Pages: [1]   Go Down

Author Topic: Working color space conversion accuracy  (Read 4928 times)

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Working color space conversion accuracy
« on: October 10, 2014, 03:51:59 pm »

There is a persistent legend in the digital photography world that color space conversions cause color shifts and should be avoided unless absolutely necessary. Here's a quote from a recent post on LuLa.

Quote
Round trips between colorspaces lose both precision and accuracy, so the main thing is to avoid this. Profiles are necessary evils, but profile conversions really are horrible and should be kept to a minimum.

Although I'd not put it that strongly, I've had inklings of that attitude myself. In my case, it was based on old experience. Fifteen years ago, with 8-bits per color plane precision ruling the land, there were strong reasons for that way of thinking, but times have changed. I thought that another look was in order. I've spent the better part of the last two weeks working on this project, and have been surprised and pleased by what I found.

Here's the take-home lesson: Accurately implemented model-based conversions among RGB color spaces with quantizing to 15 or 16 bit unsigned integer precision, and/or conversion from those spaces to CIEL*a*b* and CIEL*u*v* cause negligible errors.

That's a strong statement, and it flies in the face of conventional wisdom. I expect that you'll demand proof, and I hope to supply it, although not all in the first post.

First, some caveats: The above statement only applies to images where all colors are within the gamut of the destination color space. It also may only apply to algorithmic conversions, not those performed through table lookup and interpolation. I haven't tested any table-based conversions.

Here's a third caveat, and one that bit me several times during this project: make sure that the color spaces are well-defined and implemented properly. I wasn't using ICC profile for some of my work, and used an image that was encoded in a color space with the sRGB primaries and white point, but with a gamma of 2.2, thinking it was encoded in the IEC 61966-2-1:1999 color space, which has a different nonlinearity. It took me several days to track down the problem.

Also, let me invite whoever's interested to replicate (or fail to replicate, and that's interesting, too) my results. If you PM me, I can send you my Matlab code, although it would be a better test if you didn't peek at it.

Let's start out with no integer quantization, with the color space conversion algorithms implemented in double precision floating point and the images stored in that representation. If we take the following 14 RGB color spaces:

    IEC 61966-2-1:1999 sRGB
    Adobe (1998) RGB
    ProPhoto RGB
    Joe Holmes’ Ektaspace PS5
    SMPTE-C RGB
    ColorMatch RGB
    Don-4 RGB
    Wide Gamut RGB
    PAL/SECAM RGB
    CIE RGB
    Bruce RGB
    Beta RGB
    ECI RGB v2
    NTSC RGB

(Take a look at Bruce Lindbloom's web site for definitions of all of the above).

And we take as a test image all 16+ million colors that can be encoded in 8-bit sRGB with all colors mapped to a color set that falls within the gamut of all 14 color spaces, and perform chained (with processing of the white point performed using the calculations associated with what the ICC would call "relative colorimetric" intent) conversions from the current color space to one chosen at random (except that the current space is not allowed), and measure the difference in CIELab DeltaE of the pixel that is farthest from its value in the original image, we get the following curve:



The worst error, even after 100 iterations, is a few trillionths of a Lab DeltaE. The conversion algorithms themselves are quite accurate.

If we quantize to 16 bit unsigned integers after every conversion, we see this:



Now the worst-case error after 100 iterations is less than a tenth of a DeltaE.

There are those who say that Photoshop processes images with 16-bit color depth using 16-bit precision.

Here are the worst case results with 15-bit quantization after every conversion:



In the bad old days, we used 8-bit precision. What does this test do with that?




Not very good, huh?

There's a lot more to be said, and I'll be making some more posts. If you want more details on what's in this one, look here:

http://blog.kasson.com/?p=7517

Thanks for reading this far. Comments and questions are solicited.

Jim


« Last Edit: October 10, 2014, 04:57:01 pm by Jim Kasson »
Logged

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Working color space conversion accuracy
« Reply #2 on: October 10, 2014, 04:54:04 pm »

http://blog.lexa.ru/2007/11/19/oshibki_pri_obrabotke_cveta_i_8bitnie_izobrazhenij.html ("8-bit" )
http://blog.lexa.ru/2007/11/22/oshibki_pri_obrabotke_cveta_ii_16_bit_gamma_22_mat.html ("16-bit" )

Very interesting. Thanks. I note that we chose the same target image. However, we have quite different error metrics and choices of conversions. I've done trips to Lab and back, and will report shortly. Also, I'm starting this series of posts with conversions that are performed by mathematically implementing the color models, whereas the above looks at CMSs that we can use. I'll get there -- although not anywhere near as exhaustively as above, but I think it's useful to understnad the best that can be achieved -- without regard for computational cost -- first. By the way, I have been computing errors in CIELuv DeltaE as well, though I'm not graphing them because that color space, although preferred over Lab by me, is less familiar to most people here, or so it appears.

Jim

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Are some RGB working space conversions worse than others?
« Reply #3 on: October 10, 2014, 05:36:11 pm »

Yes, indeed, but not by as much as I’d have thought. I examined 13 RGB working color spaces:

Please note the order; it is the same order that is used in the graphs to follow. These color spaces are the same ones as in the first post of this thread, with the exception that NTSC RGB is omitted. I did that to facilitate the gamut mapping algorithm that I used to make sure that all the colors in the test image are within the intersection (in the mathematical sense of the word) of the gamuts of all the color spaces under consideration. I have another gamut-mapping method available to me, which I used for the preceding post, but it doesn’t fill the desired intersection gamut as efficiently as this one. There is Matlab code for each available on my blog.

The target image is the same, all 16+ million colors representable in 8-bit sRGB before the gamut mapping.

In this set of trial conversions, rather than chaining the computations so that the error builds up as the number of iterations increases, I’ve captured the error introduced by each conversion. In addition, so that we can see if there is some pattern, rather than have the conversions talk place in random order, they are performed sequentially, from the first color space to all the others, from the second one to all the others, and so on until we’ve reached the last color space on the list.

If we leave everything in double precision floating point:



All errors are below half of a trillionth of a Lab DeltaE (500 femto-DeltaEs? Nah, that’s just weird). The difference between the worst and the best coversion errors is about a factor of two. This is also true for the much smaller (and not shown here) mean error and the standard deviations of the errors.
If we quantize to 16-bit unsigned integers after conversion:



The worst-case errors are less than 1/100th of a DeltaE, with the same binary order of magnitude ratio.

Not shown here are 15-bit conversions. Unsurprisingly, they have twice the errors of the 16-bit ones.

Eight-bit quantization provides this graph:



Errors are occasionally as bad as 2 DeltaE and as good as 1 DeltaE.

So, with double precision floating point algorithmic conversions, the errors are not materially conversion errors at all, but merely the result of re-quantizing the image in the destination color space. The 16 and 15 bit errors are, IMHO at least, negligible.

Details here: http://blog.kasson.com/?p=7541

Jim

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Results when converting in Photoshop
« Reply #4 on: October 10, 2014, 06:05:06 pm »

We have seen with high-accuracy model-based RGB color space conversions in 8, 15, and 16-bit integer precision, that conversion accuracy is essentially limited by the re-quantization of the image in the destination color space. Are the conversion algorithms in Photoshop anything like the ones I was using in Matlab? I set out to find out.

Since it takes manual operations to do color space conversions in Photoshop (I didn't want to write scripts), I created a 16-bit per color plane image with a lot of colors: 256 million of them, to be exact, chosen randomly with uniform distribution, so that the color space of the source image was pretty completely filled. That way I could get the same amount of data that I'd get with 16 conversions of a 16 MP image in one go. I assigned sRGB to that image, and converted it to Adobe RGB and back, wrote it out, and measured the errors in Matlab.


    an average error of 0.0020 CIELab DeltaE
    standard deviation of 0.0049
    worst-case error of 0.2121.

This is not as good as we got doing the conversions in Matlab (it's more than an order of magnitude worse), but it is good enough that photographer should have to worry about damaging their images by making this set of color space conversions.

From sRGB to ProPhotoRGB and back:

    average error of 0.0030 CIELab DeltaE
    standard deviation of 0.0026
    worst-case error of 0.0900.

From sRGB to Lab and back:

    average error of 0.0040 CIELab DeltaE
    standard deviation of 0.0033
    worst-case error of 0.0875.


« Last Edit: October 10, 2014, 06:09:46 pm by Jim Kasson »
Logged

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Photoshop conversions -- ACE vs ICM
« Reply #5 on: October 13, 2014, 07:24:03 pm »

With only one exception, working color space conversions of a 256 megapixel 16-bit random color test image using the Microsoft ICM color engine are less accurate (as measured using CIELab DeltaE) than those using Adobe's ACE engine:





The ACE results are labeled "Photoshop" in the graphs. ICM's worst-case results for round trips are sufficiently bad that I wouldn't recommend using it for working color space conversions. It does honor the absolute colorimetric rendering intent, though.

Details here.

Jim
« Last Edit: October 13, 2014, 07:32:03 pm by Jim Kasson »
Logged

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: Results when converting in Photoshop
« Reply #6 on: October 14, 2014, 03:45:28 am »

We have seen with high-accuracy model-based RGB color space conversions in 8, 15, and 16-bit integer precision, that conversion accuracy is essentially limited by the re-quantization of the image in the destination color space.

Hi Jim,

Thanks for the interesting research. I think there are two (re-)quantizations at play, as long as we use integer numbers at the intermediate stages. The first is when a rounding/truncation takes place in the first conversion. Then the second (re-) quantization may or may not land on the identical tri-chromatic coordinate as it started with initially.

However, if it doesn't, it's likely(!) to be not that far off, because we only introduced the double rounding to integers as reduction of precision (assuming other calculations in the CMS are accurate, which is not necessarily a given). It may be interesting though, because it can impact things like posterization to additionally report the resulting number of unique colors.

The reduction of the number of unique colors could IMHO be a useful additional quality metric.

Calculating the unique number of colors is a nice programming exercise by itself, when I think about it, because simply tabulating and counting could become a bit memory intensive as the initial quantity increases with bit depth. It might be less memory intensive to count the not-unique colors, but might be slow. Some food for thought can be found here (I was contemplating the bit-checker approach myself).

Then there is the perceptual aspect. Not all DeltaE metrics are created equal, or perceptually relevant. I probably should re-read your blog, but which type of DeltaE are you using (simple Euclidean distance, or a perceptually weighted version)?

Cheers,
Bart
« Last Edit: October 14, 2014, 05:20:28 am by BartvanderWolf »
Logged
== If you do what you did, you'll get what you got. ==

fetish

  • Full Member
  • ***
  • Offline Offline
  • Posts: 154
Re: Are some RGB working space conversions worse than others?
« Reply #7 on: October 14, 2014, 05:44:44 am »





For a moment I thought this was a medicine forum discussing irregular heartbeat causes....  :-X
Logged

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Results when converting in Photoshop
« Reply #8 on: October 14, 2014, 11:18:50 am »

Thanks for the interesting research. I think there are two (re-)quantizations at play, as long as we use integer numbers at the intermediate stages. The first is when a rounding/truncation takes place in the first conversion. Then the second (re-) quantization may or may not land on the identical tri-chromatic coordinate as it started with initially.

Certainly true, given your assumptions. I've been doing all the intermediate calculations in 64-bit floating point. It takes longer than when Photoshop does it, but I think it's acceptable; you don't convert color spaces that often.

However, if it doesn't, it's likely(!) to be not that far off, because we only introduced the double rounding to integers as reduction of precision (assuming other calculations in the CMS are accurate, which is not necessarily a given). It may be interesting though, because it can impact things like posterization to additionally report the resulting number of unique colors.

The reduction of the number of unique colors could IMHO be a useful additional quality metric.

If it doesn't start another war about the countability of colors.

Calculating the unique number of colors is a nice programming exercise by itself, when I think about it, because simply tabulating and counting could become a bit memory intensive as the initial quantity increases with bit depth. It might be less memory intensive to count the not-unique colors, but might be slow. Some food for thought can be found here (I was contemplating the bit-checker approach myself).

It's pretty easy in Matlab: c = unique(a); Only works if the colors are smooshed together in an nxn matrix, not if they are in separate planes.

Then there is the perceptual aspect. Not all DeltaE metrics are created equal, or perceptually relevant. I probably should re-read your blog, but which type of DeltaE are you using (simple Euclidean distance, or a perceptually weighted version)?

I am computing the errors in 1976 CIEL*a*b* DeltaE and 1976 CIEL*u*v* DeltaE. I am presenting the former in this forum, since it is more familiar to the people who hang out here.
« Last Edit: October 14, 2014, 11:21:53 am by Jim Kasson »
Logged

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: Results when converting in Photoshop
« Reply #9 on: October 14, 2014, 12:13:54 pm »

Certainly true, given your assumptions. I've been doing all the intermediate calculations in 64-bit floating point. It takes longer than when Photoshop does it, but I think it's acceptable; you don't convert color spaces that often.

Indeed, but I do assume you save and reread output before requantization. Otherwise there may be differences.

Quote
If it doesn't start another war about the countability of colors.

LOL, I don't think that would be possible after quantification (which is a simple count) instead of a conceptual continuous space.

Quote
It's pretty easy in Matlab: c = unique(a); Only works if the colors are smooshed together in an nxn matrix, not if they are in separate planes.

I see. Yet, it might become a bit harder when you exceed, say, 13-bit precision.

Quote
I am computing the errors in 1976 CIEL*a*b* DeltaE and 1976 CIEL*u*v* DeltaE. I am presenting the former in this forum, since it is more familiar to the people who hang out here.

I understand.

Cheers,
Bart
Logged
== If you do what you did, you'll get what you got. ==

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Results when converting in Photoshop
« Reply #10 on: October 14, 2014, 12:28:22 pm »

Indeed, but I do assume you save and reread output before requantization.

No, I don't. If I did I'd have to save it at at least 32-bit precision.

I see. Yet, it might become a bit harder when you exceed, say, 13-bit precision.

Not harder to code, since Matlab supports 64-bit unsigned integers, but probably slower. I'll look at it.

Thanks, Bart.

Jim
Pages: [1]   Go Up