Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: xpatUSA on April 05, 2013, 03:51:22 pm
-
Sometime back, I shot a sunflower RAW image which was not well converted by ACR to RGB color. I tracked that problem down to yellows that were out-of-gamut in sRGB but not in ProPhoto. As I understand it, there are various ways (familiar to people who print stuff) of bringing wide gamuts into smaller ones - absolute colorimetric, perceptual, shift the white point, don't, etc, etc.
What would this forum recommend that would give such choices and more when converting image files from one space to another, as opposed to what Adobe thinks is good for you? I have ACR 5.4 and PSE 6 and am not looking to upgradeeither anytime soon. I don't intend to get LR, either. Nor GIMP, nor rawTherapee (not easy to open Sigma files in those).
Mainly I shoot Sigma X3F images and play around with some of them quite a lot for research purposes. I often use Dave Coffins' dcraw and lately have been looking at it's XYZ output in ImageJ, the background for that being lamp spectral emission shots using a spectroscope. Just downloaded a ImageJ plug-in, not tried it yet though.
-
Sometime back, I shot a sunflower RAW image which was not well converted by ACR to RGB color. I tracked that problem down to yellows that were out-of-gamut in sRGB but not in ProPhoto. As I understand it, there are various ways (familiar to people who print stuff) of bringing wide gamuts into smaller ones - absolute colorimetric, perceptual, shift the white point, don't, etc, etc.
That's what the profile will do for you, so just let it after soft proofing. For conversion using simple matrix profiles (sRGB, Adobe RGB etc), there is only the Colorimetric table in such profiles. You'll have to use Relative Colorimetric despite what you select (but don't pick Absolute, that's the same table without a white shift).
http://digitaldog.net/files/LR4_softproof2.mov
-
Thanks Andrew,
Sorry, I should have made it more clear that I don't have LR4 and that I don't print anything, hence I never soft-proof.
A specific case for me would be:
An image looks good (i.e. no clipping, no horrible discontinuities, etc.) on-screen (but of course, not accurate) in color space A, say ProPhoto. But, when it is converted by something into the much maligned sRGB space clipping occurs - whereas one might prefer a different conversion, but still for display on-screen. It would be expected that the output image would have the correct ICC for screen applied as part of the process.
-
What would this forum recommend that would give such choices and more when converting image files from one space to another, as opposed to what Adobe thinks is good for you?
It's not a question of what Adobe thinks, but the ICC. ICC v2 color space profiles can only use Relative Colorimetric rendering intent...so, out of gamut clips. And this isn't a function of Adobe's software, simply following the ICC spec.
The ICC has release their v4 spec and offers an sRGB v4 profile that does have Perceptual rendering. You can read more about it here: sRGB v4 Preference (http://www.color.org/srgbprofiles.xalter). With this profile you can actually use a perceptual rendering intent going from PP RGB > sRGB v4.
As far as optimizing color space conversions, you can preview what a conversion will look like and use soft proofing to adjust the conversion before converting...but that takes an app that can soft proof like Photoshop or Lightroom. I don't think there is any way to use soft proofing in Elements.
-
An image looks good (i.e. no clipping, no horrible discontinuities, etc.) on-screen (but of course, not accurate) in color space A, say ProPhoto. But, when it is converted by something into the much maligned sRGB space clipping occurs - whereas one might prefer a different conversion, but still for display on-screen. It would be expected that the output image would have the correct ICC for screen applied as part of the process.
Just to eliminate some of the variables:
- Is your monitor calibrated and profiled with a hardware device (ColorMunki, Spyder, Huey etc)?
- Are you viewing the images with colour-manged programs or viewers? Photoshop (and I assume Elements), Lightroom and the W7 and W8 photo viewers are colour managed. Firefox and Safari are colour manged (the latter only if there's an embedded profile). IE (even IE10), Chrome, and most other programs are not colour managed.
Unless both these are true, then images are likely to look different in different colour spaces, even if the conversion from one colour space to another is perfect.
-
It's not a question of what Adobe thinks, but the ICC. ICC v2 color space profiles can only use Relative Colorimetric rendering intent...so, out of gamut clips. And this isn't a function of Adobe's software, simply following the ICC spec.
The ICC has release their v4 spec and offers an sRGB v4 profile that does have Perceptual rendering. You can read more about it here: sRGB v4 Preference (http://www.color.org/srgbprofiles.xalter). With this profile you can actually use a perceptual rendering intent going from PP RGB > sRGB v4.
Thanks, I may have there before re: rendering intent and did actually download V4 but it got lost when my computer died last year, RIP. Even worse, I can barely remember which intent does what (getting old 70+) but I was interested mainly in the one that squeezes the larger gamut down, losing saturation in so doing.
As far as optimizing color space conversions, you can preview what a conversion will look like and use soft proofing to adjust the conversion before converting...but that takes an app that can soft proof like Photoshop or Lightroom. I don't think there is any way to use soft proofing in Elements.
Well, I don't print, so would be happy enough with an app that takes e.g. a 16-bit ProPhoto TIFF output from dcraw and handily turns it into a 8-bit sRGB JPEG. And it would mostly be research-based, not a regular workflow thing.
Simon,
I may have wasted your time by not making it clear that I am not trying solve a problem per se. Your reply seems to be in a trouble-shooting style, which is why I said that.
Just to answer your questions though, my monitor is totally uncalibrated apart from me turning down the color temp 'cause it's to bright for my old eyes. I am no purist, and the NEC Multi-sync shows it! My and other's pics look good enough on it for my purposes - which may seem at odds with the OP, I know.
I use many different viewers for different reasons: FastStone Viewer, FireFox, Picasa, ACR, PSE, ImageJ, IrfanView, Sigma Photo Pro, and (blush) the Windows XP thing. I'm used to all their differences which don't bother me that much, to be honest.
-
Sorry, I should have made it more clear that I don't have LR4 and that I don't print anything, hence I never soft-proof.
Soft proofing is for more than printing. IF you want to see the effects of moving into different color spaces AND you have the ability to control the rendering intent (and thus the gamut clipping/compression that MUST result), it's useful to soft proof. But until you calibrate and profile that display, none of this is even worth doing. FWIW, when moving from larger to smaller color space, gamut clipping is often going to happen and you have to live with it.
-
Soft proofing is for more than printing. IF you want to see the effects of moving into different color spaces AND you have the ability to control the rendering intent (and thus the gamut clipping/compression that MUST result), it's useful to soft proof. But until you calibrate and profile that display, none of this is even worth doing. FWIW, when moving from larger to smaller color space, gamut clipping is often going to happen and you have to live with it.
Hi Andrew, perhaps there is a need for more understanding - since "caps" are beginning to appear ;)
I'm talking about mostly research for my own amusement into things like lamp emission spectra, shooting van der Wolf targets, and stuff that does not require perfect color rendition on my monitor before my very eyes. Another case in point was ACR putting blotches on a flower whereas SPP did not . . . research was the answer - and might have been a lot easier if I had the OP subject to hand. In these cases, "proofing" for me means digging into an image with, e.g., ImageJ and examining file data values rather than what's on the screen.
I hasten to add the obvious: I am not a Pro, neither do I have a gallery of pics needing the ultimate in presentation.
Yet, photography can be a fascinating subject . . even with an un-calibrated monitor . . .
-
Perhaps the quest for "a good color space converter" is inappropriate?
Woke up this morning with the thought that a converter is a converter and no more than that. In other words, going from (easy example) XYZ to sRGB is a fixed conversion and, as Andrew said, if it's gonna clip it will. In which case, the question in the OP is not possible to answer in the way that the OP intended. Which is what I believe y'all were trying to tell this obstinate old man ;)
So, if I understand correctly, this raw file will probably not clip (triangle is sRGB):
(http://www.kronometric.org/phot/gamut/gamutCR.jpg)
(http://www.kronometric.org/phot/gamut/cedarRidge.jpg)
But the following one could be quite a problem:
(http://www.kronometric.org/phot/gamut/gamutSF.jpg)
The second gamut being that of a sunflower shot in sunlight.
And, if understand further, correct gamut conversion per se does not include rendering intent which, duh, is what it says it is!
I said earlier that flowers can be troublesome. Here is a typical yellow flower spectral reflectivity:
(http://www.kronometric.org/phot/gamut/yellowFlowerReflSpect.jpg)
Looking at the purple line on the graph, that flower is yellow with next to no blue in it.
Here's how ACR (left) rendered my sunflower versus Sigma PhotoPro (right) last year:
(http://www.kronometric.org/phot/gamut/blues.jpg)
Nothing in ACR nor in PSE post could fix those blotches without messing up the image saturation or color balance, whereas SPP and dcraw produced a blotch-free image by magic. I'll stress that it was the blotches that irritated, not the rendered color of the petals (too golden).
Here's the final sRGB image of flower in question and I can't remember how I did it :(
(http://www.kronometric.org/phot/gamut/SPP576.jpg)
Thanks to you all for your time and advice,
-
What you are seeing there is more a gamut clipping issue where the out of gamut color cause uneven gradations. Again, download and install the sRGB V4 profile and try that.
BTW, you should really read up a bit on the whole ICC workflow...the actual color transform algorithms are contained in the color matching method (CMM) but the choice of rendering intents is contained in the receiving profile. So if you are going from PP RGB > sRGB, it's the sRGB that must have the various rendering intents...and the sRGB v4 Preference profile I mentioned in the beginning has that and would allow a perceptual rendering from PP RGB > sRBG and get the advantage of gamut compression instead of simple clipping.
-
What you are seeing there is more a gamut clipping issue where the out of gamut color cause uneven gradations. Again, download and install the sRGB V4 profile and try that.
Thanks again. Er - install it where? I forget where it went last time. (Windows XP Pro, SP3).
BTW, you should really read up a bit on the whole ICC workflow...the actual color transform algorithms are contained in the color matching method (CMM) but the choice of rendering intents is contained in the receiving profile. So if you are going from PP RGB > sRGB, it's the sRGB that must have the various rendering intents...and the sRGB v4 Preference profile I mentioned in the beginning has that and would allow a perceptual rendering from PP RGB > sRBG and get the advantage of gamut compression instead of simple clipping.
Excellent advice . . I've read it and read it 'til I'm blue in the face - then I get interested in other stuff and it just fades away. But you and the Dog have reminded me about rendering intent being being contained in the receiving file, e.g. embedded IC profile, if I understand it this time around.
-
On Windows, colour profiles go in C:\Windows\System32\spool\drivers\color.
Apart from reference white papers on the ICC site (http://www.color.org/index.xalter (http://www.color.org/index.xalter)) the best reference is "Color Management for Photographers" by Andrew Rodney (aka digitaldog, who posted above). It's from 2005 and some of the examples relate to 2005 software, but virtually all of it is still relevant.
-
But you and the Dog have reminded me about rendering intent being being contained in the receiving file, e.g. embedded IC profile, if I understand it this time around.
Close...the way it goes is this: Source profile dictates the profile connection space (PCS) which could be L*a*b* or XYZ (usually XYZ in matrix profiles), which is given to the color matching module (CMM) which uses the rendering intents in the destination profile (and it's PCS) to do the color transform...so it's the destination profile whose rendering intents dictate how the color transform (the CMM) does it's conversion. That's why the sRGB V4 Preference profile is useful...it actually has other rendering intents than the normal ICC v2 Relative Colorimetric rendering.
The rendering intent controls how the source gamut is converted to the destination gamut. With V2 matrix profiles (display class working space profiles), there's no real choice (even if software allows you to change it), it's always, only Relative Colorimetric...the sRGB V4 Preference profile DOES allow the use of perceptual rendering, which is what you want when compressing the source gamut into the destination gamut.
Ultimately, if you want control over the PP RGB to sRGB conversion, you'll want something that can soft proof the sRGB V4 Preference profile destination. You might want to take a good look at Lightroom if you don't want to move up to a full Photoshop license. Elements is rather limited...
-
Close...the way it goes is this: Source profile dictates the profile connection space (PCS) which could be L*a*b* or XYZ (usually XYZ in matrix profiles), which is given to the color matching module (CMM) which uses the rendering intents in the destination profile (and it's PCS) to do the color transform...so it's the destination profile whose rendering intents dictate how the color transform (the CMM) does it's conversion. That's why the sRGB V4 Preference profile is useful...it actually has other rendering intents than the normal ICC v2 Relative Colorimetric rendering.
Thanks again, Jeff,
I did a *.icc search on my machine and it found 155 (now 156) 15 (now) 16 including today's sRGB V4 Preference profile. Where does it go? Do I re-name it? Do I move "old" sRGB profiles? It seems that several applications have a place for profiles . . often the "same" ones, by filename anyway :(
The rendering intent controls how the source gamut is converted to the destination gamut. With V2 matrix profiles (display class working space profiles), there's no real choice (even if software allows you to change it), it's always, only Relative Colorimetric...the sRGB V4 Preference profile DOES allow the use of perceptual rendering, which is what you want when compressing the source gamut into the destination gamut.
By "allow the use of", does that occur invisibly or do all my applications somehow now come up with choices. So like, in Elements 6, where it said "Convert to sRGB" under the image menu would it now say something different? (not talking about the choices offered for printing).
Ultimately, if you want control over the PP RGB to sRGB conversion, you'll want something that can soft proof the sRGB V4 Preference profile destination. You might want to take a good look at Lightroom if you don't want to move up to a full Photoshop license. Elements is rather limited...
Recalling that I don't print and that the destination is my monitor (or a web sRGB monitor), what would "soft proofing" be in that context? Sadly, PSE6 is still serving my main purposes very well . . so I'll still with it until it irritates me enough to move elsewhere which might be soon if I don't get a grip of this conversion business :-\
Simon,
Thanks for the link, will be heading there directly . .
-
Ultimately, if you want control over the PP RGB to sRGB conversion, you'll want something that can soft proof the sRGB V4 Preference profile destination. You might want to take a good look at Lightroom if you don't want to move up to a full Photoshop license. Elements is rather limited...
Jeff,
I have my own shot of a sunflower with highly saturated yellow. Soft-proofing with the sRGB V4 Preference profile using the perceptual intent in Photoshop does show some reduction in clipping when converting to sRGB. However, in LR 4.4 on my 64 bit windows machine, the sRGB V4 Preference profile does not seem to be available--it does not show up in the list of installed profiles even though the profile is properly installed and does work with Photoshop.
Do you know what is going on and have you seen the same with LR on your Mac? Also, ColorThinkPro ver 3.0.3 does not work properly with the Ver 4 profile-the color plot and image view is way off.
Bill
-
However, in LR 4.4 on my 64 bit windows machine, the sRGB V4 Preference profile does not seem to be available--it does not show up in the list of installed profiles even though the profile is properly installed and does work with Photoshop.
Yeah, I just tested this and that profile does not show up in LR 4.4. Not sure why...I'll ask.
-
By "allow the use of", does that occur invisibly or do all my applications somehow now come up with choices. So like, in Elements 6, where it said "Convert to sRGB" under the image menu would it now say something different? (not talking about the choices offered for printing).
Simon,
No, it means that when selecting Perceptual in a profile conversion, it can actually use the perceptual rendering. In most color space profiles like PP RGB, Adobe RGB and the v2 sRGB, even though software allows you to select perceptual, there is no perceptual rendering intent in the profile, so regardless of what you select in rendering intent, it's always only doing a relative colorimetric rendering.
-
Yeah, I just tested this and that profile does not show up in LR 4.4. Not sure why...I'll ask.
I'm sure I read that LR doesn't support v4 profiles, or is that out of date or just a myth?
-
Yeah, I just tested this and that profile does not show up in LR 4.4. Not sure why...I'll ask.
It's because it's missing a tag that LR uses to filter profiles. The "class" of the ICC profile needs to be Display or Output for it to show up for soft-proofing in Lr. I have a copy where this was updated if anyone's interested.
-
I'm sure I read that LR doesn't support v4 profiles, or is that out of date or just a myth?
Depends on the profile, how it was built and where you can use it. Generally speaking, V4 profiles bring nothing useful to the party, they are half baked "V2 profiles in V4 sheep's clothing". I don't know what profile package today supports what is called the PRMG which is a key to V4 profiles being (more) useful.
Until PRMG is fully supported, we're back to the part of the conversion whereby the CMM gets Lab data and has no idea about the source (was it big like ProPhoto or small like sRGB?). Each package makes it's own assumptions which is, well an assumption. It is useful with the V4 sRGB profile to have a perceptual table, but by the time that profile get's it's data, the Perceptual Rendering Gamut is no more defined than if you were using a V2 profile.
-
Depends on the profile, how it was built and where you can use it. Generally speaking, V4 profiles bring nothing useful to the party, they are half baked "V2 profiles in V4 sheep's clothing". I don't know what profile package today supports what is called the PRMG which is a key to V4 profiles being (more) useful.
Until PRMG is fully supported, we're back to the part of the conversion whereby the CMM gets Lab data and has no idea about the source (was it big like ProPhoto or small like sRGB?). Each package makes it's own assumptions which is, well an assumption. It is useful with the V4 sRGB profile to have a perceptual table, but by the time that profile get's it's data, the Perceptual Rendering Gamut is no more defined than if you were using a V2 profile.
Shown is my sunflower image that was in ProPhotoRGB and converted to sRGB with massive clipping (left). Converting to sRGB perceptual v4 with perceptual rendering helps somewhat, but colors are still clipped (right). As the Dog states, the CMM has no idea of what color was in the original, and the colors are merely compressed by a predetermined amount.
Bill
-
As the Dog states, the CMM has no idea of what color was in the original, and the colors are merely compressed by a predetermined amount.
But, it's an improvement...and with soft proofing you could tweak the colors even more.
So, zooming in, do you see any examples of where relcol produces blotches that perceptual doesn't?
-
But, it's an improvement...and with soft proofing you could tweak the colors even more.
So, zooming in, do you see any examples of where relcol produces blotches that perceptual doesn't?
No, I don't see any blotches with either conversion, but I would imagine that blotches would depend on the subject matter.
Bill
-
I'm back, after a some more research, some experimenting with the sunflower and re-thinking the reasons behind the OP.
For me, my sunflower problem posted earlier occurred with ACR 5.4's conversion from X3F into it's working space. In that version of ACR what you see (all sliders 0) is what you got, assuming WB to be as good as it can be. That is to say, the conversion itself is fixed by Adobe. If there is a clipping problem caused by an image occupying a large gamut, that can not be fixed in ACR. That is to say, the image appears on the monitor clipped or blotched and, only when the sliders are set to extreme levels downward do the blotches go away - at which point the image looks stupid, washed out, a total failure. It may well be that the in-camera exposure was high for the shot (it was a one-off snap) but the RAW data itself was not clipped - I checked and re-checked.
On the other hand, Dave Coffin's 'dcraw' allows all sorts of adjustments to the raw data during the conversion, among them being saturation, brightness and gamma - not to mention a choice of output color spaces: raw, sRGB, aRGB, aWIDE, PP and XYZ. Not that I recommend dcraw particularly, it has a clunky command line interface and a somewhat protracted work cycle.
So it is that, armed with a better understanding of color spaces and profiles gained from this thread, I've managed to produce a blotch-free sunflower (again) but this time with some knowledge of how that was possible.
(http://kronometric.org/phot/profile/sf.jpg)
(Slightly sharpened, no other processing).
I no longer regard 'perceptual' as a kind of Grail, especially for one who only produces sRGB images and never prints anything. I will continue with what applications I have for now. Any 'difficult' capture will get either dcraw'ed or trashed; ACR->PSE for the rest . . ;-)
Perhaps I should mention that my serious cameras are RAW only (early Sigmas).
-
I'm back, after a some more research, some experimenting with the sunflower and re-thinking the reasons behind the OP.
For me, my sunflower problem posted earlier occurred with ACR 5.4's conversion from X3F into it's working space. In that version of ACR what you see (all sliders 0) is what you got, assuming WB to be as good as it can be. That is to say, the conversion itself is fixed by Adobe. If there is a clipping problem caused by an image occupying a large gamut, that can not be fixed in ACR. That is to say, the image appears on the monitor clipped or blotched and, only when the sliders are set to extreme levels downward do the blotches go away - at which point the image looks stupid, washed out, a total failure. It may well be that the in-camera exposure was high for the shot (it was a one-off snap) but the RAW data itself was not clipped - I checked and re-checked.
On the other hand, Dave Coffin's 'dcraw' allows all sorts of adjustments to the raw data during the conversion, among them being saturation, brightness and gamma - not to mention a choice of output color spaces: raw, sRGB, aRGB, aWIDE, PP and XYZ. Not that I recommend dcraw particularly, it has a clunky command line interface and a somewhat protracted work cycle.
So it is that, armed with a better understanding of color spaces and profiles gained from this thread, I've managed to produce a blotch-free sunflower (again) but this time with some knowledge of how that was possible.
I no longer regard 'perceptual' as a kind of Grail, especially for one who only produces sRGB images and never prints anything. I will continue with what applications I have for now. Any 'difficult' capture will get either dcraw'ed or trashed; ACR->PSE for the rest . . ;-)
Perhaps I should mention that my serious cameras are RAW only (early Sigmas).
Ted,
Your revised image may be free from blotches, but IMHO the midtones are too dark and the three quarter tones in the center of the flower are severely lacking in detail. Furthermore, the reds are clipped in sRGB. You may underestimate the power of ACR and overestimate the advantages of dcraw. According to Eric Chan an image in ProPhotoRGB may be converted to whatever space you want with no loss of quality as long as you are in 16 bits. Gamma 2.2 is the preferred editing space, since it is approximately perceptually uniform.
It would be interesting if you would make your raw file available for others to try their hand with ACR and compare the results.
Regards,
Bill
-
d.d. et alii,
A theoretical question: Would it be possible to work around the impossibility of Perceptual rendering with a matrix working space by converting first to a device space that is close in gamut to sRGB (my monitor's space, for instance, is 96% of sRGB) using Perceptual R.I. and then a second conversion to sRGB, or would the inaccuracies, quantization errors, etc. make it not worthwhile?
-
A theoretical question: Would it be possible to work around the impossibility of Perceptual rendering with a matrix working space by converting first to a device space that is close in gamut to sRGB (my monitor's space, for instance, is 96% of sRGB) using Perceptual R.I. and then a second conversion to sRGB, or would the inaccuracies, quantization errors, etc. make it not worthwhile?
Nope...you would have to convert to an output profile space that contained perceptual rendering lookup tables (LUTs)...your display space is just another matrix based color space and only has Relative Colorimetric rendering...and what you would loose converting to some sort of real output profile whose gamut is described by the profile would make that trip pretty nasty for color.
-
Your revised image may be free from blotches, but IMHO the midtones are too dark and the three quarter tones in the center of the flower are severely lacking in detail. Furthermore, the reds are clipped in sRGB.
Thanks, Bill,
Yes, the image had no post-processing other than sharpening for posting. It was a quick test; one of several I had already made to check the embedded ICC profiles (or lack thereof). Blotch removal was the only point really. As to detail, the original raw is a LO res 0.8MP image because I was on my way to shoot a wrist watch on the bench. I do have a few more processed images; here's one I did a few minutes ago:
(http://kronometric.org/phot/profile/sf2.jpg)
You may underestimate the power of ACR and overestimate the advantages of dcraw.
I must not have made myself clear, I wasn't pushing dcraw over ACR. I was trying to emphasize that ACR 5.4 has no options for the conversion per se from raw data to ACR's working space, whereas dcraw allows several.
It would be interesting if you would make your raw file available for others to try their hand with ACR and compare the results.
The raw file is attached for anyone to download and have a go.
P.S. I'm stuck at ACR 5.4 because that's the highest possible download for PSE6. I'm sticking with PSE6 because it's fast, it suits my purpose and I have it on a CD. So, although interested as always, it won't mean too much for me to be told about later versions, or ACR as it opens with more tabs in CS, or LR, etc.
-
Yes, the image had no post-processing other than sharpening for posting. It was a quick test; one of several I had already made to check the embedded ICC profiles (or lack thereof). Blotch removal was the only point really. As to detail, the original raw is a LO res 0.8MP image because I was on my way to shoot a wrist watch on the bench. I do have a few more processed images; here's one I did a few minutes ago:
I must not have made myself clear, I wasn't pushing dcraw over ACR. I was trying to emphasize that ACR 5.4 has no options for the conversion per se from raw data to ACR's working space, whereas dcraw allows several.
The raw file is attached for anyone to download and have a go.
P.S. I'm stuck at ACR 5.4 because that's the highest possible download for PSE6. I'm sticking with PSE6 because it's fast, it suits my purpose and I have it on a CD. So, although interested as always, it won't mean too much for me to be told about later versions, or ACR as it opens with more tabs in CS, or LR, etc.
Ted,
Thanks for the raw file. The latest ACR is of little use here as the blotches appear when exposure is reduced. Even though the blotchy areas do not appear completely blown, I think that ACR highlight recovery is coming into play and it recovers to neutral, so the yellow is lost. DCraw has a better highlight recovery that looks at adjacent pixels and tries to maintain the highlight color. Look at Guillermo Luijk's essay (http://www.guillermoluijk.com/tutorial/dcraw/index_en.htm) on highlight recovery in DCraw (fig 9). Rawtherapee also has an option for this type of recovery.
I don't know much about Foveon sensors and hope some one else can clear up this behavior.
Regards,
Bill
-
Ted,
Thanks for the raw file. The latest ACR is of little use here as the blotches appear when exposure is reduced. Even though the blotchy areas do not appear completely blown, I think that ACR highlight recovery is coming into play and it recovers to neutral, so the yellow is lost. DCraw has a better highlight recovery that looks at adjacent pixels and tries to maintain the highlight color. Look at Guillermo Luijk's essay (http://www.guillermoluijk.com/tutorial/dcraw/index_en.htm) on highlight recovery in DCraw (fig 9). Rawtherapee also has an option for this type of recovery.
I don't know much about Foveon sensors and hope some one else can clear up this behavior.
Thanks for the link which I had downloaded some time back. But, re-reading, I did notice that I've been using BT 709 gamma (DCraw's default) and not the sRGB, so there's another thing to try on those dark bits in the middle of sunflower . .
dcraw -v -a -b 0.75 -o 1 -g 2.4 12.95 -q 3 -6 -T sf.X3F
The highlights in the top left petals, while not blown in the raw data, may well be in the less linear part of the F7 Foveon dynamic range. The camera outputs "saturation" metadata for each of the 3 channels, somewhere around 6,000 but, if you really over-expose, values up around 10,000 can be found in the raw data.
Interestingly, ExifToolGUI reveals that DCraw actually tacks a V2.1 perceptual profile on to it's output file, not that anything on my computer seems to do anything with it ;).
TTFN,
-
On the other hand, Dave Coffin's 'dcraw' allows all sorts of adjustments to the raw data during the conversion, among them being saturation, brightness and gamma - not to mention a choice of output color spaces: raw, sRGB, aRGB, aWIDE, PP and XYZ. Not that I recommend dcraw particularly, it has a clunky command line interface and a somewhat protracted work cycle.
So it is that, armed with a better understanding of color spaces and profiles gained from this thread, I've managed to produce a blotch-free sunflower (again) but this time with some knowledge of how that was possible.
(http://kronometric.org/phot/profile/sf.jpg)
(Slightly sharpened, no other processing).
I no longer regard 'perceptual' as a kind of Grail, especially for one who only produces sRGB images and never prints anything. I will continue with what applications I have for now. Any 'difficult' capture will get either dcraw'ed or trashed; ACR->PSE for the rest . . ;-)
Perhaps I should mention that my serious cameras are RAW only (early Sigmas).
Qimage Ultimate uses dcraw for its RAW conversions. It may not have all dcraw cords to pull and the interface is not what most like but at least is not a command line program. Whether sRGB V4 is also used I did not check but it supports the ICC profile formats up to the latest v4.2 ICC standards. The extrapolation and sharpening tools are excellent too. Its control on anti-aliasing in downsampling may be of interest for web use.
The developer, Mike Chaney, has/had some early Sigma cameras and wrote articles on them that you probably know.
--
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
December 2012, 500+ inkjet media white spectral plots.
-
Interestingly, ExifToolGUI reveals that DCraw actually tacks a V2.1 perceptual profile on to it's output file
dcraw include the HP sRGB profile (no perceptual intent). The tag you see is the tag of sRGB profile.
(http://img713.imageshack.us/img713/3525/srgb.jpg)
You get a conversion problem not a gamut problem.
Working with dcraw to get a ProPhoto image, the out of gamut colors are limited (dEmax=5.5, only 83 colors have dE>=4).
Performing a gamut mapping from ProPhoto to sRGB, instead of clipping (that is using the sRGB profile), you have a slight difference not visible on my monitor.
Jacopo
-
dcraw include the HP sRGB profile (no perceptual intent). The tag you see is the tag of sRGB profile.
(http://img713.imageshack.us/img713/3525/srgb.jpg)
Thanks Jacopo,
I said that dcraw gives 'perceptual' based on ExifToolGui information. Here is a screen shot:
(http://kronometric.org/phot/profile/sfICCtiff.gif)
You can see that it says 'perpetual' and mentions 'auto-generated by dcraw' copyright. The profile shown is embedded in a TIFF made by dcraw V 9.02 and the source image file was of type X3F.
On the other hand, I see that you are showing us a screen shot of a non-embedded profile in system32\..\color\ folder. Please explain why, to help me to understand your post.
You get a conversion problem not a gamut problem.
Working with dcraw to get a ProPhoto image, the out of gamut colors are limited (dEmax=5.5, only 83 colors have dE>=4).
Your measurement of delta-E's: what image were they from (I have post several) and what application was used?
Performing a gamut mapping from ProPhoto to sRGB, instead of clipping (that is using the sRGB profile), you have a slight difference not visible on my monitor.
What application was used to perform the gamut mapping? I would be interested in that.
-
Qimage Ultimate uses dcraw for its RAW conversions. It may not have all dcraw cords to pull and the interface is not what most like but at least is not a command line program. Whether sRGB V4 is also used I did not check but it supports the ICC profile formats up to the latest v4.2 ICC standards. The extrapolation and sharpening tools are excellent too. Its control on anti-aliasing in downsampling may be of interest for web use.
Thanks for the tip, Ernst,
I don't print, so I had ignored Qimage. I've used UFraw in the past which is also a GUI that uses dcraw but without all the options.
You might be interested in this discussion elsewhere, where Mike Chaney gets a bit of a bashing!
http://www.dpreview.com/forums/thread/2840961#forum-post-35878372
I use dcraw mainly for research. For example, to get linear, high-gamut image files of lamp spectral emissions.
Otherwise my few images go straight to ACR and I accept what comes out (except for blotchy sunflowers!).
-
On the other hand, I see that you are showing us a screen shot of a non-embedded profile in system32\..\color\ folder. Please explain why, to help me to understand your post.
On ICC ProfileInspector display you can read: "Intent: Perceptual".
This is from "Intent" tag of ICC profile.
This tag may not have any meaning until the profile is used in some context, e.g in a DeviceLink.
But the tag exists and a zero value is the encoding for "perceptual". You can find the same zero value into many profiles (Adobe1998, ProPhoto,....).
Your measurement of delta-E's: what image were they from (I have post several) and what application was used?
From your raw, converted using dcraw to get a ProPhoto image.
The application used is PhotoResampling. But the tool is not realased currently.
What application was used to perform the gamut mapping? I would be interested in that
.
Same answer as above.
Jacopo
-
Thanks for the tip, Ernst,
I don't print, so I had ignored Qimage. I've used UFraw in the past which is also a GUI that uses dcraw but with out all the options. You might be interested in this discussion elsewhere, where Mike Chaney gets a bit of a bashing!
http://www.dpreview.com/forums/thread/2840961#forum-post-35878372
I use dcraw mainly for research. For example, to get linear, high-gamut image files of lamp spectral emissions.
Otherwise my few images go straight to ACR and I accept what comes out (except for blotchy sunflowers!).
People complaining about a financial solution that changed their update fee from zero for lifetime (Mike's? User's?) to 20 dollar a year 8-)
One wonders what they think about the Adobe update policy changes over the last years. Anyway Mike is a tough sparring partner in any discussion .......
Adding the sRGB V4 profile to the list for Qimage is all it takes.
Ernst, op de lei getypt
-
Found one . . .
http://www.drycreekphoto.com/tools/profile_converter/