GNOME Bugzilla – Bug 794184
Support for high bit depth RGB (and LCH?) color palettes for painting
Last modified: 2018-05-24 19:19:12 UTC
It seems to me that an unbounded floating point RGB image editor at least needs to support unclamped high bit depth RGB color palettes, even if the palettes are limited to "sRGB only" RGB values instead of also supporting LCH color palettes. Without thinking, I just tried to add a high bit depth unbounded floating point color to a new "image-specific" color palette, and of course the color was clamped to 8-bit RGB, changing the LCH hue by 15 degrees! A fifteen-degree hue change is a rather large change in color. There were three other "out-of-sRGB-display-range" colors that I wanted to add to the palette. These four colors are rather critical for this particular image, but it looks like my image-specific color palette will be lacking the 4 brightest of the twenty colors I wanted to put in the palette. Ideally GIMP color palettes would also support LCH, as this would provide for palettes that can be used in any RGB color space instead of just the sRGB color space. But that's probably a topic for a separate bug report.
Storing the color palette values as 32-bit floating point XYZ would allow the user to choose the colors using whatever color space they wanted (sRGB, other RGB, LCh, HSV, whatever else might be available), and have the colors automatically convert to the correct values for whatever RGB color space the user happens to be using at any point in the future, even after GIMP supports "any RGB".
Per mitch's request, file format options are: SwatchBooker (SBZ), supported by Krita and Scribus: http://www.selapa.net/swatchbooker/. Any color model, can be mapped to ICC, has internationalization etc. CxF3, developed by X-Rite and supported by Scribus since v1.5.4: https://www.xrite.com/page/cxf-color-exchange-format. Lots of color models supported, some neat advanced features. Unlike SBZ, no dedicated free/libre editor for now.
Has Swatchbooker been updated since 2010? The last release seems to be from 2010: https://launchpad.net/swatchbooker/+download The requirements for running seem to include LCMS version 1 (look under requirements): http://www.selapa.net/swatchbooker/ Quoting from http://www.selapa.net/swatchbooker/ Value ranges: sRGB,RGB,HSV,HSL,CMY,CMYK,nCLR: 0 -> 1 YIQ: Y 0 -> 1 : IQ -0.5 -> 0.5 Lab: L 0 -> 100 : ab -128 -> 127 XYZ: 0 -> ~100 Limiting Lab "ab" to the range of integers between -128 and 127 means not even all *real* colors can be encoded. Limiting Lab "L" to the range 0 to 100 means colors with Lab L values >100 can't be encoded, even though apparently Mark Fairchild says somewhere in one of his papers (the link is somewhere on pixls.us) that Lab is good up to L=200. What is "RGB" in the list starting with "sRGB,RGB,HSV, . . ."? With an sRGB/RGB range limit of 0 to 1, there's no way to encode an out-of-gamut channel value. How many decimal places for sRGB/RGB can be encoded using this SwatchBooker XML file? What about Lab/XYZ? It looks like at least two decimal places can be stored - is this the limit?
Hmm, more updated version is here: https://github.com/olivierberten/SwatchBooker/releases
Yes, newer versions are available on GitHub, and no — LCMS2 is required now. I'd rather have Olivier reply the rest of your questions :)
Since 2010, SwatchBooker was only updated to work with LCMS2 and Qt5. The ranges I chose were the ones the most used in the different softwares but there's no limitation to these, neither to integers so you could very well encode out-of-gamut values. SwatchBooker treats them all as floats anyway and these are fed into LCMS as doubles. They are indeed cropped to 2 decimals in the editor but that's a limitation to the software, not to the format... Since SBZ supports color profiles, "RGB" would normally be associated with one of these but it could also be "plain" RGB values.
(In reply to Alexandre Prokoudine from comment #2) > Per mitch's request, file format options are: > > SwatchBooker (SBZ), supported by Krita and Scribus: > http://www.selapa.net/swatchbooker/. Any color model, can be mapped to ICC, > has internationalization etc. > > CxF3, developed by X-Rite and supported by Scribus since v1.5.4: > https://www.xrite.com/page/cxf-color-exchange-format. Lots of color models > supported, some neat advanced features. Unlike SBZ, no dedicated free/libre > editor for now. By "file format options" what do you mean? Do you mean the file format in which/to which GIMP itself will always read and store color palette information? Does this mean GIMP color palette-related code will need to be modified to write either something in SwatchBooker format, or else something in CxF3 format (but not both)? Which in turn would imply old-style GIMP palettes will be imported and when saved to disk by the user, rewritten as either a SwatchBooker file, or else a CxF3 file (but not both)? Just to be clear, I think you are saying that this new GIMP color palette-related code isn't about *supporting* two new ways to store color palette information - "support" would be the ability to import and export as SwatchBooker and/or as CxF3, without having any implications for GIMP's "native" color palette storage format. Instead what Alexandre/Mitch are talking about is *replacing* GIMP's native color palette storage format with either SwatchBooker or XcF3 (but of course not both). If the suggestion is to *replace* GIMP's current native color palette storage format with something new, personally I'd prefer SwatchBooker, for several reasons: 1. Because SwatchBooker is clearly free/libre software (GPL3) and Olivier Berten is responsive to questions about encoding and such. 2. To avoid dealing with potentially non-free code under control of organizations that don't give a single hoot about free/libre software. I read through the license document, included in this download: https://www.xrite.com/-/media/xrite/files/apps_engineering_techdocuments/c/cxf/cxf3corexsd.zip - I can't tell if the stuff is free/libre or not. I suspect a lawyer would have to decide, which is to say a lawyer for Debian and a lawyer for Fedora, and a lawyer for FSF, as these organizations don't agree with one another up and down the line. 3. Because this new CxF3 "Standard" is already on revision 3, and I suspect with iccMAX in the wings, more revisions will be forthcoming, which means new chances for questions about licensing and such, and more requirements for obtaining the latest "stuff" for actually using this "Standard". IMHO, *supporting* CxF3 via importing/exporting is one thing, adopting it as the native GIMP color palette code is quite another. As an aside, it looks like the rate at which CxF3 is being adopted is fairly low, or at least Adobe is being slow to adopt it: https://forums.adobe.com/thread/2191655.
Elle, I'm confused: you are the one who posted this feature request. I didn't do that! :) As for the reasons you outlined, 1. I have nothing to comment here on. 2. I don't get how a file format can be libre or not. 3. I don't understand the problem you are envisioning. I'm also unsure what Adobe has got to do with this. Could you please clarify?
(In reply to Alexandre Prokoudine from comment #8) > Elle, I'm confused: you are the one who posted this feature request. I > didn't do that! :) Maybe you could ask Mitch how SwatchBooker and CxF3 are relevant to my original request. My apologies for including your name along with Mitch's - I assumed you were part of whatever conversation there was that led Mitch on IRC to conclude that somehow SwatchBooker and/or CxF3 were relevant to my request to have high bit depth floating point color palettes. But apparently I was wrong. Or maybe I completely misunderstood what Mitch was saying. To clarify, this is my original request: Add to GIMP the ability to save colors in color palettes using floating point unbounded values instead of 8-bit integer values, perhaps using XYZ to make GIMP's color palettes be useful for "any RGB" instead of just "sRGB". Mitch said something on IRC about two possibilities for "something" to do with revising GIMP's color palette code, the possibilities being SwatchBooker or the XRite thing. > As for the reasons you outlined, > > 1. I have nothing to comment here on. It's very nice that you've gone through my list. But you didn't answer my main question, so here it is again: Is there an intention on the part of Mitch and/or other GIMP devs to *replace* current GIMP color palette code with SwatchBooker or CxF3? Or was Mitch's comments on IRC strictly about adding *support* for SwatchBooker or CxF3? Or perhaps he was talking about something else altogether and I misunderstood him, in which case I apologize. I had gone on IRC to ask for help in modifying the existing color palette code to accomodate high bit depth floating point values, and somehow the conversation ended with a reference to something about XML already having been decided by some group of GIMP devs somewhere at some point in some past conversation. I don't have a record of the conversation on IRC so I can't quote Mitch's exact words. > > 2. I don't get how a file format can be libre or not. Well, I don't know either. XRite put a copyright on "something" and perhaps I misunderstood what that "something" really is. Perhaps you could download this file, unpack it, and read the copyright information, and let me know what it's actually a copyright for: https://www.xrite.com/-/media/xrite/files/apps_engineering_techdocuments/c/cxf/cxf3corexsd.zip The title at the top of the copyright document is this: X-Rite CxF ™ Schema Open License Agreement > > 3. I don't understand the problem you are envisioning. My apologies, if I could delete what I said under "3" I would do so. > I'm also unsure what Adobe has got to do with this. Could you please clarify? Again, my apologies. If I could delete the reference to Adobe I would do so. I was trying to see how widely used this XRite stuff might be, and was surprised to see that CC doesn't seem to support it.
When I saw your bug, I remembered an old conversation with Alexandre about SwatchBooker. I have never heard of CxF3. The idea is: why reinvent a palette format to hold >8bit palettes when there already is one that originates in a free project. Also, comment 7 seems pretty clear to me, and I agree.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1328.