Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: papa v2.0 on February 23, 2015, 07:42:53 pm
-
I apologise it this has been done to death.
so if there is a thread ive missed just say so.
When I open a RAW in LR what space am I rendering in (Melissa/Prophoto?)
When I export (say to sRGB) does the colour space conversion take place then (clipping and all)?
Ta
Iain
-
When I open a RAW in LR what space am I rendering in (Melissa/Prophoto?)
When I export (say to sRGB) does the colour space conversion take place then (clipping and all)?
Yes and no. Yes, you are clipping at the point of conversion. No, it's not Melissa or ProPhoto RGB. Close, same gamut and primaries, different TRC. Has no name (Melissa is used for Histograms and RGB numbers).
-
Yes and no. Yes, you are clipping at the point of conversion. No, it's not Melissa or ProPhoto RGB. Close, same gamut and primaries, different TRC. Has no name (Melissa is used for Histograms and RGB numbers).
Andrew is, as usual, correct. The only thing I can add is that the tone response curve is linear -- some would say it's not a curve at all -- in Lr's native space. That makes a lot of operations less expensive (in terms of machine cycles) to execute.
Jim
-
Hi Andrew, Jim . Thanks to both.
I was thinking that was the case.
So the histogram is based on a rendering to Melissa which is a variant of ProPhoto.
There is no ability in LR to render directly to a smaller space with associated histogram, is that correct?
Unlike Camera Raw where one can select the render-space (choice of four) and the associated histogram before export.
Also, has the image on screen gone thought the selected colour space choice for export (say sRGB) or is it a straight internal colour space to monitor colour space conversion. (hope that makes sense).
and last but not least, why histogram readout in RGB% and can this be changed to RGB 255 etc
Iain
-
In soft proof the corresponding histogram is shown. In fact you can think of ACR as Lightroom with soft proof permanently on.
The on-screen image is always the standard source profile > display profile conversion.* In Develop the source is linear ProPhoto; for the Library previews the source is Adobe RGB. This, incidentally, is why a broken monitor profile can show up differently between the two modules.
In soft proof you have a 0 to 255 readout. It only makes sense in soft proof, where the numbers correspond to an actual color space. But you can get Lab numbers if that's any help.
*edit: Obviously, soft proof also limits display gamut by inserting the proof profile into the chain. But unless your monitor is wide gamut and you're proofing to sRGB, you won't see any difference on screen. The monitor color space is usually the limiting one.
-
Thanks D
Its all clear now. I was assuming that the same space was used for library and develop.
"In Develop the source is linear ProPhoto; for the Library previews the source is Adobe RGB. This, incidentally, is why a broken monitor profile can show up differently between the two modules"
Or a badly made monitor profile or a crap monitor can compound things.
Cheers.
-
I was assuming that the same space was used for library and develop.
For the processing of the data it is the same. For previews, it's different (frustrating design).
-
Unlike Camera Raw where one can select the render-space (choice of four) and the associated histogram before export.
In the more recent versions of ACR one can render into any number of color spaces, including L*a*b and even one's monitor space or printer space as shown in the screen capture below.
Also, has the image on screen gone thought the selected colour space choice for export (say sRGB) or is it a straight internal colour space to monitor colour space conversion. (hope that makes sense).
and last but not least, why histogram readout in RGB% and can this be changed to RGB 255 etc
The tone curve used for the readouts is merely a normalized sRGB tone curve converted from 0..255 to 0..1. To demonstrate this, I used Photoshop's posterize command to prepare a sRGB file with 10 monochrome levels and used Photoshop's info to read out the sRGB values. I then imported the file into Lightroom and read out the values as percentages and then converted the percentages back to 0..255 by multiplying by 255 as shown in the Excel spreadsheet below.
For a color image, the process would be more complicated, since the primaries in LR are those of ProPhotoRGB.
Bill
-
Yes and no. Yes, you are clipping at the point of conversion. No, it's not Melissa or ProPhoto RGB. Close, same gamut and primaries, different TRC. Has no name (Melissa is used for Histograms and RGB numbers).
Warning: this post is of interest only to image processing nerds.
When I write image processing code, my go-to representation for RGB color planes is double precision floating point, with the nominal black point 0,0,0 and the nominal white point 1,1,1. However, where it makes sense, and most of the time it does, I allow values below 0 and those above 1. This is especially useful in intermediate calculations. I suspect that Lr does something similar, although I'd expect them to use single precision (32-bit) floating point. Eric Chan, if you see this, could you set me straight?
If that's true, then the gamut of the Lr native color space is not limited to the gamut of PPRGB, since negative values would allow the gamut to be extended without limit to include even more nonphysical triplets and some that actually correspond to visible colors.
Jim
-
Im downloading PS cc as we speak.
I was using PS CS6 ACR re the four colour spaces.
Thanks Jim
and yes Andrew frustrating design and for the guys in my local camera club, its really confusing as well. They still havent got to grips with digital yet re the colour profiles.
They all have CC LR and PS but moan when nothing comes out right!
A colour scientists work is never done!
Iain
-
Warning: this post is of interest only to image processing nerds.
When I write image processing code, my go-to representation for RGB color planes is double precision floating point, with the nominal black point 0,0,0 and the nominal white point 1,1,1. However, where it makes sense, and most of the time it does, I allow values below 0 and those above 1. This is especially useful in intermediate calculations. I suspect that Lr does something similar, although I'd expect them to use single precision (32-bit) floating point. Eric Chan, if you see this, could you set me straight?
If that's true, then the gamut of the Lr native color space is not limited to the gamut of PPRGB, since negative values would allow the gamut to be extended without limit to include even more nonphysical triplets and some that actually correspond to visible colors.
Jim
Interesting thought.
To me that seems similar to the benefit of editing even an sRGB image in a wide working space. An sRGB image has no colours beyond its colour space but intermediate results of processing calculations might go beyond (and of course if you edit in a wide colour space you could create additional colours by screwing up the saturation!)
-
For the processing of the data it is the same. For previews, it's different (frustrating design).
You too, huh?
In LR4.4 having to turn on Soft Proof just to get 1.8 gamma ProPhotoRGB (my output space) histogram and RGB readouts is so annoying. And right behind it in annoyance is the subsequent warning dialog box after making the first edit asking if I want to make this the Proof or Proof Copy which I have no idea what the differences are.
-
You too, huh?
Yes but not as you understand what I wrote.
In LR4.4 having to turn on Soft Proof just to get 1.8 gamma ProPhotoRGB (my output space) histogram and RGB readouts is so annoying.
There's no visual difference (on this end) soft proofing either way. The numbers and Histogram change a bit due to the TRC which isn't an issue for me at all. The bkgnd will change too. The image? Not a lick.
What makes this architecture frustrating is having different behaviors for images in different modules! Having to tell people that if they suspect a preview issue with color, always be in Develop (don't necessarily bank on what you see outside that module). Also speed to render images to screen (the primarily reason I suspect we have two color spaces in different areas).
And right behind it in annoyance is the subsequent warning dialog box after making the first edit asking if I want to make this the Proof or Proof Copy which I have no idea what the differences are.
RTFM ;D
If you setup a soft proof and try to edit it, you are doing so with a new preview of the color so LR expects you to create a Proof Copy to apply it to and keep the original un-edited. Without layers, it would be folly to edit the master this way.
-
I wasn't referring to the preview change in my post, Andrew, just having to go through the trouble I indicated just to get RGB readouts and a histogram that reflects output.
I know what you meant by having two different preview setup differences between Library and Develop.
If you setup a soft proof and try to edit it, you are doing so with a new preview of the color so LR expects you to create a Proof Copy to apply it to and keep the original un-edited. Without layers, it would be folly to edit the master this way.
But switching Soft Proof to ProPhotoRGB as output in Develop module doesn't change the preview as you've said for both modules so what's your point? Or are you indicating the differences between "Make this the Proof" over "Proof Copy"? See how frickin' confusing and frustrating even talking about it is? We constantly talk at cross purposes over something as simple as Soft Proof and LR previews between two GUI's within the same app.
I'm going back to ACR 6.7 just cool off. And no, I'm not going to buy CS6 ACR which I'm sure someone was going to suggest. Oh good lord I'm so glad I'm not having to put up with this using Cloud apps. Just seeing the $10 a month reminder, update download alerts and/or seeing it on my credit card statement would set me off.
-
I wasn't referring to the preview change in my post, Andrew, just having to go through the trouble I indicated just to get RGB readouts and a histogram that reflects output.
It doesn't visually change only because you insist on setting up ProPHoto RGB as a soft proof and the data you see is basically in ProPhoto RGB! If you select another color space, the preview will very likely change because you are far farther from the original and editing that data must and should be done on a VC, NOT THE MASTER!
I know what you meant by having two different preview setup differences between Library and Develop.
We're not ready to do there yet. But the preview architecture and color spaces used are NOT the same between Develop and the other modules.
But switching Soft Proof to ProPhotoRGB as output in Develop module doesn't change the preview as you've said for both modules so what's your point?
My point is you are criticizing a behavior based on your own misunderstanding! IF you switch the master color space, you are forced to continue editing on a Proof Copy and that makes total sense.
Or are you indicating the differences between "Make this the Proof" over "Proof Copy"?
Same thing!
See how frickin' confusing and frustrating even talking about it is?
I admit I see how confused you are. ::)
I'm going back to ACR 6.7 just cool off.
Good idea. When you're ready to understand the architecture in LR in terms of editing upon a soft proof in a workflow, we're here to attempt to assist you.
-
When I open a RAW in LR what space am I rendering in (Melissa/Prophoto?)
the sequence of color transforms is described here = http://wwwimages.adobe.com/content/dam/Adobe/en/products/photoshop/pdfs/dng_spec_1.4.0.0.pdf
-
When I open a RAW in LR what space am I rendering in (Melissa/Prophoto?)
When I export (say to sRGB) does the colour space conversion take place then (clipping and all)?
the sequence of color transforms is described here = http://wwwimages.adobe.com/content/dam/Adobe/en/products/photoshop/pdfs/dng_spec_1.4.0.0.pdf
A longer list of colour spaces used by Lightroom:
- The image is always stored in its original colour space
- Lightroom Develop module uses ProPhoto RGB with a linear Tone Response Curve as its working space for processing, and uses ProPhoto RGB with sRGB's TRC for histogram and pixel values shown under the histogram. ProPhoto RGB with sRGB TRC is what is referred to as "Melissa RGB".
- Library module uses previews that are Adobe RGB.
- As I recall, Web module uses sRGB to preview the web site, but I might have remembered that wrongly.
- When you export or use Edit In... it uses whatever colour space you specify. Any clipping resulting from the rendering intent is done then (but you can use Soft Proofing in Develop module to get a preview).
The colour spaces used internally are fixed - you can't alter the working space as you can in Photoshop, for example.
-
Warning: this post is of interest only to image processing nerds.
When I write image processing code, my go-to representation for RGB color planes is double precision floating point, with the nominal black point 0,0,0 and the nominal white point 1,1,1. However, where it makes sense, and most of the time it does, I allow values below 0 and those above 1. This is especially useful in intermediate calculations. I suspect that Lr does something similar, although I'd expect them to use single precision (32-bit) floating point. Eric Chan, if you see this, could you set me straight?
If that's true, then the gamut of the Lr native color space is not limited to the gamut of PPRGB, since negative values would allow the gamut to be extended without limit to include even more nonphysical triplets and some that actually correspond to visible colors.
Jim
I suspect that this is similar to the approach taken in the beta versions of the upcoming release of Iridient Developer, where the internal working color space is based on ACES (ACES + sRGB tone curve) but processing controls and feedback (curves, histogram, etc.) can be viewed in any user-selected color space via an accompanying dropdown menu, making control and feedback for the user more clearly defined.
From the ID webpage for the beta:
http://www.iridientdigital.com/products/rawdeveloper_history.html
The "Working Profile" popup menu has been moved to the Curves tab panel and relabeled "RGB Curves Color Space" as this option is now only applicable to the RGB curves adjustments.
I have switched the RGB Curves Color Spaces for all camera defaults to the Iridient Internal RGB spaces (base on ACES plus sRGB tone curve). I was using an inconsistent mix of sRGB, AdobeRGB, MelissaRGB and ProPhoto in the past depending on camera model. Without any RGB curve edits this change has no impact, but this should help make many user's experience with editing RGB curves more consistent going forward
and
I have now fully transitioned to a new super wide gamut (color range) internal RGB color space for some operations which is based on the ACES (Academy Color Encoding System) color primaries. This is a bit wider and more specifically designed for use with data from modern digital sensors in mind. My previous internal RGB space which was based on ProPhoto primaries that are also very wide gamut, but primarily designed many years ago primarily for film based workflows.
kirk
-
I suspect that this is similar to the approach taken in the beta versions of the upcoming release of Iridient Developer, where the internal working color space is based on ACES (ACES + sRGB tone curve) but processing controls and feedback (curves, histogram, etc.) can be viewed in any user-selected color space via an accompanying dropdown menu, making control and feedback for the user more clearly defined.
From the ID webpage for the beta:
http://www.iridientdigital.com/products/rawdeveloper_history.html
Keep it up, Brian!
Jim
-
It doesn't visually change only because you insist on setting up ProPHoto RGB as a soft proof and the data you see is basically in ProPhoto RGB! If you select another color space, the preview will very likely change because you are far farther from the original and editing that data must and should be done on a VC, NOT THE MASTER!
The data and histogram I see without Soft Proof on is reflecting output of what? Linear with all the Adobe LR default tones applied which would explain why the histogram isn't slammed to the left on a new Raw master in Develop module? Is that correct?
The thing about LR is that images and their edits are in a constant state of perpetuity until the edits are committed to export to a tiff or jpeg so while in LR with Soft Proof turned off the data reflected in the histogram and "%" numbers have very little connection to what's reflected in the preview with regard to measuring and defining the preview through HSL or RGB analysis. Do I have that correct?
I never tried changing Soft Proof setting from ProPhotoRGB to another matrix profile to test to see a preview change, but if I understand you right (despite my doubts I'm able to), if I decide to Soft Proof to a printer profile with edits made using Soft Proof set to ProPhotoRGB on the "Make This The Proof" (I assume this means the master IS the proof) selection, the printer Soft Proof will only reflect the edits applied/encoded on the original master when Soft Proof was off and reflecting Linear with Adobe Default settings applied. Is that right?
I've never printed out of LR, yet, but I can't Soft Proof my printer anyway due to the fact I use Printer Manages Color for my little Epson All In One. So to make this less complicated and more manageable, I'm assuming I shouldn't even turn Soft Proof on to reflect ProPhotoRGB output working on the master and not a VC-(I really don't like making VC's because it creates duplicate thumbnails in Library Grid mode as mentioned above).
I'm having trouble remembering and sorting out in Library Grid mode which are the master and VC or Proof Copy even though I know the icon for VC is the turned page corner in the lower left of the thumbnail. I don't know if that's a Proof Copy VC or just a plain VC and if there is a difference. It turns into a rats nest of duplicate thumbnail previews where you have to look very carefully at those tiny icons.
I'm trying to make LR work like ACR with regard to workflow and thumbnail managing in Library mode and this Soft Proofing thingy on a master or VC or Proof Copy is just too much to rap my head around and keep organized in my head. I'm never going to print out of LR or need Soft Proofing to a printer anyway.
I should keep Soft Proof off if I'm working on the master file if I want to make LR work like ACR.
-
The data and histogram I see without Soft Proof on is reflecting output of what?
Melissa RGB. ProPhoto RGB with a different TRC than ProPhoto (2.2) BFD.
The thing about LR is that images and their edits are in a constant state of perpetuity until the edits are committed to export to a tiff or jpeg so while in LR with Soft Proof turned off the data reflected in the histogram and "%" numbers have very little connection to what's reflected in the preview with regard to measuring and defining the preview through HSL or RGB analysis. Do I have that correct?
When you soft proof, what you see is what you will get, visually and numerically after rendering through LR. Setup a soft proof for Epson 3880 Luster, that's what you get to see before a conversion to that output color space. Since you have asked LR to simulate the appearance, numbers and histogram (based on a RI as well), AND you decide at this point to edit that data, the rational of the workflow process is now set for you: you apply output specific (or different from the master) edits so based on that new appearance and path, to a Proof Copy. ACR can't do that.
I never tried changing Soft Proof setting from ProPhotoRGB to another matrix profile to test to see a preview change, but if I understand you right (despite my doubts I'm able to), if I decide to Soft Proof to a printer profile with edits made using Soft Proof set to ProPhotoRGB on the "Make This The Proof" (I assume this means the master IS the proof) selection, the printer Soft Proof will only reflect the edits applied/encoded on the original master when Soft Proof was off and reflecting Linear with Adobe Default settings applied. Is that right?
The Proof Copy workflow has nothing to do with the kinds of profiles, color space etc. You've got a master image shown to you one way in Melissa RGB. You switch that by setting a soft proof based on another color space. Either kind or profile, working space or output. The image on screen might change, it might not (toggle from ProPhoto to Adobe RGB (1998) or even sRGB, depending on the image, it might appear the same on-screen). The numbers and histogram will change. But you've told LR you want to work in another color space (fine) but further you now tell LR you want to apply an edit. Boom, you must and should do this on a proof copy! The master is untouched just as if you duplicated an image in PS and applied adjustment layers for output specific edits on the copy.
All the other comments to follow you've made are immaterial to the above workflow you appeared to misunderstand and criticize:
And right behind it in annoyance is the subsequent warning dialog box after making the first edit asking if I want to make this the Proof or Proof Copy which I have no idea what the differences are.
-
So a Proof Copy is not a Virtual Copy. IOW a duplicate of the master isn't made by either choosing "Make This The Proof" or "Proof Copy" when turning on Soft Proofing and getting that dialog box prompt.
I was under the impression that the xmp edits were the non-destructive method that gets embedded in the master over having to create a duplicate using Virtual Copy.
-
So a Proof Copy is not a Virtual Copy.
It is a specific type of VC yes.
-
I'd just like to add that gamma can be a quite confusing concept these days. This is because much of it just relates to internal color math and is rarely something the photographer needs to bother with.
In digital photography the purpose of gamma encoding is to make best use of integer math so you don't waste most of your integer steps on the very last bit of highlights. Since Lightroom and most recent photo software works in floating point space gamma has lost its meaning for the internal math. Lightroom uses ProphotoRGB primaries / RIMM space but don't need to apply the 1.8 gamma as it's floating point. Then this internal prophoto floating point image is converted via the display's ICC profile so you'll see the colors the display can handle. I assume the conversion is perceptual intent, but I'm not sure. Then there's softproofing of course, discussed above.
However, the curves tool and histogram must be displayed with a gamma, otherwise the topmost stop would take up half of the space and as our eyes have an exponential sensitivity that would not make sense. I don't know what Lightroom uses for the curves and histogram (and the 0-255 values under the picker), but I would expect gamma 2.2.
The most common file formats, 8 bit jpeg and 16 bit tiff, are both integer format so they need gamma encoding, this is made automatically at export so the user doesn't need to care. Many applications today can export/import floating point tiff, and what happens if you export a floating point tiff with ProphotoRGB color space? Gamma enconding makes no sense in floating point, so the correct way would be to encode linear, embed an ICC profile which looks like the ProPhotoRGB but has linear gamma. Defacto standard has however become that if floating point assume linear gamma and ignore gamma of the profile, so it's not uncommon that a floating point tiff contains the original ProphotoRGB icc profile with gamma, but if you apply the gamma the image will render incorrectly.
Anyway if digital color management had been created today when floating point math is always available and fast we would probably talk much less about gamma and color spaces with gamma. It still makes sense with integer gamma encoded formats for compression, but the whole color management pipeline could be floating point.
-
I'd just like to add that gamma can be a quite confusing concept these days. This is because much of it just relates to internal color math and is rarely something the photographer needs to bother with.
In digital photography the purpose of gamma encoding is to make best use of integer math so you don't waste most of your integer steps on the very last bit of highlights. Since Lightroom and most recent photo software works in floating point space gamma has lost its meaning for the internal math. Lightroom uses ProphotoRGB primaries / RIMM space but don't need to apply the 1.8 gamma as it's floating point. Then this internal prophoto floating point image is converted via the display's ICC profile so you'll see the colors the display can handle. I assume the conversion is perceptual intent, but I'm not sure. Then there's softproofing of course, discussed above.
However, the curves tool and histogram must be displayed with a gamma, otherwise the topmost stop would take up half of the space and as our eyes have an exponential sensitivity that would not make sense. I don't know what Lightroom uses for the curves and histogram (and the 0-255 values under the picker), but I would expect gamma 2.2.
The most common file formats, 8 bit jpeg and 16 bit tiff, are both integer format so they need gamma encoding, this is made automatically at export so the user doesn't need to care. Many applications today can export/import floating point tiff, and what happens if you export a floating point tiff with ProphotoRGB color space? Gamma enconding makes no sense in floating point, so the correct way would be to encode linear, embed an ICC profile which looks like the ProPhotoRGB but has linear gamma. Defacto standard has however become that if floating point assume linear gamma and ignore gamma of the profile, so it's not uncommon that a floating point tiff contains the original ProphotoRGB icc profile with gamma, but if you apply the gamma the image will render incorrectly.
Anyway if digital color management had been created today when floating point math is always available and fast we would probably talk much less about gamma and color spaces with gamma. It still makes sense with integer gamma encoded formats for compression, but the whole color management pipeline could be floating point.
AFAIK it's as you say, except that histograms and colour picker use sRGB's TRC, so roughly 2.2 gama except at the black end. (The colour picker uses %, not 0-255). The develop module working space is ProPhoto with linear TRC as you say, library module displays the cached previews, which are in Adobe RGB and web module (I seem to recall) uses sRGB.
-
I wonder which histogram linear ProphotoRGB vs output gamma when turning on Soft Proof reflects LR's built-in highlight compression that can't be turned off?
-
Melissa RGB uses the sRGB TRC (it is not a gamma curve). The underlying data is processed using a linear gamma (1.0). Not sure why anyone would need to see this but it is possible to build and use a 1.0 TRC gamma variant of ProPhoto RGB within LR (build one in Photoshop's Color Settings). Most users don't have to worry a lick about gamma or the TRC of any of the spaces they are working with.