Untitled Document

---

Dan Margulis wrote:

Here are two .DNG files you can acquire and see what ProPhoto RGB brings to the party. You are welcome to download one or both from my public iDisk (info below).

I acquired both through Adobe Camera RAW using Camera RAW defaults. Bring one in as ProPhoto RGB 16-bit. Bring one in as Adobe RGB (1998) and for torture sRGB. Do a small saturation move (plus or minus) of say only +7 on each, view the images at 100%. What do you see? Try Channel Mixer and other edits that affect color/tone.

Both images were shot at ISO 100 on a Canon 5D but I have another file from Jeff Schewe from a Mark II that shows the same issues in yellows and greens.

Convert the Adobe RGB (1998) file to LAB and do the saturation move too (interesting but requires a conversion getting us back full circle to doing this in 8-bit or high bit). No need for this move if you stick with the ProPhoto RGB file. Additionally, viewing the image in ColorThink shows it clips in Adobe RGB (1998) and that Adobe RGB (1998) is also too small a color space for output to an Epson running K3 inks (the gamut of the inks in useful areas is larger). Have fun.

Andrew Rodney

My public iDisk:

thedigitaldog

Name (lower case) public

Password (lower case) public

Public folder Password is "public" (note the first letter is capitalized).

To go there via a web browser, use this URL:

http://idisk.mac.com/thedigitaldog-Public

___________________________________________________________________________

I understand that anything but ACR is off-topic to this list.

But advocacy of ProPhoto space based on the problems ACR has with other spaces is over my head.

If anybody is interested I can render the file to RGB without any colour space conversions, and then we will see what colour space and bit depth it can be mapped into.

--

Best regards,

Iliah Borg

___________________________________________________________________________

Hello Andrew,

I downloaded "flower_06 october 18_001" and did the test that you suggested and I found that an RGB1998 16bit version showed some bad posterization while a ProPhoto 16bit version did not show any, I conclude that in this particular test the ProPhoto is clearly superior and that the difference between the two is probably due to the larger gamut of the ProPhoto space (like you said or implied).

I also compared a ProPhoto 16bit and a Prophoto 8bit and there was no posterization in either of them, however, colorwise, the 8bit version ended up better than the 16bit, the tones from dense areas to light areas were much more gradual. In the 16bit, the transitions were more abrupt (occurred within a shorter distance) isn't this a "mild" form of posterization?

I also corrected your RAW in the sRGB 8bit space using my own RAW settings in the Adjust and Curve tabs, using settings that suited the sRGB space best and then, in Photoshop, I did a very simple RGB all-in-one Curve (sorry Dan) instead of the Hue/Saturation move that you suggested so as to achieve an image that appears to have all the qualities of the ProPhoto 16bit image. The sRGB showed no posterization and was a match for the ProPhoto.

This last test supports my contentions that if an image must be handed over to a print shop as an sRGB file (like Wai-hong Chung mentioned) it can very well be done within the sRGB 8bit space all the way, starting with the RAW input right up to the final output file. I also think that, with some difficult images (lots of details in the reds), doing those very important RAW adjustments in the *same space* as the final output space will result in a better final image detail wise.

Andre Dumas

___________________________________________________________________________

On Oct 25, 2006, at 6:03 PM, colorman042000 wrote:

Andre,

How are your getting the 8-bit file for this comparison? I can't reproduce what you're seeing, even at 400% mag.

Well, at best it could have all the qualities of ProPhoto except the larger gamut, which the sRGB image would not be expected to be able to match.

I haven't tried this, but I agree that the ACR settings need to be optimized for whichever output space one is planning to use. You can see a large shift in the histograms when the destination profile is changed. ACR uses both RIMM and ROMM in its processing path (ignoring the gamma encoding). After the white balance and initial camera profile application, the data is basically in RIMM space. The tone curve and other user controls transform the image into ROMM space, which is then converted to the final selected RGB working space. An image that is almost identical to the output from ACR in sRGB (at a given set of settings) can be obtained from the ProPhoto image by converting in PS to sRGB, since ProPhoto and ROMM are very similar. The conversion will be with the RelCol intent (since ProPhoto does not have all 3 rendering intents), which is what ACR appears to use internally to convert from ROMM. It might be possible to get a better conversion to sRGB from ProPhoto by first converting back to ROMM, then to sRGB, as the perceptual table in the ROMM profile can be used to "pull in" the out-of-gamut colors.

I get, at most, a one-level difference in pixels between the 16-bit output from ACR and the 8-bit output, after the former is converted to 8-bit. I suspect that ACR is using 16-bit math until the image is saved, when it would be converted to 8-bit before writing the file.

This has been my experience also, although I have found that converting an image from ProPhoto to ROMM RGB before conversion to sRGB (using the Perceptual rendering intent) seems to work well. It is still not clear to me why Adobe chose to use ProPhoto as an output profile, rather than ROMM RGB. Of course, the "final" profile is seldom sRGB - it will often be a flavor of CMYK or an inkjet printer profile. Tuning images in ACR for sRGB (or AdobeRGB) as well as ProPhoto does not seem to be an efficient workflow, and certainly if one is making fine-art prints or archiving high-res TIFs, the larger gamut of ProPhoto is very desirable. If the only output I was interested in was sRGB, I would tune images in ACR with the output profile set to sRGB.

--Rich Wagner

___________________________________________________________________________

By all means, run the files through other converters. I still see the issues (but lesser so) when I use Raw Developer on the same .DNGs.

I don(c)ˆt see this as being attributable to just ACR.

Andrew Rodney

___________________________________________________________________________

I downloaded the flower dng's from Andrew's site and wanted to share what I see. I took both images and adjusted them in ACR as I normally would and exported them as both AdobeRGB and ProPhotoRGB. Sharpening was turned off for output.

I think I'm finally getting a handle on when this "gamut" stuff might matter to me. Now I'm trying to get a better handle on the best way to deal with it. I recently adjusted a photograph of a woman in a bright Aqua/Cyan workout outfit that I treated in a similar way to how I adjusted this image. For my image I was most interested in maintaining detail in the out of gamut cloths, for Andrew's image I was most interested in maintaining detail in the out of gamut yellows. There are lots of ways to do this, but I think if we're aware of the problem at the Raw stage it makes sense to deal with it as early as possible. It appears to me that a large part of the problem with these images is the poor way that RGB transformations are handled at this point in the technology. It seems crazy that when going from one gamut RGB space to another there's no control over gamut mapping. It all seems so last century.

Another problem is the limitations of our monitors. The same image rendered to different color spaces almost always appears identical on screen because even the smallest gamut spaces are all, or mostly, within our monitor's gamuts. With many printing methods exceeding the monitor in some areas (even CMYK has always had this problem with yellows), I acknowledge it can be important not to lose printable colors. However, when edited, the differences in the channels can make even a bigger difference. I have had images where maintaining detail after necessary corrections requires a lot of extra work.

I am still working under the assumption that I do not want to make ProPhotoRGB my main editing space and that for now AdobeRGB is fine for all or virtually all of my commercial and personal work. Hence I want to handle the gamut mapping into AdobeRGB and then do my image corrections.

I looked at Flower_06October18_001 with an eye toward how I would want to adjust it. When looking at the Blue channel of the AdobeRGB version the first thing I see is total black in the purest yellows. If I convert this file to ProRGB I don't get more detail, I just get a gray blob in the Blue channel. I see 2 choices: 1. Output both ProRGB and AdobeRGB and use the ProRGB Blue channel to blend with. or 2. Output as ProRGB, bring the yellows down to the AdobeRGB gamut and then convert. I think #2 is much simpler.

I took the ProRGB image (16 bit), converted to Lab (no dither), opened a Curves adjustment layer, Command Clicked on some yellow points in the b channel. I then brought down the most extreme yellows to the point where I could just barely see the saturation decrease. I then backed off a little so I couldn't see any difference on my Sony Artisan monitor and converted this to AdobeRGB. Result: a virtually identical looking version with a much better Blue channel. At this point I would normally convert to 8 bit and begin my adjustments.

Any thoughts, comments, criticisms of this working method?

Ric Cohn

___________________________________________________________________________

Rich your message created a doubt in my mind and I checked back on my tests and realized that the 8bit ProPhoto was Andrew's RAW *but* with modified ACR settings while the 16bit image was Andrew's exact settings. So I'm sorry for this error, my comments are wrong.

I did the test again and could not detect any *obvious* differences between the two images but still the 8bit version appeared to be just slightly darker than the 16bit one, could be an optical illusion, I don't know (?) I compared the two images in ColorThink and there is a difference between them but it seems to be very slight.

My comments about using sRGB as a working space have a lot to do with keeping the workflow as simple as possible when the final output is sRGB and besides I'm not convinced that converting a 16bit Prophoto RGB image to 8bit sRGB at the very end of the process will yield as good an image as one that has been kept in sRGB from beginning to end. Specially if the "process" involves a lot of manipulations.

Your comments about ACR's limitations regarding profiles are very interesting, I'm having a look at Bibble which does not seem to have those limitations.

Thanks,

Andre Dumas

___________________________________________________________________________

Dear Andrew,

Thursday, October 26, 2006, 7:26:34 PM, you wrote:

Here is a rendition of your CRW_0775 with all colour conversions skipped. The "colour" you see is how the camera recorded it.

The file was rendered in the mode we use to profile our converter. Demosaicing is done by binning (substitution of four "incomplete colour" pixels with one RGB; both greens are averaged to form new value)

Only gamma adjustment and normalisation to 16 bit were applied

http://www.pochtar.com/CRW_0775_RM_HDRstraight.zip

-- Best regards,

Iliah Borg ___________________________________________________________________________

Iliah,

Why is the left-hand side of the histogram showing such jaggedness? Aliasing? Something else?

Is binning your standard demosaicing algorithm?

What do you use as an internal color space after profiling - RIMM/ ROMM? Something else?

Where in the process do you usually switch from floating point 16-bit/ 8-bit?

Thanks!

--Rich Wagner

___________________________________________________________________________

This image is from the original challenge not the newer flower image which suggests advantages in ProPhoto RGB and my remarks about using a different converter (I see the same issues with RAW Developer). I(c)ˆm not sure what I(c)ˆm supposed to do with the image you converted scene referred.

Andrew Rodney

___________________________________________________________________________

Hello Rich,

You wrote: "ACR uses both RIMM and ROMM in its processing path (ignoring the gamma encoding). After the white balance and initial camera profile application, the data is basically in RIMM space. "

Rich, you seem to know a lot about ACR's inner chemistry, is there a document somewhere that explains all these internal processes that go on inside ACR? Where can I find it?

Andre Dumas

___________________________________________________________________________

Thursday, October 26, 2006, 7:26:34 PM, Andrew wrote:

I was going to try it through CaptureOne for comparison before I realized that it doesn't support DNG.

Ric Cohn

___________________________________________________________________________

On 10/26/06 9:06 PM, "colorman042000" wrote:

You mean the final output is an sRGB behaving display? Cause that(c)ˆs the only sRGB output device on the planet.

Some find this so called limitation a feature. It greatly reduces the complications in the product. Lightroom is going even further with this use of color management.

Andrew Rodney

___________________________________________________________________________

I wish! I keep an eye out for tidbits and try to reconstruct the bigger pieces from the scraps. Thomas Knoll seems to stay on the cutting edge, so one way to check out what's going on is to follow the imaging literature. There is a book called the Digital Color Imaging Handbook that has several good chapters on color management for digital imaging systems and color image processing for digital cameras, published by the well-respected CRC Press in 2003. Much of the cutting-edge theory is coming out of Kodak, particularly from Giorgianni and Spaulding. If you Google RIMM ROMM RGB you will find several papers by these authors, as well as white papers on RIMM and ROMM and updates by various standards committees. (RIMM and ROMM are now standards - check the Society for Imaging and Science updates. ) ROMM is nearly identical to ProPhoto. RIMM is the "scene-referred" counterpart. The future of digital imaging is in wide-gamut color spaces. Adobe is already there.

As for the quote above, it came from Thomas Knoll himself.

http: //adobe.groupbrowser.com/searchthread137621-RIMM.html

--Rich Wagner

___________________________________________________________________________

Could somebody please change the name of this thread to "Anderw's DNGs" or something? Having this ongoing as "Re: Moderator notice: stay on topic" is the height of irony.

--

___________________________________________________

RICK GORDON

EMERALD VALLEY GRAPHICS AND CONSULTING

___________________________________________________

WWW: http://www.shelterpub.com

___________________________________________________________________________

On Oct 26, 2006, at 8:06 PM, colorman042000 wrote:

Andre,

I wish I had a quarter for every time I've done something similar - usually at the beginning of a bunch of work. It happens.

Best,

--Rich Wagner

___________________________________________________________________________

I almost forgot - I3A 7466 also defines an extended dynamic range version of ROMM encoding known as ERIMM RGB. This color encoding has a logarithmic nonlinearity function and a large enough dynamic range to handle the full range of information captured on color negative film, but it requires a minimum bit-depth of 12 bits. (ROMM is defined for 8, 12, and 16-bit encoding.) The times, they are a changin'!

Besides RIMM-ROMM-EROMM, there is also e-sRGB, which is generally similar to sRGB except that it allows for extended encoding of RGB values that range from -0.53 to 1.68. This allows for the encoding of a larger or extended color gamut compared to sRGB. e-sRGB requires 10 bits per component as a minimum encoding bit depth. While both sRGB and e-sRGB are output-referred, sRGB was designed for display-based imaging systems, while e-sRGB was designed for high quality printing.

All of the great new inkjet printers coming out are handicapped without wide-gamut input, so that's where the imaging industry is putting its resources.

--Rich Wagner

___________________________________________________________________________

Hello Everyone,

Rich, I used your cropped Tiffs to do the test as you suggested. What I found is correct, the ProPhoto file is better!

But why does this effect only seem to happen with Photoshop's Hue/Saturation command? If I do any other adjustments (even radical curves) to any of the files, in any of the three color spaces the same effect doesn't show up. Is this defect limited to this Photoshop command only?

Also, I converted all the files to 8 bits in Photoshop and did the same test. I couldn't tell the difference between any of the 16 bit or 8 bit photos. The same defect to the non-ProPhoto photos existed to the same degree. I don't know why but I was expecting the effect to be worse when doing the saturation adjustment to an sRGB 8 bit file.

Any thoughts would be appreciated,

Murray DeJager

___________________________________________________________________________

Murray, there is a 'secret' option to be used with the Hue/Sat command that not all users are familiar with - which has a profound effect on the effect and thus the useability of the command. Fading to color blend mode or using the command in an adjustment layer set to color (or saturation) blend mode.

Another alternative are AB channel moves to increase saturation.

I have not had time yet to test these files, so I would be interested in your findings if you were simply using hue/saturation in normal blend mode.

Best,

Stephen Marsh.

___________________________________________________________________________

Hello Ric,

Thanks for an interesting message about Flower_06October18_001, I can see that the AdobeRGB output is inferior to the Prophoto RGB output, and whatever moves one does in ACR will not change that, I tried. Important areas in the blue channel of the AdobeRGB version are out-of-gamut, so details are missing and when you compare the composites, the differences between the two images are obvious.

I tried a different (simpler) recipe: as I came out of ACR into Photoshop with the ProPhoto RGB 16bit image I immediately converted to AdobeRGB 8bit and did a small correction in Levels to match the appearance of the ProPhoto 16bit. The blue channel is as bad as before but when you compare the two composites (16bit ProPhoto - 8bit AdobeRGB) they look identical on the monitor, I assume that the conversion process used the other two channels to compensate for the missing details in the blue channel. In ColorThink the difference between the two can be seen, it is obviously there but is not that great.

By the way many of the dark and denser pixels in both versions are out-of-gamut of my display and of my 8-color printer.

Is it possible to work in AdobeRGB 8bit or even in sRGB 8bit with results that match ProPhoto 16bit?

Andre Dumas

___________________________________________________________________________

Hi Stephen,

I consider myself an 'Advanced Beginner' but I've never heard of this 'secret' option with the Hue/Saturation command. So from now on I'll refer to myself as a beginner!

I had done the tests on the Flower_06October18.001 cropped version files using the normal blending mode.

I redid the tests today using the color blend mode on an adjustment layer and the results were different. The negative effects were greatly reduced but not totally eliminated in the 16 bit sRGB file. I don't think the negative effects were totally eliminated in the 16 bit AdobeRGB file either, but it was close.

But again, this only held true for the Hue/Saturation command. At the, supposed, extreme end I converted the 16 bit sRGB file to 8 bits in Photoshop and then converted to LAB and gave the B channel a saturation boost by bringing in the end points 10 points each. This move closly matched the saturation of the 16 bit Prophoto file after it had received a +7 saturation boost with the Hue/Saturation command on an adjustment layer with a normal blend mode. I then converted back to 8 bit sRGB. Again, I couldn't tell the difference between the 8 bit sRGB file and the 16 bit Prophoto file. No negative effects.

Now, just to make sure, I took the 8 bit sRGB file and converted back into LAB and made another couple of moves in Curves before converting back to 8 bit sRGB. Still no negative effects, until that is, I made a move with Hue/Saturation with a normal blend. Viola! the negative effects appeared!

Now, what I also found interesting is that the negative effects of this last test on the final image, with all the extra moves, was no worse then the negative effects of an otherwise 'pristine' 16 bit sRGB file that took only a +7 move in Hue/Saturation. I would have thought the componding effect all those prior moves would have made the image such a mess that by the time it got to the final Hue/Saturation move it would have collapsed into a random mass of pixels!

So the moral of the storey for me is to stay away from the Hue/Saturation command, with or without any 'secret' options.

Murray DeJager

___________________________________________________________________________

In one of the recent "Professional Photoshop" editions, Dan pointed out the significant improvement when a Saturation adjustment layer's blending is changed to Saturation mode. In normal mode, a saturation increase converts some of the color noise into luminosity noise because, in RGB and CMYK, color and luminosity are inextricably linked.

I tested a 16-bit ProPhoto version of one of Mr. Rodney's excellent flower photos against an 8-bit Adobe RGB version. I added adjustment layers to each with saturation settings of +75 to make the effect obvious--and ugly. When I changed their blending mode to Saturation, the difference was almost completely eliminated. However, neither approach comes close to the quality of increasing saturation in Lab mode as Dan illustrates quite early in "Canyon Conundrum". Also, when I tried a version in Lab mode, I had opened the image as a 16-bit Adobe RGB file and immediately converted to 8-bit before converting to Lab.

David Marley

I don't think I'll ever make a large saturation move outside Lab mode again.

___________________________________________________________________________

On 10/28/06 4:22 PM, "murraydejager" wrote:

IF you(c)ˆre referring to my Flower image and the banding with working spaces other than ProPhoto RGB, moral of this story should be, use the appropriate working space for this kind of image (ProPhoto RGB), then there(c)ˆs no issues at all with Hue/Sat and no need for all kinds of extraneous moves into LAB to boast saturation.

___________________________________________________________________________

Murray DeJager wrote:

Hi Murray, well at face value one would presume that adjusting saturation in normal blend mode via the hue/saturation command would only affect saturation! This is obviously not the case. One must change from normal blend to color or saturation blend so that the luminosity component is not adversly affected. This provides a cleaner, more natural saturation increase (but LAB is better).

Your moves were much larger than mine, as I had no issues in A98 or sRGB. Saturation was lesser, but detail was better in the sRGB, as expected. There are many ways to combine the higher saturation and the detail if one backs off a little bit on the overall saturation (still keeping high saturation in areas where there is lesser detail).

For increasing saturation in normal blend mode this is a poor choice of tool. I prefer LAB, one can even use duped high bit files and blend them back into the original 8bit RGB in color blend mode, perhaps with masks if one is concerned about issues with LAB mode. If not using LAB mode, color/saturation blend mode is a must for the hue/saturation command, in my opinion. There are many options and variations.

It is often intersting to observe *theory* and how it holds up when it is *applied* to our various workflows.

That is one viable approach. For others that do use it, I would suggest that they at least toggle between normal and color/saturation blend modes when using this command to see what effect it has on a given image (results vary).

Sincerely,

Stephen Marsh.

___________________________________________________________________________

On Oct 28, 2006, at 7:23 PM, David Marley wrote:

I can't for the life of me understand how this could help improve the image - it can only make it worse.

--Rich Wagner

___________________________________________________________________________

Richard Wagner wrote:

It's not a matter of understanding. It's a matter of looking. I made the LAB version this way, because, for me, editing high-bit, wide-gamma color is a waste of time.

I work for a small commercial printer in Boston. Our clients include universities, museums, architects and small design houses. I spend about 20 hours a week using Photoshop. Most of the pictures with which we work are of poor quality. The improvements that I and my coworkers produce are usually quite large.

Even when adjusting very good photos or art reproductions for architects and museums, Dan's concepts and methods produce a very high level of customer satisfaction. The notion that your theories say something bad is happening holds no import to our clients.

Maybe you could experiment with these techniques and see for yourself.

David Marley

___________________________________________________________________________

Hi Andrew,

Actually, I agree with your logic. If the problem is caused by a narrow colorspace then the best solution is to widen that space.

If, however, the problem is really the Hue/Saturtion command and by using a wide colorspace like Prophoto RGB one merely covers up the real problem then I don't think justice is being served.

If the Hue/Saturation command is the real problem then I would be very nervous that even the Prophoto file is suffering from some sort of damage, even though it may not be visible on screen. And maybe only after further moves or sharpening may the problem start to rear its ugly head!

The bottom line for me is, what's the real cause of the problem in your flower photos? I'm just having a hard time believing that it's a wide vs. narrow colorspace issue.

Murray DeJager

___________________________________________________________________________

On Oct 29, 2006, at 8:56 AM, David Marley wrote:

No one said anything about changing the color space to wide-gamut, and you conveniently avoided answering the question of why converting to 8-bit before conversion to LAB would improve the image. It simply cannot. The rest of your comments are irrelevant to the discussion, but if your output is only directed toward offset printing, and especially if what you usually start with are "poor originals," I would agree that wide-gamut workspaces have no role in your workflow. If you were producing images for fine-art inkjet printing, you would be doing your clients a big disservice by not utilizing the full gamut of the inkjet printers that are currently in widespread use.

--Rich Wagner

___________________________________________________________________________

On 10/29/06 2:49 PM, "murraydejager" wrote:

Seems pretty clear the issue IS the gamut of the image and working space.

It(c)ˆs not. The image doesn(c)ˆt degrade using the correct working space using those controls. Nor do other images exhibit an issue when they fall within a smaller gamut in context to the working space.

Not at all when you plot the gamut of the image within Adobe RGB (1998) versus ProPhoto RGB. Should I provide a 3D Quicktime animation? It(c)ˆs very, very clear that Adobe RGB (1998) hasn(c)ˆt the gamut to hold those yellows while ProPhoto does.

Andrew Rodney

___________________________________________________________________________

Murray,

I don't think that there is a "problem" with the flowers photos. I have *many* images that are comparable. The digital captures have a wide gamut that can easily be shown in ProPhoto. Scans from Velvia into a custom scanner profile are often similar. ACR does a good job of keeping all of the "scene-referred" data and translating it to a wide-gamut "output-referred" color space. If Andrew wanted to produce the best Epson 9800 prints possible, the ProPhoto-based image would be ideal, as there are many colors that can be printed by the Epson 9800 that do not exist in AdobeRGB or sRGB. (Even in the year 2000, a large percentage of the colors that could be printed from an inkjet printer did not exist in sRGB.) The same is true with good scans in scanner space. A lot is lost if the images are converted to sRGB or AdobeRGB - and whether or not this is important depends on the final destination. Trying to compress this information into a small-gamut color space *can* be a problem. The *real* image can only be contained within a wide-gamut color space - be that RIMM, ROMM, ProPhoto, or something else.

I uploaded a gamut plot of the one flower image so that you can see how many colors, out of a 500x500-pixel crop, are out-of-gamut in sRGB. Many of these colors are still out-of-gamut in AdobeRGB, but many can still be printed from an Epson 9800 printer if the colors are maintained in a wide-gamut color space like ProPhoto up until the conversion to the printer space.

http://www.wildnaturephotos.com/Private/AndrewRodney/

I have gamut plots of a Hutcheson Velvia film target (http:// www.hutchcolor.com/hct.htm) that also show the large numbers of **measured** colors that are out-of-gamut for AdobeRGB here:

http://www.wildnaturephotos.com/Public/GamutComparison/

Using a wide-gamut color space for digital masters is not just "my theory" or Andrew Rodney's - it is a recommendation of the American Society of Media Photographers (ASMP) and The Universal Photographic Digital Imaging Guidelines Working Group (http://www.asmp.org/ publications/updig/tools.php#master).

I hope this helps.

--RIch Wagner

___________________________________________________________________________

Hi Richard,

I'm glad you responded with the following email. I actually turned on my Epson 2400 printer and printed some flower photos today.

I believe my Epson 2400 and Andrew's Epson 9800 use the same K3 inks so the gamut of both these printers should be comparable. I printed the 16 bit flower photos after giving each a +7 Hue/Saturation move with Normal Blending in Photoshop. Each photo was printed with exactly the same printer settings and on the same paper, etc.

There were No color differences between them!

The only way I could tell the prints apart was from the obvious banding in the sRGB file and the slight banding in the Adobe RGB file. I know that the Histograms showed that the sRGB file was being drastically clipped in the yellow channel and yet in the final print it's undetectable.

Now I'm not suggesting that photos don't exist that have colors that extend beyond the gamut of my monitor, but maybe the histogram isn't the best tool for distinguishing just how far out of gamut those colors really are and whether a more expensive printer with a wider gamut is necessary.

But wait! I saved the best for last. I also took the sRGB flower photo and converted it into LAB and did a mild saturation boost in the B channel as I described in an earlier post. I then converted back into sRGB and printed it the same way I printed the other photos. When comparing all 4 photos together it now appears that I have 3 photos with banding problems and one photo with very smoooth transitions between tones. Yes, now even the Prophoto photo doesn't look that great!

Once again, I'm leaning toward NOT using the Hue/Saturation command for anything important.

Thanks for the uploads and links I will look at them all!

Murray DeJager

___________________________________________________________________________

Murray DeJager wrote:

I agree as far as this explanatoin goes Murray, but as you go on to say:

There is more going on here than attempting to fill a near full container with more than it can hold. It is more than about moving to a larger container.

The color/saturation blend seems to prove the point for me, when using the hue/saturation command to boost saturation. Normal blend mode is almost next to useless for increasing saturation without hosing the image.

There is no problem when correct technique is used, even in sRGB.

Hue/saturation in normal blend is known to create problems and there are better ways to apply the command, namely color or saturation blend or LAB mode straight line steepening AB channel curve edits that do not move the mid neutral point, or apply image blends.

So for me, in *any* RGB editing space - even ProPhoto, if I was to use a positive value in the H/S saturation slider, it would be done in saturation or color blend and not normal blend mode. After all, this is what one wishes to do, alter saturation independently of hue or tone. Why do the edit in normal blend when it is known to have negative issues? It sort of reminds me of zero threshold sharpening.

I repeated the test in third party software that supports saturation curves and the sRGB 8bpc dupe did not break as it did when using the Photoshop saturation command in normal blend mode. The sRGB does not break when using color/saturation blend mode either.

Sincerely,

Stephen Marsh.

___________________________________________________________________________

Hi Stephen,

Oh my God, what's up with zero threshold sharpening? I just bought, and read, Bruce Fraser's new book: Real World Image Sharpening. I know he doesn't use the Threshold command in any of his teachings.

Shapening is another subject that as a beginner I've been trying to understand thoroughly. I thought it was finally starting to settle in... now this!

I noticed that Dan's next book's chapter on sharpening has been rewritten and I've actually pre-ordered that book so I might have to wait a little while longer before I commit to a final sharpening workflow.

Murray DeJager

___________________________________________________________________________

Murray,

You're right - the histogram is not the best way to determine how far out-of-gamut colors are.

The best way is by actually printing all the colors that a printer is capable of, then measuring those colors and checking to see if a particular color space is capable of encoding those colors. Fortunately, this experiment was done in the year 2000.

The paper I'm referring to was authored by Henry R. Kang and was published in a well-respected, peer-reviewed scientific journal by The Society for Imaging Science and Technology for the 2000 International Conference on Digital Imaging Technologies. The paper is titled, "Computational Accuracy of RGB Encoding Standards." (https://www.imaging.org/store/epub.cfm?abstrid=4231)

The author wanted to look at the output from an inkjet printer and see if the colors that he could print could be represented by different RGB profiles (or RGB encodings). Obviously, if a given color space or RGB encoding is not capable of representing a given color, that color can't be printed, even if the RGB printer is physically capable of doing so.

The technique he used was similar in concept to what I described for looking at the "quantization loss" from converting from RGB profiles to Lab, using a "round-trip" conversion to compare the round-trip image with the original. In Kang's case, he started by printing 150 color patches with an inkjet printer and then measuring the patches to obtain their CIE LAB values under D65 illumination. He then converted these CIELAB values to 13 different different RGB color spaces and back, and looked to see if the colors were the same, and if not, how much error there was. The computational accuracy was judged by calculating deltaE value between the input LAB and the reversed LAB.

Using sRGB encoding, Kang found that an astounding 38 out of the 150 color patches, or 25.3% of all the colors tested, were out-of-range colors. These colors, spread across the spectrum, could not be reversed back to their original LAB values, indicating that the sRGB gamut was too small for a typical inkjet printer. (This was in the year 2000 - inkjet printer gamuts have increased significantly since then.) AdobeRGB showed 15 out-of-range colors (10%), mostly in the yellow, red and purple regions, thanks in large part to the higher chroma of the green primary. sRGB was by far the worst-performing color space out of the 13 tested.

At 8-bit depth, further accuracy could be obtained for "in gamut" colors by increasing the bit-depth. There was practically no visually detectable error beyond 12 bits. Not surprisingly, the out-of-range (or out-of gamut) colors produced the biggest color errors on round- trip conversion, and the errors remained the same for out-of-gamut colors regardless of bit-depth. The lesson from this is that out-of- gamut colors cannot be brought into range by extending the number of bits for encoding sRGB. Increasing the bit-depth increases the accuracy of colors that are "in gamut" by creating finer measurement granularity, but this will not help those colors that are "out-of- gamut."

Out-of-gamut colors can be eliminated, or brought "into gamut" by expanding the RGB gamut with properly selected primaries. RIMM/ROMM RGB and ROM RGB were able to enclose most, if not all real-world producible colors within their gamuts. (ProPhoto is a simplified version of ROMM RGB.) These colors can be printed on inkjet printers.

The only way that the full gamut of current ink-jet printers can be realized is to use a wide-gamut color space. Using sRGB severely limits the color output of inkjet printers. Whether or not you, personally, can visualize the difference is a different question. Many people can. In fact, this is the entire basis for the CIELAB color system. (http://en.wikipedia.org/wiki/CIELAB#CIE_1976_L.2A. 2C_a.2A.2C_b.2A_Color_Space_.28CIELAB.29)

--Rich Wagner

___________________________________________________________________________

--- "murraydejager" wrote:

It sharpens everything - even noise.

In Andrew's previous wide gamut test, the image broke after a zero threshold sharpen, but visually same sharpness could be obtained when using different settings with a threshold and then ProPhoto did not show any great advantage and the image did not break (the older shot of the tradesman working and bird feeder image). That test also contained a hue/sat move as well but I can't recall if that compounded the sharpening errors or not (another reason to sharpen the tone and not the colour component of an image).

Zero threshold USM with no edge mask or other limiting and H/S command positive saturation slider moves in normal blend are not workflows that quality conscious users would/should be embracing for real life workflows.

And smart sharpen does not have a threshold.

One is pretty much forced to use an edgemask when using a zero threshold, which Bruce advocates (so I am not picking bones with BF here as I too use edgemasks, but not for every image sharpen).

Best,

Stephen Marsh.

___________________________________________________________________________

Thanks Richard,

Color... it's a fasinating subject and although its not my intent to become a color scientist, I really just want to take nice photographs, I find the desire to understand is great!

To digress a little bit, it was only a couple of years ago that I purchased a Gretag Color Chart with the idea that if I included it in all my photos I would be able to reproduce the scenes colors 'exactly' as they were! I even once tried to color correct an image so that all the colors of the chart matched the numerical values that I had obtained from some web site on color. I'm learning!

I think its kind of ironic, some people say that ghosts exist, they can see them they just don't have any real scientific data to back them up. Here we have a subject where the scientific data of data loss exists, we just can't often see it!

Murray

___________________________________________________________________________

On Nov 1, 2006, at 4:15 PM, murraydejager wrote:

Ah, but often you can! Try it, and you'll see.

Best,

--Rich Wagner

___________________________________________________________________________

Hi Stephen,

Bruce Fraser does a pretty good job of describing why he doesn't like the Threshold command and what he does instead. So now I understand both of your points.

I'm still very curious to hear what Dan has to say in his new book however, because in his LAB book he talked about the 'Surface Blur' command which Bruce doesn't bring up at all.

Plus Bruce's book doesn't take into account any type of LAB workflow.

Murray DeJager

___________________________________________________________________________

I haven't read Fraser's recent sharpening book, but I have read some of his old sharpening articles at creativepro.com. I know about edge masks, which often can be used with zero threshold USM, but could someone please summarize the reasons for his objections to non-zero thresholds per se? (Or a link to a Fraser article where he describes his problem with non-zero threshold.) Thanks!

George Machen

___________________________________________________________________________

Hi George,

I'll quote you what Bruce Fraser has to say from his new book: "The Threshold control is designed to allow you to protect textured areas such as skin tones or slightly noisy skies from being sharpened...

...At higher settings, it has a attendency to create unnatural-looking transitions between the sharpened and unsharpened areas. Because of this tendency, I tend to rely on layer masks..."

Murray DeJager

___________________________________________________________________________

Murray - I think its kind of ironic, some people say that ghosts exist, they can see them they just don't have any real scientific data to back them up.

Here we have a subject where the scientific data of data loss exists, we just can't often see it!

Certainly ironic BUT surely in much the same way as the ghost the scientific data that represents a real life image is no more than an arguably poor interpetation of what we actually 'see'. Not so sure about seeing a ghost but seeing red or even double is sometimes on the cards. Obviously, a camera, even a digital one is of little use in these situations - too stupid perhaps?

Peter Leyland

PDQ Print Services

___________________________________________________________________________

Thanks Rich,

I have read much and not fully understood or appreciated these issues. so if I get this, there are at least 3 relevelant colorspaces (with possible excursions to and from LAB) that matter:

1) the scan or digital capture is tagged or assigned it's color space (say sRGB),

2) the monitor we are viewing on has a colorspace (and if callibrated, a color profile) which the image is mapped into for display and our manipulations and

3) the gamut of our printer defines yet another colorspace which will have different extent than either of the two above (for any given color, greater or lesser range)

so let's say we do expand the colors out by going through LAB or ProPhoto which we know is a space LARGER than out printer. On output, photoshop will attempt to condense these colors (with perceptual rendering) into colors that our printer can handle.

But if our color space is SMALLER then my guess from what you have said is that photoshop will not expand it to fit the printer's space?

Is that why you are suggesting the larger-than-the-printer colorspace (like proPhoto or EktaSpace or...) so that you fill or even slightly overfill the range of the printer and then count on Photoshop to map it down to fit?

I'm sorry if this has been covered previously; I have been looking at the archives for a while but am interested in the bottom line, in a way that I think I can understand.

Thanks in advance,

William M. Theis

___________________________________________________________________________

William,

Here's the longer response to your question on input profiles (e.g., scanner profiles) as described by Steve Upton, a true color geek who writes well for those who are not color-geeks.

INPUT PROFILES and COLOR SPACE CONVERSION GUIDELINES

http://www.chromix.com/colorsmarts/smartNote.cxsa?snid= 1081

You can find other informative information on his site here:

http://www.chromix.com/colornews/

--Rich Wagner

___________________________________________________________________________

On Nov 2, 2006, at 10:47 AM, williamtheis wrote:

Aieee! Right idea - sort of. You can tag (or more properly, assign) a profile to a scanned image from a transparency, but it is unlikely that sRGB will be the correct profile (unless color management is turned on in the scanner software and sRGB is chosen). Hopefully, someone has profiled the scanner (with color management turned OFF) and created a custom profile for the scanner/film. (With a film like Velvia the gamut of the profile will not be contained by sRGB - it will "poke out" a lot in several directions.) That profile is the one that would be assigned to the scan. For a great reference on scanning, see Don Hutchison's excellent free download, which can be found on this page describing the use of his very-high-quality scanner target: http: //www.hutchcolor.com/HCT_instructions.htm

For a scan, the next step will be converting the image in scanner profile to a "working space" such as sRGB, AdobeRGB, or ProPhotoRGB. This is done in part because *device* profiles are not neutral - e.g., grays will not be equal amounts of R,G, B like 128, 228, 128, and because you need "elbow room" to work in. It will also make it easier when compositing images from multiple sources, etc. This choice of "working space" is critical, as described below.

For digital captures, the "scene-referred" profile is often internal to the RAW processing software, and you chose an output profile. In Adobe Camera RAW, the choices are sRGB, ColorMatch, AdobeRGB, and ProPhotoRGB. (Some RAW processing software, like Phase One's Capture One, will allow you to build and use a custom camera profile.)

Note that, whether starting from a raw scan or a digital capture, the choice of working space (or output profile) is critical. Once the image gets compressed into a smaller space, it cannot be "expanded back" into a larger color space, and the color information that is lost is lost forever (unless you go back to the raw scan or digital file and start over).

Correct. This is the Display Profile that is used by color-managed apps like Photoshop to convert from your working space to the display space, thus color-correcting your image on your monitor.

Correct again. Printer profiles are device profiles - unique for each printer, ink, and paper combination (and many printer driver settings). That's why you have lots of them. Each will have a specific gamut - or range of colors that can be printed. Gamut plots are useful for comparing profiles, to see the advantages and disadvantages of each (or to pick up a bad profile!). You can download a demo version of ColorThink (or ColorThink Pro) to plot profiles in Lab space (or Luv or Yxy) here - it's a great way to visualize the differences between color spaces and profiles. (If you're on a Mac, you can also use the free ColorSync utility to do the same - it's just not as fancy.) These utilities will also allow you to "look inside" of profiles to see how they work. http://www.chromix.com/colorthink/cxctpro/index.cxsa

OK, you can't really "expand the colors out." You can *start* with an image in ProPhoto, or AdobeRGB from a digital capture or scan like we described above.... but if someone gives you an image in sRGB, that's essentially what you're stuck with. Thomas Knoll hasn't written a "gamut expander" function yet. ;-) Picture the colors of an image plotted in Lab. Those colors may fit inside sRGB, AdobeRGB, ProPhoto, or a printer gamut, but you've got what you've got, and it's too late to change it. But let's say that you have a wide-gamut image from a scan or digital capture in ProPhoto...

We use the word "compress" but the idea is the same. You can also soft-proof this step in Photoshop to see what rendering intent works the best. It might be Perceptual, and it might be RelCol. This step is done through Photoshop's Color Management Module, or CMM. The image's profile is used by the CMM to convert to the Profile Connection Space, then the CMM uses the printer profile to convert from the Profile Connection Space to your printer profile space. (The PCS is usually Lab.) The details aren't important now.

Way correct!!! There are lots of colors that the printer will never print if you always use a color space that is smaller than the printer's gamut. Picture a sphere inside another sphere, both plotted in Lab, where the inner sphere represents your working space gamut and the outer sphere represents your printer gamut. If the colors on the inner sphere "max out" at RGB 255, 255, 255, as do the colors on the outer sphere, you can never give RGB coordinates for the inner sphere that will "reach out" to the outer sphere. You can't address that empty space between the spheres, thus you can't print any of those colors. In the real world, the gamuts are not spherical, and they don't overlap nicely. But to print all the colors that a printer is capable of, the working space must enclose the printer space.

Correct again. Congrats!!!! I think you've got it! That's the big picture. I created a web page describing this a couple of years ago, using AdobeRGB rather than sRGB, but you might find it helpful. It includes a scanner profile for comparison, as well.

http://www.wildnaturephotos.com/Public/GamutComparison/

Hope this was helpful.

Best,

--Rich Wagner

___________________________________________________________________________

Murray,

To me it's a simple warning of the effect of too high a setting. Why this is enough to scare everyone off using it at all (setting it to 0) surprises me.

This isn't unique to Photoshop's USM. Its been around in scanners for a lon