|
Convert profiles in Capture NX2
 |
When converting color profiles in Capture NX2, I see quite significant shifts in the shadows. For example, when converting from Adobe RGB to sRGB, the shadow lights up. The shadow darkens when I do the opposite conversion.
For the conversions, I always used Perpetual and with Black Point Compensation checked.
When I do the same conversions in Adobe Photoshop CS3 with the same intent and BCP, I get different results depending on which conversion engine I use: Microsoft ICM or Adobe (ACE). Using Adobe (ACE) I don't see any significant shifts in shadow but with Microsoft ICM I see the opposite of what I see in NX2: AdobeRGB->sRGB conversion darkens the shadow while sRGB->Adobe RGB conversion lightens the shadow.
So now it comes to the question: what conversion engine is Capture NX2 using (on Windows Vista)? Perhaps it needs some optimization? That may explain the "color madness" I see.
www.flickr.com/groups/capturenx/discuss/72157620758441685/
Max
Fixed misspelling in title. - Barry
Originally posted at 8:35AM, 4 July 2009 PST
(
permalink
)
Barry Wallis (a group admin) edited this topic 4 months ago.
|
 |
"For example, when converting from Adobe RGB to sRGB, the shadow lights up. The shadow darkens when I do the opposite conversion."
Ah, the joys of gamma encoding in Int16 and Int8. Even if the SW works in float32 the results are stored in Int16 or Int8, and data becomes Clementine . . . lost and gone forever. sRGB and aRGB behave very different in the way the gamma encoding / decoding handle truncation errors @ both ends of the Luma scale.
Posted 4 months ago.
(
permalink
)
|
|
starfish235, your reply sounded like it is the inevitable fault of sRGB vs. aRGB or 8bit vs. 16bit. However the variations among applications (or settings) seem to suggest it is up to the application to handle this "truncation errors" in a better way.
It is apparent not all color managed apps are handling images the same way. Capture NX2 is quite different from Adobe Photoshop for just displaying an image.
Max
Posted 4 months ago.
(
permalink
)
|
|
I noticed in another thread where you've been experimenting with ICC Version 4. In the supporting documentation that you provided it notes that V4 is trying to clean up some of the ambiguity that still resides in V2.
One of the ambiguous areas in V2 is "black point compensation". This ambiguity leaves programmers some freedom in how they choose to handle the black point . . . i.e. to honor the standards intent or to honor the ICM "black point" . . . and you actually get to voice an opinion in this selection when you check the box by "black point compensation" . . .but when you close and re-open the file the programmer on the other end gets to make the choice . . . why??? . . . Well, that's because your original choice isn't recorded in the file. By selecting the box by "black point compensation", you're actually violating the intent of the new standard. The "black point" field has been removed from the current standard to minimize this potential conflict.
Edit: There is a round off or truncation error every time you take a trip into or out of the connection space . . . even if you come back to the same color space that you originally left.
sRGB -> LAB -> sRGB round trip:
- - - Perceptual mean 8-bit RGB code value error, mean ΔRGB = 0.225
- - - Perceptual maximum 8-bit RGB code value error, max ΔRGB = 3.28
LAB -> sRGB -> LAB round trip:
- - - Perceptual mean ΔE = 0.27
- - - Perceptual maximum ΔE = 4.20 {visible shade changes}.
Originally posted 4 months ago.
(
permalink
)
starfish235 edited this topic 4 months ago.
|
Would you like to comment?
Sign up for a free account, or sign in (if you're already a member).
|
|
Nikon Capture NX Users Group /
Discuss
Feed – Subscribe to Nikon Capture NX Users Group discussion threads
|
Deutsch
|
English
|
Español
|
Français
|
