Step six
And now, with profile integrate in TIF, no save on disk : FOIP-sRGB-2.412.92310
@jdc - slightly off-topic, but thank you! for showing Histogrammer screenshots. Guillermo Luijk is a genius and I had completely forgotten about his Histogrammer. Well, it’s Windows only and I haven’t had a Windows machine in many years. I don’t even have Wine installed, but does anyone know if Histogrammer runs under Wine?
The download link for Histogrammer is at the top of the second column of the second link below:
http://www.guillermoluijk.com/tutorial/histogrammar/index_en.htm
http://www.guillermoluijk.com/software/histogrammar/index.htm
It would be wonderful to have such a tool available for free/libre software. Do you know if Guillermo ever supplied the source code under an appropriate license? Is it perhaps incorporated in the Perfect Raw code?
Of course, I can furnished others graphs… bt I think there is enough fr the moment now 
@Elle
No, it is not in Perfect Raw code, but 8 yeras ago, when I work in the team of Perfect Raw, Guillermo, show us this wonderfull software
jacques
In your article, there is a typo (? - but the “typo” links to the Babel proprietary software website) and incorrect link:
In his writeup on the sRGBz profile, Øyvind Kolås (Pippin) mentioned generating new colorant tag values from Babel with improved accuracy.
I was a bit surprised to see “Øyvind Kolås (Pippin)” and “Babel” proprietary software in the same sentence given Pippin’s commitment to using free/libre software . Looking through Pippin’s write-up on sRGBz (sRGBz—a minimal ICC v2 sRGB profile), indeed “Babel” software isn’t mentioned. He was actually referring to his own “babl” software:
GEGL - Wikipedia - quoting: “babl, a support library for GEGL, provides a generic way to deal with color-space conversions”
Here’s a link to GEGL software page: http://www.gegl.org/
So the quantizing for the 212-point profile shown by Histogrammer is obviously a bad thing. The question is whether the quantizing is from Histogrammer not doing a linear interpolation between the profile TRC points (the ICC does specify to use linear interpolation between the points). We can’t check without access to the Histogrammer software source code.
What happens to the histogram when you use cctiff (cctiff) to convert from my V4 sRGB profile to the 212-point profile? What happens to the histogram when you do the same thing using LCMS’s tificc (Little-CMS/utils/tificc/tificc.c at master · mm2/Little-CMS · GitHub)? I guess it’s not possible to tell using Histogrammer, if Histogrammer indeed does not interpolate between the points? Maybe do a round-trip for each conversion back to my V4 version of sRGB, and then check using Histogrammer? Or maybe use Imagemagick to count the number of colors in the image “before” and “after” converting and/or after simply assigning the different versions of sRGB?
If a “failure to interpolate between the points” happens in various softwares, that alone is a reason to confine the use of “small” sRGB profiles to 8-bit images displayed on the web.
@saucecontrol - is your final version of the small sRGB profile available for download? If it was given in your Part 3, I didn’t see it, but I was scanning for the main lines of your argument, rather than for a download link.
Regarding your proposed values for the sRGB profile’s RGB XYZ tags, I see where you are going with your line of reasoning. Here’s my understanding so far, so please correct me if I misunderstand:
-
It’s not enough to use the correct source and destination white points and the correct source xy values, and then “nudge” to get well-behaved primaries in the profile that is saved to disk.
-
In addition, one must make sure the resulting primaries are invertible, to get back to the xy values in the spec.
-
These invertible primaries - at least for the sRGB ICC profile - are actually in the sRGB specs and/or in the ICC’s recommendations for making an sRGB profile.
-
No-one ever, anywhere, ever - including Graham Gill (my sRGB primaries match Graham Gill’s sRGB.icm by design), HP, and the ICC - has ever actually produced a correct sRGB ICC profile.
-
And because of the way the source white point is calculated, all true V2 ICC profiles (including I presume AdobeRGB1998) that have ever been made for a color space with a D65 source white point - or at least the ones I included in my various surveys - all of these profiles have incorrect white point tags.
I haven’t had a hex editor installed on my system since iccXml was released, so first I want to install a hex editor (or maybe 3 or 4 hex editors 
), and then reread through your Part 3. So clarifications on where I might have misunderstood Part 3 are greatly appreciated. A link to your proposed replacement sRGB profile also would be nice!
If I understand Histogrammar, it does the same thing (in best ==> zoom and so on), than an normal histogram.
An normal histogram works in general in 8 bits ==> 256 colors for red, 256 colors for green, 256 colors fo blue, and for each color we count the number of pixels, and put them in Y ordonate, and in X value of R, G or B
In this case Guiilermo (I am quasi sure,even I am an old man!) works in 16 bits ==> 65536 colors for red, 65536 colors for green, 65536 colors for blue
The only “interpolation” is round of float values to integer, eg 32123,34 ==> 32123, I think negligeable
@jdc thanks for posting your test findings. I’ve been considering different ways to test and had settled on using tiffcc in 8-bit and 16-bit modes with the V4 profile as a reference. I’ll check out Histogrammar and see if I can figure out how it does its thing
@Elle thanks for the tip on the babel/babl typo. I knew that didn’t look right, and then it was late when I was adding links to my post, so I didn’t think about it as much as I should have.
I do believe that’s enough to get a well-behaved profile, according to neutral grey axis definition. In fact, you can choose completely wrong whitepoints and primaries and get a well-behaved profile too, as long as the primary values balance out so that they add to exactly the value of white. It was easy for me to see this in looking at the hex values, since the granularity becomes one hex digit. Trying to figure it out in increments of 0.000015 in decimal form makes it a bit harder.
This, I think, is an important part of adhering to the spec. If the spec only gave the values for the R’G’B’->XYZ matrix, I think you could calculate those values with any level of precision you want (as long as it was at least what’s specified). But the sRGB spec also give the XYZ->R’G’B’ matrix values, and in order to match those, the profile matrix has to be invertible. The fact that those numbers were revised between the draft spec and the final spec is key for me. sRGB is meant to be easy to implement and get right. If you use the XYZ values published in the spec, you follow the spec. Attempting to calculate the intended numbers from xy is not only more difficult, it also breaks compatibility with software that did actually follow the spec.
Yes, and yes. I’m sure you’ve looked at more profiles than I have, but I couldn’t find one myself. I find it very odd that the ICC publishes what I believe to be the correct numbers in their spec extension but doesn’t distribute a profile with them,
I don’t think this is right. The D65 value in the white point tag should match the value that was used to adapt to D50. My understanding is that the wtpt tag is only used in Absolute Colorimetric Intent conversions, and it’s used to undo the chromatic adaptation to the profile white point. That means its value should match the one that was used to create the original D65->D50 adaptation matrix. sRGB is very clear that the value of D65 is [X=0.9505,Y=1,Z=1.0890], and using that number keeps everything in balance because it is the exact sum of their rounded primary values given in the R’G’B’->XYZ matrix.
I’ve only just started looking at the Adobe RGB spec, but they give the XYZ value of D65 as [X=0.9505,Y=1,Z=1.0891], so by that definition, they should have a different wtpt tag in their profiles.
Interestingly, Adobe gives 5 decimals of precision their R’G’B’->XYZ matrix, and their values total to [X=0.95046,Y=0.99999,Z=1.08906]. Those totals are closer to the correct value of D65 as calculated from their given D65 chromaticity of x=0.3127, y=0.3290. Calculating XYX from those xy values gives [X=0.950455927051672, Y=1, Z=1.08905775075988].
Anyway, what’s correct for that value depends entirely on what was used to calculate the primary color values. I found that if those values are kept in balance with their defined white and the Bradford adaptation matrix uses that same defined white, the values always come out well-behaved. It would stand to reason that the value stored in the wtpt tag would also allow a reverse Bradford matrix to be created that would allow its output to be well-behaved too.
You got it! sRGB-sc-212.icc (796 Bytes)
I haven’t done all the testing I want to with that profile and the other variants I want to try, but you’re welcome to put it through its paces and see if you can find a weakness.
Yes, as long as one’s only goal is producing a well-behaved (neutral gray axis) ICC profile, it doesn’t matter what source or destination white point or even what xy values for the primaries you choose. As long as the resulting XYZ values are properly “nudged” (which ArgyllCMS does do, and LCMS does not do), the resulting profile is “well-behaved”. Well, most profiles with D50 source white points don’t need nudging, and not even all the color spaces wtih non-D50 white points need nudging.
As a complete aside, I’m guessing there are practical limits to what can be used as source color space RGB xy values. For example, what happens if you choose three primaries that are all on the spectral red and yellow side of any normal white point, and not including a primary on the other side of any actually “white” white point? For such a color space, it would be odd to speak of a neutral gray axis. In another thread this type of profile was suggested, but I never did take the time to make such a special-purpose profile (and I’m not sure my profile-making code would even be able to make such a profile). If you are curious, here’s the thread:
I am very happy - thrilled actually - that so many people on this forum and in this thread are taking the time to read the ICC specs and also even read color space specs.
Like @saucecontrol, I’m not willing to spend money to get copies of the various official latest color space specs. But if anyone uses exiftool to examine my ICC profiles, I do give the link to the version of the spec that I did use, right inside one of the ICC profile tags.
Thanks! And also thanks much! for clarifying regarding the D65 white point.
To me, this is the really cool thing about XYZ colors… it doesn’t matter. Imagine you’re in a room with a red light and you’re wearing white shoes. If you look at your shoes, they’re red… as is everything else. There is no neutral grey in such a room. In fact, the only color in that room’s gamut with 0 a* and b* values is black (if even that exists). I guess that gives it a neutral axis, which just happens to be a neutral point instead of a line.
All of that seems perfectly legit, but you wouldn’t want to do work in that room that required you to be able to accurately compare colors. So it would make a valid color space but not a good working space. And it would be silly to define an RGB space in that way since there’s no green or blue light to represent. On a chromaticity diagram, red, green, and blue would all be red. Still valid, I suppose
1 Like
Hi,
I’m afraid I’m not convinced that your sRGB primaries are more accurate. From my reading of your blog post, you seem to be trying to make the matrix values match the rounded values in the sRGB specification. I don’t think that’s a valid goal. If one starts with the primary x,y values as given, then the equivalent matrices have to have infinite precision in order to match the original x,y values. If you truncate the matrices to 4 dp precision, then you are taking them as canonical, instead of the primary x,y values.
To put it another way, I take the sRGB spec matrix values as illustrative or implementation convenience values, not canonical, and instead compute the ICC tag values (equivalent to the RGB to XYZ matrix) from first principals to be the the best rounded values consistent with the spec. x,y values, and the goal that the primaries should sum exactly to the white point.
From a pragmatic point of view, I use the (quantized) header values thru-out ArgyllCMS. Once again I assume that the published 4 dp values have been rounded to meet the Scientific publishing convention of not showing more precision than can be justified. To take the decimal values as canonical would result in an impossible to reconcile and unnecessary loss of precision in the CMS implementation.
I’ll make note of another source of inaccuracy in ICC profile conversions, this one being in absolute colorimetric conversions when the ‘chad’ tag is used rather than the older ICC V2/sRGB/AdobeRGB convention of using the white point tag in combination with the Bradford matrix. With the older convention the CMM can compute a float precision transform matrix between the absolute and relative WPs, the precision being limited by the ICC 1.15 bit white point tag precision. Using the ‘chad’ tag the abs<->rel matrix itself gets quantized, resulting in noticeably larger errors in the profiles ability to encode the devices measured color response.
Hey Graeme, I’m really pleased you found your way into this thread.
Let me start with a few caveats before I get into your comments.
- I’ve been writing color management software for roughly 2% as long as you have
- I’ve never actually read the sRGB spec
- I unequivacally have zero knowledge of the inner workings of the ratification process for said spec
- I don’t necessarily expect you or anyone else to change their long-working implementations based on my math. After all, we disagree by a max value of 3/65536 in our primaries.
All that said, I’ll debate with you anyway 
I don’t necessarily believe they’re more accurate, just that they’re more compliant with the spec.
That’s correct, and I believe that is the correct interpretation. The x,y values were the starting point for the sRGB primaries, but the spec deviated from those ever so slightly in order to make the math cleaner. That deviation was small enough that the value of the primaries is preserved to the level of precision given in both the sRGB and the Rec. 709 standards. In other words, using the XYZ values at the given precision maintains compatibility with the starting x,y values at their starting precision level. Using the x,y values does not maintain compatibility with the given XYZ values at their starting precision level. And that’s true no matter how much precision you keep in the intermediate processing.
This, I believe, is incorrect. The fact that the original matrices didn’t invert to each other would have justified publishing more decimal places. Instead of adding precision to the document/spec, they actually adjusted the numbers so they worked out at the lower precision. This is reinforced in the fact that not only were the matrix values adjusted, but the rounded XYZ value of D65 given is rounded in the wrong direction.
I can’t speak to lost accuracy within the CMS itself, but as soon as an ICC profile enters the mix, precision is lost anyway. The s15Fixed16Number format only has accuracy to log(2^16) =~ 4.8 decimal places, which really means 4 with the 5th being mostly right. Any precision you start with by trying to improve on the XYZ values given in the spec is lost when you save them to or read them from a profile.
Going back to the example I used in my post, this is the value of the D65 R’G’B’-XYZ matrix calculated with as much accuracy as I could preserve, starting from the x,y primaries. This was the matrix that produced the profile values that match the ones from ArgyllCMS (after adaptation, of course).
0.4123907992659590 0.3575843393838780 0.1804807884018340
0.2126390058715100 0.7151686787677560 0.0721923153607337
0.0193308187155918 0.1191947797946260 0.9505321522496610
If you round-trip those though s15Fixed16Number format, they only maintain 4 dp of accuracy.
0.4123840332031250 0.3575897216796880 0.1804809570312500
0.2126464843750000 0.7151641845703130 0.0721893310546875
0.0193328857421875 0.1192016601562500 0.9505310058593750
And taking that round-tripped matrix and inverting it, you get this.
3.2411015823888700 -1.5374742408225600 -0.4986348425717410
-0.9693232691940230 1.8760231681184500 0.0415720618303295
0.0556374237335379 -0.2039925695286720 1.0569719298571300
Which only matches the correct inverse matrix (below) to 3 dp.
3.2409699419045200 -1.5373831775700900 -0.4986107602930030
-0.9692436362808800 1.8759675015077200 0.0415550574071756
0.0556300796969936 -0.2039769588889760 1.0569715142428800
By contrast, the XYZ values used in the sRGB spec, with their intentional imprecision, maintain 4 dp of agreement on that round trip.
I actually just started looking into this today, and that was my initial thought when reading the ICC spec. I can see there were some very odd decisions made between the V2 and V4 spec publication and in updating the V2 spec after.
I don’t see a practical way to take the sRGB spec. matricies as canonical - they are not perfect inverses of each other, so which one is the reference ?
(Note that an ICC matrix profile has just one matrix, the forward transform matrix. The CMM inverts this to create the reverse transform.)
They are inverses of each other at 4dp precision. I actually did that math in my blog post. The only way I could get all the numbers in the spec (or rather, the Wikipedia summary of the spec 
) to agree with one another was to use the published XYZ values, at their given precision. Any attempt I made to get extra accuracy, including starting from the x,y values, resulted in mismatches. That’s what ultimately convinced me that the XYZ values are the canonical ones. They all agree with each other and balance out perfectly (again, at their given precision).
The fact that the draft spec numbers aligned more closely with the values I calculated from the x,y starting point and that those values were deliberately modified between the draft and the final really drove it home for me.
Sorry, I’m completely unconvinced. The spec. starts with the x,y values and then does limited precision calculations to arrive at matrices that do not exactly correspond to their starting point, and are not exact inverses. Starting with the spec. primary x,y values and computing ICC rounded matrix values results a profile that (overall) more accurately models the original primaries, and therefore better represents the sRGB colorspace.
I guess we’ll have to agree to disagree.
I do completely agree that the primaries and whitepoint you use are correct for Rec 709. And I do agree that sRGB could be described, in its original draft version, as ‘a colorspace with Rec 709 colors and whitepoint, and a gamma curve tuned for PC displays’.
Really, where we differ is that I believe the final version of sRGB could better be described as ‘a colorspace with colors and whitepoint based on Rec 709 but slightly modified for easier/cleaner PC software implementation, and a gamma curve tuned for PC displays and then slightly modified for easier/cleaner PC software implementation’
I believe the changes to the numbers between the draft and final spec back up that change in definition, and again, I’ll say the matrices given are exact inverses (at the precision given) and do still reverse to the x,y primaries/whitepoint (at the given precision). So yes, starting from x,y does more accurately model the original primaries, but I don’t believe it more accurately models the final specified primaries.
If only someone had a copy of the actual spec and could check it to see if it contains any clarification to explain the discrepancy…
Language Lawyer here, just want to make sure communication is clear. The word “canonical” essentially means “of the canon”, which asserts the published specification as Correct. It doesn’t mean the contents of the specification are precise, accurate, or even appropriate, it means that articles developed to comply with the specification adhere to the prose as-written.
This distinction is important to the operation of complying mechanisms that need to interoperate, or operate with consistent results. They may all be “wrong”, but they’re consistently wrong.
It sounds to me like what’s being chased here is more along the lines of “colorimetrically consistent”, with respect to individual gamut transforms as well as their continuity across “adjacent” transforms. ??
The aerospace business has horribly maimed me… 
1 Like