In-gamut translations

wrote:

Given a safely in-gamut color, can an arbitrarily high number of trips be made between standard models and their spaces with the expectation that the result will exactly equal the original color?

According to well-known authors like Dan Margulis, Deke McClelland and Bruce Fraser you can convert many times between Lab and RGB modes without *seeing* a degradation, but if you simply draw a gradient and look at the histogram and then convert to Lab and back to RGB and check the new histogram you’ll see the "fuzz" gets smoothed off the gradient so there is clearly some change. Just not noticeable color-wise.

If you mean between say sRGB and say AdobeRGB then I really doubt the "result will exactly equal the original color" numerically, but should be pretty close visually … but it’s trivial to check this … just make an action that converts to and from a space, note down the RGB values of a few in-gamut color patches, and then run the action 20 (or how every many) times and look at the final RGB values.

Bill

Bill Hilton wrote:

If you mean between say sRGB and say AdobeRGB then I really doubt the "result will exactly equal the original color" numerically, but should be pretty close visually … but it’s trivial to check this … just make an action that converts to and from a space, note down the RGB values of a few in-gamut color patches, and then run the action 20 (or how every many) times and look at the final RGB values.

Bill

Hi Bill,
Thanks for the info. I am surprised by this. If I was going to propose a rendering algorithm, one of the target behaviors at the top of my list would be that unless forced to by destination space considerations e.g. a white or black point mismatch between the source and destination space or maybe the need to compress or expand colors to get the out of gamut source colors to fit, then the integrity of all colors would be protected. I do not understand why an algorithm should make unnecessary changes.

Brgds,
Ron

wrote in message

Bill Hilton wrote:

If you mean between say sRGB and say AdobeRGB then I really doubt the "result will exactly equal the original color" numerically, but should be pretty close visually … but it’s trivial to check this … just make an action that converts to and from a space, note down the RGB values of a few in-gamut color patches, and then run the action 20 (or how every many) times and look at the final RGB values.

Bill

Hi Bill,
Thanks for the info. I am surprised by this. If I was going to propose a rendering algorithm, one of the target behaviors at the top of my list would be that unless forced to by destination space considerations e.g. a white or black point mismatch between the source and destination space or maybe the need to compress or expand colors to get the out of gamut source colors to fit, then the integrity of all colors would be protected. I do not understand why an algorithm should make unnecessary changes.

Most of the numeric changes are due to quantization. Some people attach great significance to this, but the changes are generally very small compared to the noise that is characteristic of an actual photograph. —
Mike Russell
www.curvemeister.com/forum/

Mike Russell wrote:

Most of the numeric changes are due to quantization. Some people attach great significance to this, but the changes are generally very small compared to the noise that is characteristic of an actual photograph. —
Mike Russell
www.curvemeister.com/forum/

Quantization, of course, this all stems from the original sensor data being discrete – in my camera’s case 12 bits. Why doesn’t Photoshop just convert everything coming in into high precision floating point?

Thanks,
Ron

Ron,

Mike is IMO right. Some years ago we had an avalanche
of cute posts about ‘gaps in the histogram’.
For a printed image the underlying source image pixels
are interpreted totally new.
Gaps in the source image histogram are easily filled
by dithering.
Therefore it turned out that these fashionable inter-
pretations were wrong – gaps don’t affect the printed
quality.

RAW images can be converted into PhS pseudo 16-bit-
per-channel, e.g. by Nikon Capture.

Best regards –Gernot Hoffmann

wrote:

Mike is IMO right.

I never doubted it.

Gaps in the source image histogram are easily filled
by dithering.
Therefore it turned out that these fashionable inter-
pretations were wrong – gaps don’t affect the printed
quality.

RAW images can be converted into PhS pseudo 16-bit-
per-channel, e.g. by Nikon Capture.

My interest is purely academic. I do not have enough understanding of color management to justify leaving the RGB spaces at this poing anyway. I am just trying to get it all nailed down.

Best regards –Gernot Hoffmann

Thanks Gernot,
Ron

Bill Hilton wrote:

If you mean between say sRGB and say AdobeRGB then I really doubt the "result will exactly equal the original color" numerically, but should be pretty close visually … but it’s trivial to check this … just make an action that converts to and from a space, note down the RGB values of a few in-gamut color patches, and then run the action 20 (or how every many) times and look at the final RGB values.

..

wrote:
Hi Bill,
Thanks for the info. I am surprised by this. If I was going to propose a rendering algorithm, one of the target behaviors at the top of my list would be that unless forced to by destination space considerations e.g. a white or black point mismatch between the source and destination space or maybe the need to compress or expand colors to get the out of gamut source colors to fit, then the integrity of all colors would be protected. I do not understand why an algorithm should make unnecessary changes.

Round-off errors … I just ran one 15x on a few patches from a ColorChecker chart (dark skin, light skin, blue sky, foliage, blue flower etc) and the final AdobeRGB values are all within one digit per channel … http://members.aol.com/bhilton665/tests/conv_multi.jpg …

In ‘real life’ most of us would keep a master file and convert that to say sRGB for the web or a printer profile for printing, but would not do multiple conversions between spaces, so I don’t really see the point in all this …

Bill

Bill Hilton wrote:

I don’t really see the point
in all this …

Bill

I didn’t really have a point, just curious. Thanks for looking into it. It must get tiresome for the experienced members to see the same old topics come up again and again. A lot of times a question will just pop into my head and I will not do the research before posting. I try to balance the karma by contributing to the group when I can.

Brgds,
Ron

wrote:

Why doesn’t
Photoshop just convert everything coming in into high precision floating point?

Thanks,
Ron

Since this went unanswered I assume there is something I am missing. But I do not see why it is nonsense because my HP28C calculator does something similar by using a kind of symbolic integer arithmetic for purposes of display while internally doing all calculations in high precision floating point. Even when the calculator is in a low precision floating point mode there are ordinarily no quantization (other than the inevitable) errors because internally the calculator is still processing in high precision mode – it just displays the results in low precision. Why can’t Photoshop work this way?

Thanks,
Ron

wrote:

wrote:

Why doesn’t
Photoshop just convert everything coming in into high precision floating point?

Thanks,
Ron

Since this went unanswered I assume there is something I am missing. But I do not see why it is nonsense because my HP28C calculator does something similar by using a kind of symbolic integer arithmetic for purposes of display while internally doing all calculations in high precision floating point. Even when the calculator is in a low precision floating point mode there are ordinarily no quantization (other than the inevitable) errors because internally the calculator is still processing in high precision mode – it just displays the results in low precision. Why can’t Photoshop work this way?

Thanks,
Ron

I’m just guessing but most likely it’s a design trade-off between processing speed and precision.

As you can see from the example I provided even 15 conversions between working spaces would cause no visual difference and only a minor numerical difference, so who cares?

You could repeat the experiment with 16 bit instead of 8 bit starting values and probably find even less difference, so if this is really important to you then start working with 16 bit files.

Bill

Bill Hilton wrote:

I’m just guessing but most likely it’s a design trade-off between processing speed and precision.

Probably, but I bet the decision was made before everyone had 3 or 4 GHz machines – maybe CS3.

As you can see from the example I provided even 15 conversions between working spaces would cause no visual difference and only a minor numerical difference, so who cares?

I care, but I don’t care care care – it’s just interesting.

You could repeat the experiment with 16 bit instead of 8 bit starting values and probably find even less difference, so if this is really important to you then start working with 16 bit files.

My default is 16 bit but I have to switch out quite a bit.

Thanks,
Ron

wrote in message

wrote:

Why doesn’t
Photoshop just convert everything coming in into high precision floating point?

Someday it will, probably, and cameras may capture directly to floating point format as well. Meantime, integer arithmetic remain an order of magnitude faster than floating point. To apply – for example – a curve to a channel, you would use floating point to load a table with 256 or 32K curved channel values. Once this lookup table is built use each channel value to index into the table – voila, almost instantaneous curving. Doing the same thing in pure floating point would be much slower, and only slightly more accurate.

There are some small optimizations that Photoshop does not bother with. For example, when you adjust both the RGB curve, and the individual channels, Photoshop does two layers of lookup – one for each channel, and a final lookup for the RGB curve. This leads to an addiitonal unnecessary quantization. Curvemeister – ahem – combines these into a single lookup operation, and the result is a very slightly faster, and more accurate result.

Since this went unanswered I assume there is something I am missing. But I do not see why it is nonsense because my HP28C calculator does something similar by using a kind of symbolic integer arithmetic for purposes of display while internally doing all calculations in high precision floating point. Even when the calculator is in a low precision floating point mode there are ordinarily no quantization (other than the inevitable) errors because internally the calculator is still processing in high precision mode – it just displays the results in low precision. Why can’t Photoshop work this way?

Not many people care if a calculator takes 2 microseconds or 2 milliseconds to show the answer, so it’s less critical to optimize this particular operation. Even so, a lot of expertise went into programming your calculator. There are other operations, such as calculating trig functions, use a lookup table initially, and then use floating point interpolation to clean up the result.
—

Mike Russell
www.curvemeister.com/forum/