Drawn out the woodwork yet again, Manfred. Glad you mentioned "carefully said"
With Adobe, any resemblance to ProPhoto a.k.a. Kodak ROMM is almost coincidental, it's that elephant-in-the-room thing ...
How about Melissa's sRGB white point and gamma, as opposed to D50 and 1.8?
Your understanding is incorrect, unless you can point me to an Adobe publication that says otherwise. Everybody and his dog knows that ProPhoto gamma is 1.8 and that ProPhoto white reference is D50!
What?Regardless, the way Adobe gets around the colour space issue is natively working in a very wide colour space.
I seem to remember reading that in an article written by one of the Lightroom engineers, but it's been a while so I could be wrong. Obviously not everyone and his dog does not know, including me.
The D50 illuminant is commonly used in the printing industry and in many ways it makes more sense than D65 in terms of the colour temperature for image viewing. I don't usually view printed images at high noon.
What I do care about is that Lightroom outputs to Photoshop in ProPhoto RGB, Adobe RGB , sRGB or Display P3 (which is one colour space I have never used). Melissa ends with the hand off.
Lightroom/ACR uses
Melissa RGB (ProPhoto primaries with a gamma of 2.2 instead of 1.8) to display the histogram
A linear version of ProPhoto RGB (ie no gamma) for image processing
Thanks Dave. I had forgotten about the linear gamma bit.
Here's one of the better explanations about that:
http://ptgmedia.pearsoncmg.com/impri...mRGB_Space.pdf
It includes the word "bastardized" and reveals who Melissa is.
Just to keep the pot boiling, elsewhere it says:
Glurk, geddit? . . https://sites.google.com/site/chromasoft/icmprofilesMelissa RGB is not an "official" color space, but is the combination of the ProPhoto color space, with an sRGB gamma curve.
I seem to recall that this has some good info but my connection is on a go-slow so I'll just post the link:
http://www.colourspace.xyz/the-truth...ur-management/
I think the Melissa gamma confusion results from the underlying working file being linear but the display and the histogram have the sRGB gamma (2.4+linear12.95 slope) applied. Could be wrong on that ...
Last edited by xpatUSA; 17th March 2018 at 05:21 AM.
Converting to a wider color space.
http://www.peachpit.com/articles/article.aspx?p=1660185
From that article step V
It seems to me it's a standard function in PS.
Maybe in LR too?
George
That dialogue box is a similar action to the edit/convert to profile menu. you get it anytime you open a file with a different profile to your working colour space.
I am no expert in this field, but did some experimenting a while ago when trying to learn about colour management. I had a picture of a very vibrant green car against a red fence. I processed the raw file to give me two jpegs, one in Adobe RGB profile and one in sRGB.
When i open the sRGB one in Photoshop it matters not what selection I make (use embedded or Convert ) it is still a much duller red and green than the Adobe RGB one.
If I take the AdobeRGB one and use "edit/convert to profile" to change it to a sRGB profile it looks duller. Try changing it back to Adobe RGB and it still looks dull, just like the sRGB ones.
So I am inclined to agree with Manfred that the process is a one way street. Once you have converted your image from AdobRGB to sRGB converting it back does not give you the original colours. It simply maps the (duller) colour to an AdobeRGB value.
I am using a wide gamut monitor and my reference her to "duller" is relative. Both profiles are actually very vibrant but the AdobeRGB one is significantly more so.
No one says it can't be done, but in general, there is no reason to do so because there is no gain from it.
There are a couple of reasons where I have done so:
1. I want to do a sky replacement and I am working in a wide-gamut colour space. I see an image on a stock site that has the sky I want. I download it and it is sRGB. Converting it to the wider colour space would be done at this point to make for a clean, seamless process.
2. If one is dealing with a very noisy image and one does not want to have colour shifts, an old Photoshop trick is to convert the image to CMYK and only do the noise reductions on the "K" or black layer only, where most of the luminosity (= noise) data is. If one wants to print on an inkjet printer, one has to go back to a RGB colour space.
George, in the article you point to, Kelby wrote:
If you read the rest of the article, he is consistent in this regard:While you might use Lightroom for your JPEG or TIFF images, there’s really no advantage to choosing ProPhoto RGB for them
In other words, if you are going to bake a color space into a file, choose the largest you can, because everything else is lost. The math is the math. When you collapse to a smaller color space and save a file in that space, there are no longer any data about colors outside that space. You could arbitrarily assign pixels to values outside of the space, but there is no information about where outside the space they should be mapped.if you work in sRGB, you’re essentially leaving out those rich, vivid colors you could be seeing. That’s why we either change our color space to Adobe RGB (1998) if you’re shooting in JPEG or TIFF, which is better for printing those images, or ProPhoto RGB if you shoot in RAW
This is one reason why many of us shoot raw and then work in the widest color space we can until the end. This puts off the inevitable data loss until the end, when you know which data loss is least problematic. if you are going to display on the web, sRGB is the best option; if you are going to print, it isn't.
George - let me try to show what is happening with a diagram.
Take an Adobe RGB image and convert it to an sRGB image and then convert back to an Adobe RGB image. The data in the final Adobe RGB image is identical to what I had as an sRGB. What is the advantage of going back as the colours are going to be identical to what one had in the sRGB colour space?
I would say this is a wrong conversion. See Ted's posts.
The question was not about the (dis)advantage of changing colour space but if it was possible or not. Both Adobe RGB picture's should be the same or nearly the same.
All colour management is doing is correcting the digital pixel values for the used output device. Simple said. When my output device is able to show green in a wavelength range from x to y then colour management must take care that the green digital pixel values are ok for the used sensor range in that colour and for that output device.
If my monitor can show green in a range of x1 till y1 nanometer and I want to use an image that has pixel values for a range of x2 till y2 nanometer, then I have to adjust those digital values.
George
No George, to be blunt the diagrams show what does happen when one converts from a wider colour space to a narrower one and then back, assuming that some of the colours are out of gamut for the narrower colour space.
The "special case" you are thinking about would only work out if all of the colours contained in the wider colour space are in-gamut for the narrower one. In that case, the colours will look the same when they are converted back. This would be what happens in the following diagram.
Colour management is something that is quite different. Colour management is all about ensuring that colours are correctly interpreted as they are passed from one device to the next; camera -> computer screen -> printer / paper. Where gamut comes into play is simply the ability to recreate all of the colours and how colours that cannot be re-created are handled; i.e. the rendering intent.
While the computer screen might be capable of reproducing more colours than we see in the image, the actual colour model used will restrict what can be seen. My main computer screen is Adobe RGB compliant, but if I view an sRGB image, the most colours I can see are the ones contained in the sRGB colour space. That is what colour managed applications do.
Last edited by Manfred M; 17th March 2018 at 03:40 PM.
It looks to me like as the difference between perceptual and calormatic. If changing from one colorspace to another there's no difference between in- or out-gamut. The step size of the individual channels has to be changed in order to use the other color space. So also for the "in-gamut" colors.
Give some reaction on Ted's post and link.
George
George it is neither. The colour space shows nothing more than the subset of colours out of the total colours that humans can see. A colour space is really a standardized mathematical model for defining that subset of colours that can be applied using computer software.
Gamut is just a way of saying "these are the colours this device can reproduce". Gamut is device specific. Out-of-gamut is just a technical way of saying "those colours that the device cannot reproduce".
If colours can be reproduced in one colour space and we switch to another, narrower one, not all of those colours can be described by the narrower colour space. Those have to be assigned new values so that they can be reproduced. Rendering intents are nothing more than descriptions as to how that is handled. The two diagrams I posted have nothing to do with rendering intents, although from a technical standpoint, a rendering intent would have to be applied to take the OOG colours and remap them to the narrower colour space.
The basic rule is simple: if data are lost, they can't be recovered. Any transformation of scale, including a transformation to a new color space, is reversible if it follows a known function and doesn't lose information. It is irreversible if it does.
George, what you have in mind simply doesn't happen in this context. If the color values were on a continuous scale, and if the mapping to the smaller color space was a simple functional rescaling, then what you want to be true would be true. For example, you could impose a simple linear tranformation of this form for each plane of the color space (let S be the standard deviation, M be the mean, X be the value, 1 be the wide space, and 2 be the smaller space):
X_2=(X_1-M_1)(S_2/S_1)+M_2
This would compress the color values to fit within the smaller space and would not lose any information. It would also be extremely ugly if the spaces were substantially different in spread because it would assign the wrong value to every single in-gamut pixel. In the digital world, however, even this isn't quite reversible because the scale is discrete, and some of the needed values of X_2 won't exist. The values of those pixels will have to be placed in the new scale by rounding or truncating, and as soon as that is done, one has lost information. If you wanted to reverse the transformation, you wouldn't know which of the pixels at the new value belong there.
The bigger issue is that no one would do this. If one did this to produce an sRGB jpeg starting with a ProPhoto representation, the results would be extremely ugly, as all in-gamut colors would be misrepresented. So as is evidenced by several of the posts above, that is not what actually happens. Once you move to a smaller space, you can't go back accurately because the mapping is not a function that can be reversed. Unless, of course, you are using a parametric editor, in which case nothing has been done to the original data; it is simply displaying a transformation that you can discard, rather than having to reverse it.
Last edited by DanK; 17th March 2018 at 09:38 PM.
Reading it all over again I think the subject has changed from "can I convert my workingspace to a wider colour space" to "what happens when I send the image to an output device with a smaller colour space"
Manfreds answer in post 15 was "No; it is a "one-way" operation only." In post 50 it could be done. It seemed to be a standard function in PS.
The arguments here are mostly dealing with what happens when that image is send to an output device with a smaller colour space with the choice between coloirmetric or perceptual rendering intent. Nothing is converted yet. That happens when send to the printer somewhere. And there the pixel values are changed.
I think I've declared it for myself. I only have no PS or LR.
George
It is obvious that you still do not understand George.
Time to close this thread.