Converting from sRGB to Adobe RGB (1998)

I'm spending a lot of time trying to understand the basics of colour

management with the aid of books and online tutorials. I hope I'm beginning

to get there but there's one thing that continuingly puzzles me thatI'm sure

the people here can easily resolve.

I understand that I can convert an image file from Adobe RGB to a narrower

gamut working space such as sRGB using the "Edit/Convert to profile" command

in CS2. I also understand that in the event that there are colours in the

original file that fall outside the sRGB gamut then they will be distributed

on the edge of or within the sRGB colourspace according to the rendering

intent I choose. If I'm misunderstanding things here it would help to tell me.

But my real issue occurs if I then want to do the reverse after having closed

the file after conversion. Does conversion to a smaller gamut working space

such as Adobe RGB to sRGB result in an irrevocable loss of data which prevents

me from recreating that file exactly as was in the original colour space by

converting back? Clearly if the answer is 'yes' then I can make and keep a

copy of any file I convert to a smaller gamut space; but I'd rather not.

Simplification: Think of it sort of like peeling an apple. Once the skin is gone, nothing will return it to its original lustre. This translates to "yes, it is an irreversable loss of data".

Note: Depending upon settings, there is a form of 'color-compression' that doesn't shave-off the data, but squishes colors closer together. Information is lost, but not quite as brutally as an apple-peeler ;-)

>> Does conversion to a smaller gamut working space such as Adobe RGB to sRGB result in an irrevocable loss of data...<<

Dave, yes this can happen. Rather than try to explain, I'll walk through a specific example.

Here's the example if you'd like to try it out, assuming you have Photoshop. Using an existing image, assign Adobe RGB (1998). Now, select a small area (or do the whole image if you prefer) and fill it with a specific color, R=34, G=164, B=211 will work nicely. I picked this out by using the Lab (CIELAB) values of L*= 60, a* = -40 and b* = -40. Note that these Lab values cannot exist in sRGB.

Now you have a set of data to play with. If you convert (from Adobe RGB (1998)) to sRGB, you should get something like R=0, G=166 and B=214. What has happened, sort of, is that one of the values could not go as far as it wanted to; it got down as far as 0, but could not go further. Consequently, we have lost a sense of what color the conversion was trying to get to; in other words, the color which was fine to start with happens to be out of gamut for sRGB.

If you now convert from sRGB back to Adobe RGB (1998), it should be something like R=93, G= 164and B=211. You can now see that a significant change happend to the red pixel, from 34 originally to 93. Green and blue still remain the same (or very nearly so). If your image DID NOT have any out of gamut colors, they should return very close to the original data.

As a point of interest, it turns out that all of the rendering intents give the same result going between these two synthetic spaces, so it doesn't matter. This was pointed out to me be another poster some time back. However, it's good practice to leave your converter set where you normally leave it, probably perceptual or rel colorimetric for printing.

Hope this clarifies things a bit.

"Does conversion to a smaller gamut working space such as Adobe RGB to sRGB result in

an irrevocable loss of data which prevents me from recreating that file exactly as was in

the original colour space by converting back?"

The short answer is that once you have converted an image to a smaller color space

converting back to a larger color space is pointless as you can't "unfold" the clipped gamut

range back to the original space. Without confusing by going into LAB values. lets say that

you have two colors one is just on the einside edge of sRGB color space (say 211, 112, 136

(I am making up these numbers BTW) while the the second colors RGB valuesare 222, 112,

136 and fall outside of sRGB. A theorectical conversion from the larger color space to

sRGB , now assigns 211, 112, 136as the new color value for the color that was out of

gamut. Can you thin kof a reconversion processthat could differentiate betwen the two

colorsoncvethey have the same RGB values?

What is confusing is that the scale, the ruler for two color spaces is marked i ntthe same .

In Adobe RGB 211/112/136 hasadifferent meaning than 211/112/136 in sRGB. Among

other things the spaces for between the numbers are different.

To use a metaphor: it's as if you are making soup and the recipe is only in percentages

not ounces and tablespoonsand teaspons. If a recipe calls for 75% of a pot unless you

know the size of the pot they are referring to you are goignto have trouble knowing

howmuch of what ingredientsyou'll need. and clearly 75% of a a 2 quart pot is not going

to fit in a one quart pot and755 of the one quart pot is only 37.5% of the 2 quart (I think I

havethat right :~)). You have to know the context for the numbers. Iamnot sure why this

is. I'd like to see it changed to a context independent scale

Hi David, Some more: First, I think rendering intents refer to printing output, rather than colour space conversions. At least I have never encountered this issue in discussions of spaces.

Second, the difference between converting a file from one space (or profile) to another, and assigning a different space (or profile) to a file. Converting changes the data in order to preserve the colour appearance; assigning does not change the data but changes the colour appearance - which makes sense when you think about it. Once you convert say from Adobe RGB to sRGB, then convert back, you lose the accurate rendition of the colour data that was located outside the sRGB gamut. Don't do it on your master file.

Third, practicalities. It is important to use a colour space, in which to do your file work, that has a gamut that closely corresponds to that of your capture method. If you use sRGB for your film output, you are going to see colour clipping for all observations in your composition that lie outside that small space. Not all scenes do, but many do. The colours that lie outside the restricted gamut will clip to the colour that lies on the 'wall' at the edge of the small colour space, rendering all such pixels the same colour tone. Many people actually like that look, such as the notorious Ken Rockwell - colours are big and bold because they are 'blocked up' with little tonal subtlety.

If you use an overly large gamut space, your file will suffer 'data stretching' as your observations are 'mapped' to the large space. I believe that errors introduced as a result of this process are called quantization errors, but could stand corrected on this.

It is even more important to archive files in compatible gamut spaces. I suggest either Adobe RGB [sometimes referred to as Adobe RGB (1998)] if you want compatibility with most output processes, or Joe Holmes EktaSpace (free) or Chrome Space 100 (not free but very good), recognising that you shoot chrome film. When you want to get Frontier prints done, or make web versions, you should copy your file and convert the copy to sRGB for that special purpose.

All monitors you can afford show only sRGB. Advanced pigment ink inkjet printers (like the K3 ink Epsons) are capable of printing colours that exceed Adobe RGB. Further reading: anything by Andrew Rodney (who posts here) and Joe Holmes, also Norman Koren, Outback; that will get you started! Try to stay clear of the PS cookbooks, even the much-lauded Bruce Fraser is quite impenetrable on these matters. My opinions only - cheers, philip.

If large-to-small gamut conversion is done by leaving colours already in the small gamut unchanged, and mapping ("projecting") other colours onto its boundary (e.g. nearest colour), then this is irreversible. If it is done by "squeezing" the large gamut to the small one, which involves adjusting colours that are already in the small gamut, then, in principle at least, you can reverse the process, but since colour spaces are discrete in practice, and 8-bits-per-colour is not very many, there will be a potentially significant loss of colour resolution. This would probably not be noticeable if you are working in 16-bits-per-colour. I do not know whether such "lossless" inversion is actually supported by the usual software, and in any case it is not the sort of operation that should be necessary in a well-planned workflow.

Raw files come labelled as AdobeRGB or sRGB, but this is only a flag to tell software how to "develop" them during conversion; it can be changed in the raw file, or over-ridden at conversion time, without loss, and even (if the raw file is rich enough to make it worth doing, and output devices can handle the result) replaced at conversion time with a gamut wider than AdobeRGB.

If large-to-small gamut conversion is done by leaving colours already in the small gamut unchanged, and mapping ("projecting") other colours onto its boundary (e.g. nearest colour), then this is irreversible. If it is done by "squeezing" the large gamut to the small one, which involves adjusting colours that are already in the small gamut, then, in principle at least, you can reverse the process, but since colour spaces are discrete in practice, and 8-bits-per-colour is not very many, there will be a potentially significant loss of colour resolution. This would probably not be noticeable if you are working in 16-bits-per-colour. I do not know whether such "lossless" inversion is actually supported by the usual software, and in any case it is not the sort of operation that should be necessary in a well-planned workflow.

Raw files come labelled as AdobeRGB or sRGB, but this is only a flag to tell software how to "develop" them during conversion; it can be changed in the raw file, or over-ridden at conversion time, without loss, and even (if the raw file is rich enough to make it worth doing, and output devices can handle the result) replaced at conversion time with a gamut wider than AdobeRGB.

yes.

but why would you like to get sRGB? for web or presentation purpose?

Thank you very much for your lucid answers, which have helped me a lot. I'm rather surprised that in the reading I've so far done (at least some of which I understand) I haven't come across a direct warning that conversion to a narrower working space irrevocably (or once the file is closed anyway) costs the ability to recreate the file as was. Maybe I've missed it.

I do now understand that if I convert a file to a ColourSpace with a narrower gamut, whether for web use or to use a particular printer, then I should make a copy and convert that, leaving my master file alone.

-->I think rendering intents refer to printing output, rather than colour space

conversions. -->At least I have never encountered this issue in discussions of spaces.

Simple matrix profiles like all those used to define RGB working spaces only have one

table, the Colorimetric table so the only rendering intents are Relative and Absolute

Colorimetric when doing such conversions. That's one reason the profiles are so small in

file size. If you pick Perceptual in Photoshop, it provides RelCol.

Printer profiles use look up tables or LUTs and are larger in size and contain all three

tables. This is a much more complex profile.

"I think rendering intents refer to printing output, rather than colour space conversions. At least I have never encountered this issue in discussions of spaces."

Not so - Photoshop includes options for both rendering engine and rendering intent in its "Convert to Profile" dialog box.

"Not so - Photoshop includes options for both rendering engine and rendering intent in its "Convert to Profile" dialog box."

Yes they are and you can set a rendering intent, but that's not the same as it having any effect. You can tinker and toggle to your heart's content (and I have, following Philip's post) and the image looks the same. Different story if your destination is a device rather than a workspace, and the explanation is given by Andrew Rodney above.