A Workflow with Beta RGB

[Robert Ardill]

I would like to correct what I said regarding the Perceptual gamut mapping from the working space to the destination.  How this is achieved does depend on the profile maker and not all profiles will map the whole of the source gamut to the destination gamut.  The reason for this is not necessarily that mapping part of the source gamut is better (although it may be) but rather because with many profiling programs, the source profile is not specified, so the mapping table has no knowledge of it.  In that case I suppose it would have to use some arbitrary figure, which could leave OOG colors.  With ArgyllCMS the source gamut must be specified and so it does know how to construct the Perceptual and Saturation mappings in relation to the source profile (the mapping has to be in relation to something, of course). 

This link explains things better than I can, in relation to Argyll at any rate: http://www.argyllcms.com/doc/iccgamutmapping.html

My apologies,

Robert

[Jim Kasson]

I would like to correct what I said regarding the Perceptual gamut mapping from the working space to the destination.  

Thank you for that, Robert.

Warning: off topic part starts here.

And now that we're not arguing that point, here's a link to an algorithm for gamut mapping that my admittedly biased and interested self believes would be an improvement over the point-process gamut mapping algorithms used today. It is more computationally-intensive than a straight 3D interpolation, but I don't think it would materially increase print times. I think it could be implemented in a manner compatible with ICC-managed systems. Mapping is performed independent of the source space.

http://www.google.com/patents/US5450216

It's not exactly unknown; it's been referenced 181 times by other patents. The patent has lapsed and I believe  the concepts are available to all.

Jim

[Robert Ardill]

Thank you for that, Robert.

Warning: off topic part starts here.

And now that we're not arguing that point, here's a link to an algorithm for gamut mapping that my admittedly biased and interested self believes would be an improvement over the point-process gamut mapping algorithms used today. It is more computationally-intensive than a straight 3D interpolation, but I don't think it would materially increase print times. I think it could be implemented in a manner compatible with ICC-managed systems. Mapping is performed independent of the source space.

http://www.google.com/patents/US5450216

It's not exactly unknown; it's been referenced 181 times by other patents. The patent has lapsed and I believe  the concepts are available to all.

Jim

Hi Jim,

A plain English interpretation of this mapping system would be appreciated! 

A quick look through the patent gives me this impression: that the both the luminance and chrominance of out of gamut colors (and also in-gamut colors) are mapped on the basis that:
- we are more susceptible to chroma that also has a high luminance
- for that reason, for every hue angle, the luminance for the maximum chroma is found
- OOG colors for each hue angle are then mapped in the direction of that luminance, with more OOG colors mapped a larger distance and small OOG filtered out
- in-gamut colors are also mapped in the same way, but to a lesser extent, to avoid ugly banding-type artifacts
- the chrominance of the mapped colors is also adjusted so that colors that have been lightened will have their chroma increased whereas colors that have been darkened will have their chroma decreased.

Is that the general gist of it?

It seems like a good idea, but I imagine that the implementation would be very difficult (not the maths of it, but getting the image to look right ... that is, what algorithms to use, exactly and how to go about tuning the model for a good visual effect ...).

Still, it would be nice to have this as an extra mapping intent within the ICC model.  Perhaps someone could convince the ICC to add an extra intent called 'Experimental' .

Robert

[Tim Lookingbill]

Actually, Tim, it is very much of practical use.  You surely can't be serious when you say that there is no value in understanding what happens when an image is mapped from one color space to another?  Or perhaps I've misunderstood you.

If you prefer to work entirely by experience then that's totally fine: it is another and entirely valid way of finding out what works and what doesn't.  Experience cannot be replaced by theory - I don't dispute that. But why knock an attempt to understand what actually happens when A gets transformed to B?

Robert

I haven't seen you provide a better looking image directly connected to knowing how this works, nor have I produced a better looking image and I do understand what's going on.

It's just the work as been done and I paid for it in the software. I don't need to know how the code was written and how it produces the preview on my display or on my print. If the code doesn't give me what I want, I don't look under the hood to figure out what's wrong. I find other ways to get what I want which turns out to be a lot faster and better than your approach.

[Robert Ardill]

I haven't seen you provide a better looking image directly connected to knowing how this works, nor have I produced a better looking image and I do understand what's going on.

It's just the work as been done and I paid for it in the software. I don't need to know how the code was written and how it produces the preview on my display or on my print. If the code doesn't give me what I want, I don't look under the hood to figure out what's wrong. I find other ways to get what I want which turns out to be a lot faster and better than your approach.

I really do get it Tim ... you think I'm wasting my time, your time, everyone's time and that I should quit and go process some images.  Well, as it happens I have to agree with you ... if I don't follow your advice I won't be able to pay the bills next month 

Robert

[Tim Lookingbill]

Thank you for that, Robert.

Warning: off topic part starts here.

And now that we're not arguing that point, here's a link to an algorithm for gamut mapping that my admittedly biased and interested self believes would be an improvement over the point-process gamut mapping algorithms used today. It is more computationally-intensive than a straight 3D interpolation, but I don't think it would materially increase print times. I think it could be implemented in a manner compatible with ICC-managed systems. Mapping is performed independent of the source space.

http://www.google.com/patents/US5450216

It's not exactly unknown; it's been referenced 181 times by other patents. The patent has lapsed and I believe  the concepts are available to all.

Jim

Jim, can you produce a print of an image that takes advantage/benefits from this algorithm and take a photo of it and post it here, so we can all see how this is going to make our gamut mapping lives much easier?

[Robert Ardill]

Mapping is performed independent of the source space.

Jim,

As you seem to be interested in this general topic and seem knowledgeable, I wonder if you would be kind enough to explain to me how a mapping is done without reference to the source (without an intelligent CMM that examines the image data and computes the mapping on the fly, that is)?

Referring to the image below, the top sketch is essentially how ArgyllCMS does it: because it knows the gamut of the source it can relatively intelligently work out how far the OOG pixels need to be mapped to bring them into gamut, and also how far the in-gamut pixels need to be mapped.  

In the bottom sketch I show just the output gamut.  Clearly the profile cannot know how far the pixels might be out of gamut.  So on what basis is the mapping done?  It would have to make an assumption on the source gamut, surely ... perhaps picking an intermediate gamut like Beta RGB?  Then smaller gamuts would be mapped too much and larger ones would end up with pixels outside the intermediate gamut effectively clipped to the destination gamut.  Is that not so?



And would this also not apply to the method proposed in the patent?

BTW ... now that we seem to have gotten off the subject of sRGB etc., one of the reasons I use Beta RGB (and not sRGB is that I can make a Perceptual profile for it that is optimized for its gamut.  I could make multiple profiles for different working spaces, of course, but that would really be Gilding the Lilly!

Robert

[Robert Ardill]

Jim, can you produce a print of an image that takes advantage/benefits from this algorithm and take a photo of it and post it here, so we can all see how this is going to make our gamut mapping lives much easier?

I have to give it to you Tim ... you have me convinced! Never in the history of mankind has so much hot air been expended for so little elevation!  (I have hot air baloons in mind). But, it's kind of fun ... and I suspect you get some fun out of it too, or you wouldn't be reading and commenting on the posts .

Robert

[Jim Kasson]

A plain English interpretation of this mapping system would be appreciated!  

A quick look through the patent gives me this impression: that the both the luminance and chrominance of out of gamut colors (and also in-gamut colors) are mapped on the basis that:
- we are more susceptible to chroma that also has a high luminance
- for that reason, for every hue angle, the luminance for the maximum chroma is found
- OOG colors for each hue angle are then mapped in the direction of that luminance, with more OOG colors mapped a larger distance and small OOG filtered out
- in-gamut colors are also mapped in the same way, but to a lesser extent, to avoid ugly banding-type artifacts
- the chrominance of the mapped colors is also adjusted so that colors that have been lightened will have their chroma increased whereas colors that have been darkened will have their chroma decreased.

Is that the general gist of it?

It seems like a good idea, but I imagine that the implementation would be very difficult (not the maths of it, but getting the image to look right ... that is, what algorithms to use, exactly and how to go about tuning the model for a good visual effect ...).

I think you've pretty much got it, Robert. The idea is to be able to change the luminance, not just the chroma, so that we don't have to make as big changes to the chroma as we otherwise would have to. Further, when we're making luminance changes, do it at low spatial frequency so that the viewer doesn't twig to the fact that we're messing with the luminance. Think of it as dodging and burning, but with the luminance changes averaged over neighborhoods, in the direction that makes the amount of chroma change you need to be smaller than it otherwise would be.

It ran fairly slowly on the computers of the day, but it took a minute or so to open a PhotoCD image on them.

In testing the algorithm, it worked very well if you didn't get too greedy -- make big luminance changes. There were color combinations that made it fail -- think of one color that needed its luminance raised right next to a color that needed its luminance lowered -- but in most implementations the result was to leave the luminance alone. There was no big win, but no loss either.  

The whole thing depended, as do all gamut mapping algorithms that I know of, on having a color space in which you could adjust chroma and keep the same hue. Lab and Luv were just fair at that. Now, thanks to Bruce Lindbloom and others, we have spaces that are a lot closer to ideal in this respect.

Jim

[Jim Kasson]

Jim, can you produce a print of an image that takes advantage/benefits from this algorithm and take a photo of it and post it here, so we can all see how this is going to make our gamut mapping lives much easier?

Tim, I'd have to implement the algorithm in my present programming environment: Matlab. That'll take a week or so of coding. And, if I did it, I'd want to figure out how to use Bruce Lindbloom's modification of Lab. Still, it's a neat idea, and I'd like to try it if I get some time.

Jim

[Jim Kasson]

Jim,

As you seem to be interested in this general topic and seem knowledgeable, I wonder if you would be kind enough to explain to me how a mapping is done without reference to the source (without an intelligent CMM that examines the image data and computes the mapping on the fly, that is)?

The algorithm that I proposed does examine the image data and computes the mapping on the fly. All it requires is the image in a color space appropriate to gamut mapping (like Bruce's modification of Lab) and the gamut of the output device in that same space. The gamut of the space in which the image was created is irrelevant.

Knowing the source space could be useful in supplying "hints" to the gamut mapping algorithm, sort of like Postscripts hints help in rasterizing fonts. I think explicit hints to gamut mappers could help a lot. You could say we already have one set: rendering intent, but a bunch of knobs with labels like "maximize chroma", "concentrate on these [ a list of values] colors", "make it pop", "make it subtle", etc. There may be some of that slipping into custom ICC profiles; X-Rite lets you build printer profiles that are optimized (in what way I don't know) for certain images.

Jim

[TylerB]

I hope this isn't cold water thrown on an otherwise good thread, but BetaRGB does not contain the gamut of some current ink/paper combinations. I used BetaRGB for years, never had any problem with it, and though I'm not sure I saw a significant improvement, was secure in the knowledge all was well due to the comparison's and explanations on Bruce's sight. One improvement for sure, it was much easier to fit the profiled and color managed gamut of drum scanned color film into BetaRGB, than having to massage some colors down to fit into AdobeRGB.
When I got the 9900 and began testing and profiling many papers, I was surprised to find some combinations could print colors outside of BetaRGB. So in my opinion, there is still no ideal working space, to convert "from", if your primary work is editing for print, and printing. Joseph Holmes newer spaces look interesting, but those are smaller the 9900 gamut as well. ProPhoto, and maybe one or two others a bit obscure, (Wide Gamut?), are the only ones big enough, assuming printer gamut containment is THE criteria. As others in the thread have shown, they may be less than ideal.
Tyler

[Tim Lookingbill]

One improvement for sure, it was much easier to fit the profiled and color managed gamut of drum scanned color film into BetaRGB, than having to massage some colors down to fit into AdobeRGB.
Tyler

Referencing what I had to do with the orange flower edit demo posted earlier in the thread, what do you mean by "fit" the gamut of drum scanned color into BetaRGB that wouldn't fit in AdobeRGB and what did that involve? How did it manifest to tell you that was the problem? Do you mean you had to edit color detail so it didn't turn into blobs of posterized color as I had to do in the orange flower? Or was all this "not fitting" manifested in the print?

[fdisilvestro]

Joseph Holmes newer spaces look interesting, but those are smaller the 9900 gamut as well.

Not D Cam4 or D Cam5. This profile (DCam 5) makes ProPhotoRGB looks small and it is the only profile I have seen that ecompasses all visible colors (not even LAB)

[fdisilvestro]

The algorithm that I proposed does examine the image data and computes the mapping on the fly. All it requires is the image in a color space appropriate to gamut mapping (like Bruce's modification of Lab) and the gamut of the output device in that same space. The gamut of the space in which the image was created is irrelevant.

Knowing the source space could be useful in supplying "hints" to the gamut mapping algorithm, sort of like Postscripts hints help in rasterizing fonts. I think explicit hints to gamut mappers could help a lot. You could say we already have one set: rendering intent, but a bunch of knobs with labels like "maximize chroma", "concentrate on these [ a list of values] colors", "make it pop", "make it subtle", etc. There may be some of that slipping into custom ICC profiles; X-Rite lets you build printer profiles that are optimized (in what way I don't know) for certain images.

Jim

Jim, thanks for this. I hope what you propose continues to evolve and gets into commercial software soon.

[jwlimages]

Hmm, well it's entertaining (and somewhat informative, I must admit) to see a rip-roaring tussle over working spaces again. Thanks!

Not to hijack the thread, but I did see a couple posts that seemed reminiscent of the concept about converting to a final output space that is small, e.g., sRGB - what is the current thinking about the idea advanced in the past that one can get a better final result by converting in steps - e.g., from ProPhoto (large) original to AdobeRGB (smaller) as a transition, then to final destination sRGB?

Some of the image examples posted earlier in this thread seem intended to support this scheme, no?

John

JWL Images
Emeryville, CA

[Robert Ardill]

The algorithm that I proposed does examine the image data and computes the mapping on the fly. All it requires is the image in a color space appropriate to gamut mapping (like Bruce's modification of Lab) and the gamut of the output device in that same space. The gamut of the space in which the image was created is irrelevant.

Knowing the source space could be useful in supplying "hints" to the gamut mapping algorithm, sort of like Postscripts hints help in rasterizing fonts. I think explicit hints to gamut mappers could help a lot. You could say we already have one set: rendering intent, but a bunch of knobs with labels like "maximize chroma", "concentrate on these [ a list of values] colors", "make it pop", "make it subtle", etc. There may be some of that slipping into custom ICC profiles; X-Rite lets you build printer profiles that are optimized (in what way I don't know) for certain images.

Jim

Jim, thanks for the clarification on the algorithm ... I had missed the (crucial) point of the luminance changes being limited to low spacial frequencies.

OK, so this is effectively a new CMM which incorporates the gamut-mapping strategy, which is surely a better way to go if you want a good Perceptual mapping (algorithm and performance issues aside).  How do you see it fitting in with the current ICC model (the only way I can see it myself is that the new CMM would override the Perceptual mapping in existing profiles).

Robert

[Robert Ardill]

Hmm, well it's entertaining (and somewhat informative, I must admit) to see a rip-roaring tussle over working spaces again. Thanks!

Not to hijack the thread, but I did see a couple posts that seemed reminiscent of the concept about converting to a final output space that is small, e.g., sRGB - what is the current thinking about the idea advanced in the past that one can get a better final result by converting in steps - e.g., from ProPhoto (large) original to AdobeRGB (smaller) as a transition, then to final destination sRGB?

Some of the image examples posted earlier in this thread seem intended to support this scheme, no?

John

JWL Images
Emeryville, CA

Hey John ... you most certainly are not hijacking the thread because I started it and the whole thrust was the advantage of using as small a workspace as possible, so that Perceptual mappings would cause the least damage possible.

The corollary to this is that if you prefer to work in a large working space, as many of us do for various reasons, then there may be an advantage when doing a Perceptual mapping to first convert the image to a smaller working space.  The reason for this, as I've tried to explain with little success , is that a Perceptual mapping effectively 'squeezes' the working space gamut (or some approximation of it) into the destination gamut.  The result may be that saturated colors in the image will end up less saturated. As i1Profiler says: "The perceptual intent is intended to preserve the look and feel of the original image, maintaining tone and detail as a first priority, and saturation/color accuracy as a second priority" (bold on 'saturation' and 'second priority' from me).

The idea behind the 2-step mapping is that the first step is a Relative Colorimetric one from the large working space to the smaller one (of course there is a need to watch out for out-of-gamut issues when doing this); followed by the 2nd step which a Perceptual mapping to the destination.  What this should do is to reduce the desaturating effect of the Perceptual mapping from the original (large) workspace.

There is no advantage to using a 2-step approach for Relative or Absolute Colorimetric but there should be for Perceptual and Saturation.  Since converting from any workspace to another workspace (say ProPhoto to sRGB) is always Relative Colorimetric, there is no benefit from doing a 2-step from ProPhoto to sRGB.  The destination profile has to be for print (or to output profiles that use LUTs).

If we do not want to use this 2-step approach (but do want to try to get a better Perceptual mapping), the various profiling programs offer some alternative mechanisms:

i1Profiler gives some controls to attempt to improve the Perceptual mapping (for example to weight the profile towards saturation ... presumably at the expense of color accuracy). You can also optimize the profile to your particular image (I don't know what the effect is, except, presumably, to add additional spot colors to reduce the amount of interpolation required).

ArgyllCMS has a more intelligent algorithm, I think.  When you build a profile with Argyll you specify the source gamut. So you can specify, for example, that your source gamut is AdobeRGB and then the profile knows that your images will all be within AdobeRGB, so the Perceptual mapping is only from AdobeRGB and not some bigger gamut: this should reduce the desaturating effect of the Perceptual mapping.

With Argyll you can go quite a big step further as you can build the profile for a specific image (or for a range of images).  The Perceptual mapping is then fully optimized to that image (or range of images), so it should give the best Perceptual mapping.  The downside is that you can't use this profile for other images.

Robert

[Robert Ardill]

Tim, I'd have to implement the algorithm in my present programming environment: Matlab. That'll take a week or so of coding. And, if I did it, I'd want to figure out how to use Bruce Lindbloom's modification of Lab. Still, it's a neat idea, and I'd like to try it if I get some time.

Jim

I didn't realize you had actually implemented the algorithm Jim ... the final one in the patent I guess?  Very interesting ... I hope you do get to the time to re-code it!  If you do I'll be happy to do some testing .

Robert

[Robert Ardill]

I know I should post this in the 'Adobe Raw Q&A section', but I don't want to start a whole new topic, and the question is very much related to this thread.  (I have searched the forum and I haven't found a reply, although no doubt it's there, so if anyone knows where the relevant thread is, please let me know!).

Anyway, my question/comment relates to raw Smart Objects in Photoshop, and backward compatibility.  If I understand things correctly, if I have an image with a raw SO in Photoshop CC, opened from Lightroom with PV2012 (or from ACR with PV2012), I can edit the same image in Photoshop CS6 as it also has PV2012 support.  However, although I can open the image in CS4, say, I can no longer edit the raw SO (well, I can edit it, but it will get changed simply by opening it and closing it) as CS4 doesn't have PV2012 support.  What that means to me is that if I ever want to go back to CS6 that the critical thing NOT to do from later versions of Lightroom or Photoshop CC is to use a process version greater than PV2012 (when that gets introduced).  Is that correct?

My second question relates to camera support and process version.  If I find that I need to use the latest version of ACR because I've just bought myself a new camera, does this mean that I will then have to use the latest process version (say PV2015) in order to have support for my camera? I think the answer is no, that the camera support is not tied in to the process version (since I can process a 1DsIII image in PV2003).

So, as far as raw smart objects in Photoshop are concerned, we should be able to go back to CS6, providing we stick to PV2012; and as long as Adobe continues to sell perpetual versions of Lightroom, we should be relatively confident to be able to stay in PV2012 and be able to go back to CS6. Or is it worse than that?

Robert