New article on color management

Started Apr 26, 2013 | Discussions
Great Bustard
Forum ProPosts: 23,242
Like?
Re: Color Space Color Gradations
In reply to Jack Hogan, Apr 29, 2013

Jack Hogan wrote:

Great Bustard wrote:  What I'm wondering is if 16 bits representing a less expansive colorspace might not have advantages, on occasion, over 16 bits representing a larger colorspace, due to the finer gradations of the smaller colorspace.

You mean which color space makes better use of the available bits with histograms such as these (sRGB to the left, ProPhoto to the right)?

As far as I know, any issues that ProPhoto had with posterization went away when PS switched to 16 bits, so I would guess that if there is an advantage to the higher color resolution of the smaller space it is not noticeable in practice.

Jack

Excellent!  That was *exactly* what I was asking.  Thanks!

Reply   Reply with quote   Complain
crames
Regular MemberPosts: 192
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to gollywop, Apr 29, 2013

gollywop wrote:

crames wrote:

sRGB might not be the best color space in which to do white-balancing. Another reference here. (sRGB has the same primaries as ITU-R BT.709 compared in these references.)

I'm not sure what you're talking about here, Cliff.  If you're shooting raw and doing white-balancing in ACR, the result is the same regardless of which working space you've chosen.  If you're talking about white-balancing a jpeg in PS -- well, there you're on your own.

Well, it depends on one's workflow, doesn't it? Just more reason to avoid editing in sRGB.

Reply   Reply with quote   Complain
gollywop
Veteran MemberPosts: 5,554
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to crames, Apr 29, 2013

crames wrote:

gollywop wrote:

crames wrote:

sRGB might not be the best color space in which to do white-balancing. Another reference here. (sRGB has the same primaries as ITU-R BT.709 compared in these references.)

I'm not sure what you're talking about here, Cliff.  If you're shooting raw and doing white-balancing in ACR, the result is the same regardless of which working space you've chosen.  If you're talking about white-balancing a jpeg in PS -- well, there you're on your own.

Well, it depends on one's workflow, doesn't it? Just more reason to avoid editing in sRGB.

"Reason"? . . . no.

-- hide signature --

gollywop

Reply   Reply with quote   Complain
crames
Regular MemberPosts: 192
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to gollywop, Apr 29, 2013

gollywop wrote:

crames wrote:

gollywop wrote:

crames wrote:

sRGB might not be the best color space in which to do white-balancing. Another reference here. (sRGB has the same primaries as ITU-R BT.709 compared in these references.)

I'm not sure what you're talking about here, Cliff.  If you're shooting raw and doing white-balancing in ACR, the result is the same regardless of which working space you've chosen.  If you're talking about white-balancing a jpeg in PS -- well, there you're on your own.

Well, it depends on one's workflow, doesn't it? Just more reason to avoid editing in sRGB.

"Reason"? . . . no.

Jack said, "Compare this to moving to the output space at the very start and then applying rendering/adjustments.  Chances for error would intuitively appear to be minimized in this case, no?"

If you want to do white balance and other adjustments in ACR, then you'll not be "moving to the output space at the very start," and in fact none of the operations performed in ACR will have been accomplished in the sRGB space, since ACR uses a linearized ProPhoto internal space.

If you were to white balance in ACR and do the rest in sRGB, of course you will not run into the potentially sub-optimal white balance problems described in the papers I referenced. On that basis, yes, white-balance issues would not be a "reason" to avoid sRGB. Despite having avoided the white-balance issues, you will still be faced with the possible hue shiifts during other routine editing operations after moving to the sRGB space. It's not hard to imagine that sometimes it is necessary use PS to selectively touch up the white balance of a digital photo taken in mixed lighting, or even skip ACR completely, for example when editing a film scan. In such cases the potential white balance issue is another "reason" to avoid sRGB .

In answer to Jack's original question, I think that one has more control over the conversion to sRGB if the conversion and gamut-mapping to the smaller sRGB space is saved for the end, because then you have the full controls of PS to deal with any out-of-gamut colors. By going camera space -> ProPhoto -> edit -> sRGB, you have the opportunity to identify out-of-gamut colors and smoothly bring them into gamut by selective desaturation. If instead one converts to sRGB at the very start, you really have no control over the mapping of the out-of-gamut colors - in most cases they will be simply chopped down to the gamut boundary.

Cliff

Reply   Reply with quote   Complain
photoreddi
Senior MemberPosts: 4,026
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to xpatUSA, Apr 29, 2013

xpatUSA wrote:

gollywop wrote:

xpatUSA wrote:

gollywop wrote:

How does dcraw treat a raw file?  That would give us a good hint.

For what it's worth, dcraw offers the following -o (output) options:

Thanks, xpatUSA.  Yes, those are the choices for an output space.  So it would appear that XYZ is a possible output space, but it is not employed as a matter of course during processing, which is what I'd figure.  It's like RPP allows LAB as a choice for an output space, but it doesn't figure in any of the basic rendering operations.

My mistake. As I understand color theory, XYZ is a color model and, as you probably know, color spaces are contained within a color model. XYZ itself is, as it were, dimensionless - often normalized to 1,1,1 for example. What Coffin does (at least with my X3F's) is transform the 3-channel raw data into 16-bit XYZ numbers, i.e. 1 = 65,553. Theoretically, he should do this internally anyway, irrespective of the output space but he's not forced to do so and I don't know if he does. When displayed on the monitor, his XYZ images come out very unsaturated as one expect. One of Coffin's profiles is ProPhoto linear gamma, so I suspect that he may use Kodak RIMM/ROMM as the working area. ArvoJ probably knows more about that than I.

Similarly, CIELAB is also a color model, not a space, so I'm not sure how it could be chosen as an output space although it is most certainly a PCS for some profiles.

Er, what is RPP?

This Mac photo app., I assume.

http://www.raw-photo-processor.com/RPP/Overview.html

Reply   Reply with quote   Complain
Roy Sletcher
Contributing MemberPosts: 769
Like?
Question: Is there a Windows equivelent to COLORSYNC?
In reply to Detail Man, Apr 29, 2013

Detail Man wrote:

http://www.youtube.com/watch?v=n0bxSD-Xx-Q

High resolution version: http://digitaldog.net/files/ColorGamut.mov

By Andrew Rodney, author of “Color Management for Photographers”

Website: http://digitaldog.net/

.

Here is a 3-D viewer widget for comparing color spaces:

http://www.iccview.de/content/view/3/7/lang,en

I watched the Digital Dog video. Extremely well presented, and a complex subject clearly explained.

I was intrigued by the Apple Colorsync utility which enabled Printer profiles to be visually compared to defined color spaces by means of a 3D plot.

My Question:

Does a PC or Windows utility exist which does the same thing, or close to the same thing?

I am calibrate my monitor and make printer/paper profiles with colormunki, and would like to see the co-relation between the two in 3D graphic format.

Roy Sletcher

Reply   Reply with quote   Complain
Detail Man
Forum ProPosts: 15,000
Like?
Re: Question: Is there a Windows equivelent to COLORSYNC ?
In reply to Roy Sletcher, Apr 30, 2013

Roy Sletcher wrote:

Detail Man wrote:

http://www.youtube.com/watch?v=n0bxSD-Xx-Q

High resolution version: http://digitaldog.net/files/ColorGamut.mov

By Andrew Rodney, author of “Color Management for Photographers”

Website: http://digitaldog.net/

.

Here is a 3-D viewer widget for comparing color spaces:

http://www.iccview.de/content/view/3/7/lang,en

Bruce Lindbloom's web-site also has a 3-D viewer widget (for a list of color-spaces) here:

http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html#Viewer

I watched the Digital Dog video. Extremely well presented, and a complex subject clearly explained.

I was intrigued by the Apple Colorsync utility which enabled Printer profiles to be visually compared to defined color spaces by means of a 3D plot.

My Question:

Does a PC or Windows utility exist which does the same thing, or close to the same thing?

I am calibrate my monitor and make printer/paper profiles with colormunki, and would like to see the co-relation between the two in 3D graphic format.

No direct experience with such applications. Googling the search terms:

"3-D color space windows"

... turned up a few apps with versions for Windows. Interestingly, they are all somewhat "dated":

Trial version allows 20 tests (2008): http://www.gamutvision.com/

Limited functionality trial version (2005): http://www2.chromix.com/colorthink/std/

Freeware (2007): http://www.couleur.org/

Reply   Reply with quote   Complain
Hugowolf
Forum ProPosts: 11,271
Like?
Re: Hope this may help a bit ...
In reply to gollywop, Apr 30, 2013

OK so I was mostly wrong about the use of floating point numbers for processing. I think what got me thinking this way was Adobe's descriptions of the blending mode algorithms, here:

http://photoblogstop.com/photoshop/photoshop-blend-modes-explained#BlendModeMath

and here:
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf
from about p324 onwards

Brian A

Reply   Reply with quote   Complain
Hugowolf
Forum ProPosts: 11,271
Like?
Re: Question: Is there a Windows equivelent to COLORSYNC?
In reply to Roy Sletcher, Apr 30, 2013

Roy Sletcher wrote:

Detail Man wrote:

http://www.youtube.com/watch?v=n0bxSD-Xx-Q

High resolution version: http://digitaldog.net/files/ColorGamut.mov

By Andrew Rodney, author of “Color Management for Photographers”

Website: http://digitaldog.net/

.

Here is a 3-D viewer widget for comparing color spaces:

http://www.iccview.de/content/view/3/7/lang,en

I watched the Digital Dog video. Extremely well presented, and a complex subject clearly explained.

I was intrigued by the Apple Colorsync utility which enabled Printer profiles to be visually compared to defined color spaces by means of a 3D plot.

My Question:

Does a PC or Windows utility exist which does the same thing, or close to the same thing?

I am calibrate my monitor and make printer/paper profiles with colormunki, and would like to see the co-relation between the two in 3D graphic format.

I haven't seen the presentation in a while, but I am pretty sure that Andrew uses Chromix ColorThink Pro, not Apple's ColorSync. There is a Windows version of ColorThink Pro.

Brian A

Edit, I just checked and it is definately ColorThink Pro.

Reply   Reply with quote   Complain
gollywop
Veteran MemberPosts: 5,554
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to crames, Apr 30, 2013

crames wrote:

gollywop wrote:

crames wrote:

gollywop wrote:

crames wrote:

sRGB might not be the best color space in which to do white-balancing. Another reference here. (sRGB has the same primaries as ITU-R BT.709 compared in these references.)

I'm not sure what you're talking about here, Cliff.  If you're shooting raw and doing white-balancing in ACR, the result is the same regardless of which working space you've chosen.  If you're talking about white-balancing a jpeg in PS -- well, there you're on your own.

Well, it depends on one's workflow, doesn't it? Just more reason to avoid editing in sRGB.

"Reason"? . . . no.

Jack said, "Compare this to moving to the output space at the very start and then applying rendering/adjustments.  Chances for error would intuitively appear to be minimized in this case, no?"

If you want to do white balance and other adjustments in ACR, then you'll not be "moving to the output space at the very start," and in fact none of the operations performed in ACR will have been accomplished in the sRGB space, since ACR uses a linearized ProPhoto internal space.

The linearized ProPhoto RGB is ACR's internal working space, but, if you've chosen sRGB, or Adobe RGB, or ProPhoto RGB (non-linearized) as your "working" space, what you see on your monitor and the corresponding histograms are the version as rendered in that space.

Eric Chan :: ( http://www.luminous-landscape.com/forum/index.php?topic=60179.msg485409#msg485409 ) @ December 12, 2011 :
The internal working space of ACR and LR is Referred Input Medium Metric (RIMM), which has ProPhoto RGB primaries with linear gamma.  Temporary excursions are made to other color spaces and image decompositions, as needed, to suit the image processing.
In ACR, there are additional options to set the desired output color space (which is used to drive the histogram and on-screen preview image).

If you were to white balance in ACR and do the rest in sRGB, of course you will not run into the potentially sub-optimal white balance problems described in the papers I referenced. On that basis, yes, white-balance issues would not be a "reason" to avoid sRGB. Despite having avoided the white-balance issues, you will still be faced with the possible hue shiifts during other routine editing operations after moving to the sRGB space.

As I said before, there will be equal or worse problems in converting at the end after using a broader space.  This is not to say it's a bad idea to do so, but it is to say that your critique of moving directly to sRGB on this account is misplaced.

It's not hard to imagine that sometimes it is necessary use PS to selectively touch up the white balance of a digital photo taken in mixed lighting

Of course.  This is true simply as a matter of fact and not finessed by any other method.  What's nice is that, with recent versions of ACR, it is possible to apply selective WB.

In answer to Jack's original question, I think that one has more control over the conversion to sRGB if the conversion and gamut-mapping to the smaller sRGB space is saved for the end, because then you have the full controls of PS to deal with any out-of-gamut colors. By going camera space -> ProPhoto -> edit -> sRGB, you have the opportunity to identify out-of-gamut colors and smoothly bring them into gamut by selective desaturation. If instead one converts to sRGB at the very start, you really have no control over the mapping of the out-of-gamut colors - in most cases they will be simply chopped down to the gamut boundary.

You're a better man than I.  I've done just what you advocate -- did it for years.  I processed in ProPhoto RGB as a matter of course and ended up with beautiful images on my wide-gamut monitor.  Then when I went to "selectively desaturate" the OOG colors in soft proofing to reduce the space for printing or for the web, the degree of selective desaturation that was required to undo all the beauty that ProPhoto RGB created resulted in "selective colors" that were dull as dirty dishwater -- downright unpleasant.

I was better off in these cases simply printing from the ProPhoto RGB space using the printer's profile without any adjustments.  The OOG colors were considerably less vibrant than on screen, but they were a heck of a lot better than the "controlled" adjustments of which you speak.  Better yet were the same images processed in Adobe RGB, which more nearly matches my Pixma Pro 9000 II's gamut.  Not much worse were those processed in sRGB.  As to web-destined images, the same holds, except that Adobe RGB is not as useful.

So, I know what you're saying: it is, and has been, a common mantra.  But, in my experience, it is not borne out in fact.

But, as the old saying goes, "suit yourself."

-- hide signature --

gollywop

Reply   Reply with quote   Complain
crames
Regular MemberPosts: 192
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to gollywop, Apr 30, 2013

gollywop wrote:

crames wrote:

gollywop wrote:

crames wrote:

gollywop wrote:

crames wrote:

sRGB might not be the best color space in which to do white-balancing. Another reference here. (sRGB has the same primaries as ITU-R BT.709 compared in these references.)

I'm not sure what you're talking about here, Cliff.  If you're shooting raw and doing white-balancing in ACR, the result is the same regardless of which working space you've chosen.  If you're talking about white-balancing a jpeg in PS -- well, there you're on your own.

Well, it depends on one's workflow, doesn't it? Just more reason to avoid editing in sRGB.

"Reason"? . . . no.

Jack said, "Compare this to moving to the output space at the very start and then applying rendering/adjustments.  Chances for error would intuitively appear to be minimized in this case, no?"

If you want to do white balance and other adjustments in ACR, then you'll not be "moving to the output space at the very start," and in fact none of the operations performed in ACR will have been accomplished in the sRGB space, since ACR uses a linearized ProPhoto internal space.

The linearized ProPhoto RGB is ACR's internal working space, but, if you've chosen sRGB, or Adobe RGB, or ProPhoto RGB (non-linearized) as your "working" space, what you see on your monitor and the corresponding histograms are the version as rendered in that space.

Eric Chan :: ( http://www.luminous-landscape.com/forum/index.php?topic=60179.msg485409#msg485409 ) @ December 12, 2011 :
The internal working space of ACR and LR is Referred Input Medium Metric (RIMM), which has ProPhoto RGB primaries with linear gamma.  Temporary excursions are made to other color spaces and image decompositions, as needed, to suit the image processing.
In ACR, there are additional options to set the desired output color space (which is used to drive the histogram and on-screen preview image).

Clearly confirming what I said, and Eric said further down in that same message, "These color conversions are done at the end of the image processing pipeline, after the UI-driven controls (e.g., Exposure) are done."

That there is a convenient preview of the output does change the fact that the image processing is done in the internal space(s) and not in the output space.

If you were to white balance in ACR and do the rest in sRGB, of course you will not run into the potentially sub-optimal white balance problems described in the papers I referenced. On that basis, yes, white-balance issues would not be a "reason" to avoid sRGB. Despite having avoided the white-balance issues, you will still be faced with the possible hue shiifts during other routine editing operations after moving to the sRGB space.

As I said before, there will be equal or worse problems in converting at the end after using a broader space.  This is not to say it's a bad idea to do so, but it is to say that your critique of moving directly to sRGB on this account is misplaced.

I guess this is where we disagree. I think it is worse to introduce hue shifts to an image that already suffers from out-of-gamut issues.

It's not hard to imagine that sometimes it is necessary use PS to selectively touch up the white balance of a digital photo taken in mixed lighting

Of course.  This is true simply as a matter of fact and not finessed by any other method.  What's nice is that, with recent versions of ACR, it is possible to apply selective WB.

So there are reasonable scenarios besides the presumably unreasonable jpeg white balance one.

In answer to Jack's original question, I think that one has more control over the conversion to sRGB if the conversion and gamut-mapping to the smaller sRGB space is saved for the end, because then you have the full controls of PS to deal with any out-of-gamut colors. By going camera space -> ProPhoto -> edit -> sRGB, you have the opportunity to identify out-of-gamut colors and smoothly bring them into gamut by selective desaturation. If instead one converts to sRGB at the very start, you really have no control over the mapping of the out-of-gamut colors - in most cases they will be simply chopped down to the gamut boundary.

You're a better man than I.  I've done just what you advocate -- did it for years.  I processed in ProPhoto RGB as a matter of course and ended up with beautiful images on my wide-gamut monitor.  Then when I went to "selectively desaturate" the OOG colors in soft proofing to reduce the space for printing or for the web, the degree of selective desaturation that was required to undo all the beauty that ProPhoto RGB created resulted in "selective colors" that were dull as dirty dishwater -- downright unpleasant.

If it didn't work for you, I can understand your position.

I was better off in these cases simply printing from the ProPhoto RGB space using the printer's profile without any adjustments.  The OOG colors were considerably less vibrant than on screen, but they were a heck of a lot better than the "controlled" adjustments of which you speak.  Better yet were the same images processed in Adobe RGB, which more nearly matches my Pixma Pro 9000 II's gamut.  Not much worse were those processed in sRGB.  As to web-destined images, the same holds, except that Adobe RGB is not as useful.

Output to a printer profile with its several available rendering intents is not comparable to output to the sRGB matrix profile.

So, I know what you're saying: it is, and has been, a common mantra.  But, in my experience, it is not borne out in fact.

"A common mantra" of some of the experts whose books and articles I have read over the years. It certainly works for me with the tools I use.

But, as the old saying goes, "suit yourself."

Cliff

Reply   Reply with quote   Complain
crames
Regular MemberPosts: 192
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to crames, Apr 30, 2013

Speaking of experts, here is a brief article by Jeff Schewe that shows some of the effects of gamut clipping in sRGB and ProPhoto.

Jeff has posted in this thread, so maybe he will comment.

Reply   Reply with quote   Complain
Jack Hogan
Senior MemberPosts: 3,721Gear list
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to crames, Apr 30, 2013

crames wrote:

Speaking of experts, here is a brief article by Jeff Schewe that shows some of the effects of gamut clipping in sRGB and ProPhoto.

One of the early articles that conviced me to use MelissaD65 as a working color space for years, despite the fact that the visible difference was and remains minimal.  Several years later I have two questions in the context of this sub-thread (i.e. Camera-sRGB vs Camera-ProPhoto-sRGB)

1) Can you see a material difference between the two?
2) Even if you did, which one would be more 'correct'?

If someone can answer these two questions without bait and switching to answering a different question (is ProPhotoRGB bigger than sRGB?)  we may actually take a step further in the discussion.  In the meantime this is the file in the article opened in ACR 6.7 sRGB, CEP3 Tonal Contrast applied at default settings (left); and the same file opened in ACR 6.7 ProPhotoRGB, CEP3 TC at default and converted to sRGB (right).  I had to actually convert the right file to sRGB after applying TC in order for CS5 gamut warning (gray) to show.

Jeff has posted in this thread, so maybe he will comment.

That'd be great.

Jack

Reply   Reply with quote   Complain
crames
Regular MemberPosts: 192
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to Jack Hogan, Apr 30, 2013

Jack Hogan wrote:

crames wrote:

Speaking of experts, here is a brief article by Jeff Schewe that shows some of the effects of gamut clipping in sRGB and ProPhoto.

One of the early articles that conviced me to use MelissaD65 as a working color space for years, despite the fact that the visible difference was and remains minimal.  Several years later I have two questions in the context of this sub-thread (i.e. Camera-sRGB vs Camera-ProPhoto-sRGB)

1) Can you see a material difference between the two?
2) Even if you did, which one would be more 'correct'?

If you are converting in the usual ways - relative colorimetric intent in PS, standard sRGB and ProPhoto profiles, and without any editing while in ProPhoto to ameliorate gamut clipping, I don't think there will be any visible difference. The correct way under these conditions would be the direct Camera->sRGB, to avoid an extra color space conversion.

Another way to do it is to use the v4 ICC profiles for sRGB and ProPhoto, which contain perceptual intent tables for the purpose of performing a proper gamut mapping to the smaller space. I remember trying them but not getting good results.

Yet another approach was discussed a couple years ago on LuLa by "jc" who developed a method using a profile for an intermediate-sized color space, also having a perceptual table. It seemed to work as advertised. The thread is a little hard to follow, but clarifies a few pages in.

If someone can answer these two questions without bait and switching to answering a different question (is ProPhotoRGB bigger than sRGB?)  we may actually take a step further in the discussion.  In the meantime this is the file in the article opened in ACR 6.7 sRGB, CEP3 Tonal Contrast applied at default settings (left); and the same file opened in ACR 6.7 ProPhotoRGB, CEP3 TC at default and converted to sRGB (right).  I had to actually convert the right file to sRGB after applying TC in order for CS5 gamut warning (gray) to show.

Jeff has posted in this thread, so maybe he will comment.

That'd be great.

Jack

Reply   Reply with quote   Complain
Jack Hogan
Senior MemberPosts: 3,721Gear list
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to crames, Apr 30, 2013

crames wrote:

If you are converting in the usual ways - relative colorimetric intent in PS, standard sRGB and ProPhoto profiles, and without any editing while in ProPhoto to ameliorate gamut clipping, I don't think there will be any visible difference. The correct way under these conditions would be the direct Camera->sRGB, to avoid an extra color space conversion.

Ok

Another way to do it is to use the v4 ICC profiles for sRGB and ProPhoto, which contain perceptual intent tables for the purpose of performing a proper gamut mapping to the smaller space. I remember trying them but not getting good results.

I have a V4 profile for sRGB but not ProPhotoRGB.  Is there a problem to mix and match?

Yet another approach was discussed a couple years ago on LuLa by "jc" who developed a method using a profile for an intermediate-sized color space, also having a perceptual table. It seemed to work as advertised. The thread is a little hard to follow, but clarifies a few pages in.

Very interesting thread.  Is it worthwhile to go through the double conversion process?  Is anybody using his 'perfect' color space?

Reply   Reply with quote   Complain
gollywop
Veteran MemberPosts: 5,554
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to Jack Hogan, Apr 30, 2013

Ok, here is a quartet of processing.

Upper left: ProPhoto RGB in ACR to acceptable rendering —> to ProPhoto RGB in CS6, adjustments (curves, selective saturations) made while soft proofing in sRGB with OOG indicator on to remove as much (90%) of OOG as possible (i.e., before it became absurd) —> sRGB.

Upper right: ProPhoto RGB in ACR to acceptable rendering —> make adjustments in ProPhoto RGB to predict conversion to sRGB (i.e., make adjustments, convert to sRGB, check histogram, if ok, fine, if not ok, go back make more adjustments, convert, check histogram, etc., until the conversion is good) —> sRGB.

Lower left: ProPhoto RGB in ACR to acceptable rendering —> sRGB in CS6, make adjustments with selective saturation and curves to produce decent histogram —> stay sRGB.

Lower right: sRGB in ACR to acceptable rendering —> some adjustments to brightness, contrast in CS6 —> stay sRGB

I should note that the initial raw file here is about 1EV underexposed according to RawDigger.  The ACR histogram shows a modest gap at the right when using ProPhoto RGB, and it is stacked hard against the right-hand edge when using sRGB.

I should also note that the bottom two look a great deal more like the original (viewed in ProPhoto RGB in ACR on a wide-gamut monitor).  They are no where nearly as bright and vibrant as the original, but, as I say, much more like the original than either of the top two.

As to a choice between the bottom two, each has its value (but there is no question about which is the easier to produce).

-- hide signature --

--
gollywop

Reply   Reply with quote   Complain
crames
Regular MemberPosts: 192
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to gollywop, Apr 30, 2013

gollywop, for further comparison and experimentation would you please make the original ProPhoto version available?

Cliff

Reply   Reply with quote   Complain
gollywop
Veteran MemberPosts: 5,554
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to crames, Apr 30, 2013

crames wrote:

gollywop, for further comparison and experimentation would you please make the original ProPhoto version available?

I'd be happy to, Cliff.  If Jack says it's all right, I'll ship it to him to post.  I'd also be pleased to see what you can do with it.  You seem to have more skill with method 1 than I do.

Jack, can I mail the dng to you for distributing?

-- hide signature --

gollywop

Reply   Reply with quote   Complain
crames
Regular MemberPosts: 192
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to Jack Hogan, May 1, 2013

Jack Hogan wrote:

I have a V4 profile for sRGB but not ProPhotoRGB.  Is there a problem to mix and match?

I'm pretty sure they both should be v4 in order to make use of the perceptual Profile Connection Space. Here are v4 variations on RIMM RGB (ProPhoto's linear cousin).

Some implementation details can be extracted from this:

I haven't really studied this v4 stuff, so I hope I'm not steering you wrong..

Yet another approach was discussed a couple years ago on LuLa by "jc" who developed a method using a profile for an intermediate-sized color space, also having a perceptual table. It seemed to work as advertised. The thread is a little hard to follow, but clarifies a few pages in.

Very interesting thread.  Is it worthwhile to go through the double conversion process?  Is anybody using his 'perfect' color space?

I haven't seen anything about it since that thread ended 2 years ago, nor have I used it since testing it back then, only because I seldom need to do those kinds problematic conversions. When I tested it, it did work and preserved hues well. We can try it on golliwop's flower and see how it does.

Cliff

Reply   Reply with quote   Complain
crames
Regular MemberPosts: 192
Like?
Re: Camera-->sRGB versus Camera-->ProPhoto-->sRGB
In reply to crames, May 1, 2013

crames wrote:

Jack Hogan wrote:

I have a V4 profile for sRGB but not ProPhotoRGB.  Is there a problem to mix and match?

I'm pretty sure they both should be v4 in order to make use of the perceptual Profile Connection Space. Here are v4 variations on RIMM RGB (ProPhoto's linear cousin).

Some implementation details can be extracted from this:

Here is the link I omitted.

Reply   Reply with quote   Complain
Keyboard shortcuts:
FForum MMy threads