GNOME Bugzilla – Bug 758001
GIMP should provide a user option to disable the babl flips
Last modified: 2016-12-23 00:08:44 UTC
An option to disable the babl flips is critically important for users who want or need control over how their RGB data is handled. Four specific reasons are given below: 1. The option to disable the babl flips will enhance interoperability with other high bit depth image editing programs: * It will enhance interoperability with editing programs like Krita that don't try to enforce radiometrically correct editing, but rather take the route that the user is responsible for choosing whether to edit in a true linear gamma color space or in some other color space. * It will also enhance interoperability with editing programs like PhotoShop, which *do* enforce linearized RGB for selected operations, but enforce linearity for a different (and for PhotoShop, very incomplete) set of editing operations (https://www.freelists.org/post/argyllcms/colprof-problem,30; https://www.freelists.org/post/argyllcms/colprof-problem,31 ). 2. Without the ability to disable the babl flips, high bit depth GIMP users are at the mercy of whichever developer last modified the code for any given editing operation, to request RGBA vs R'G'B'A or YA vs Y'A. Obviously it's very important that babl/GEGL/GIMP provide radiometrically correct default handling for all editing operations. But: * For various reasons and for some editing operations, developers have programmed in radiometrically incorrect choices. * Checking and changing the code is time-consuming and requires a good understanding of whether any given operation should be done using linearized RGB or perceptually uniform RGB, or whether maybe it's one of the rare operations that should by default provide both options. * The option to disable the babl flips is a necessary safety net for users who know what they are doing. 3. There will always be cases where particular users for particular reasons will want to override the default code regarding linearized vs perceptually uniform RGB: * Some users really do know *exactly* when and why they want to edit using a true linear gamma color space, and when they want to edit using a more perceptually uniform color space. Developers simply can't know *why* a user wants to make an editing move that isn't easy or even possible if the babl flips are working in the background to manipulate the RGB TRC. * Some users also know which perceptually uniform TRC they actually want to use, and it won't always be the sRGB TRC. Disabling the babl flips makes it possible for the user to choose a different TRC for times when they want to operate on more or less perceptually uniform RGB. For example: i. When I want to operate on perceptually uniform RGB, I usually use a color space with the LAB-L TRC, not the sRGB TRC. ii. The gamma=2.2 TRC is just about as close to a perceptually uniform TRC as the sRGB TRC, but allows for exposure compensation using perceptually uniform RGB, and also allows to white balance using "Levels, Pick white point" on perceptually uniform RGB, without introducing the systematic small errors that result from using the sRGB TRC because the sRGB TRC isn't a true gamma TRC (neither is the LAB-L TRC). 4. There are use cases where users will want to edit an image in very odd color spaces such as device color spaces. For these particular use cases the image RGB values simply can't - and for the user's particular purpose - *shouldn't* be subjected to an arbitrary conversion to a proper RGB working space and then subjected to the babl flips. It would be sad if GIMP couldn't accomodate this type of use case.
Two additional important use cases for having the option to disable the babl flips (continuing numbering from above): 5. For scientific editing, where the user simply *must* be trusted to know what they are doing, and simply *can't* be expected to have to account for whatever default behavior the devs might have programmed into the various editing algorithms. 6. For testing how GIMP itself is working. Currently the only way to know for sure what any given combination of "operation+precision+gamma hack" actually produces is to test the operation in a version of GIMP that's been patched to disable the babl flips.
I was under the impression that we had discussed this in all length earlier this year, with the following conclusion: 1. GIMP 2.10 will be released as-is, or we will never get it out 2. Future Babl will have formats with freely configurable RGB chromacities and gamma, and ops will be able to "wildcard" their input formats and take "any rgb".
I'm not sure what the implications are of closing this bug as "won't fix". If someone trying to test algorithms or ICC profile conversions, or trying to choose for technical or artistic reasons to use one or another RGB channel encoding, or etc, can't *disable* the babl flips, then they can't know whether their editing/testing results are the results of what they are actually trying to test or do, or whether their results are the results of having the TRC in which the RGB channels are encoded "changed in midstream" by babl/GEGL/GIMP. I keep returning to the fact that the babl flips *could* be useful for allowing the USER to choose when to operate on linear RGB and when on perceptually uniform RGB. But the way the babl flips are currently being used . . . 1. *Not* under the user's control on a per op basis 2. *Always* the sRGB TRC (which is a TRC that's of questionable use for photographic editing - the LAB companding curve is much more useful, and for VFX workflows there are many TRCs a person might need, and so on) . . . makes high bit depth GIMP useless for any editing workflow in which the user knows what they are doing and needs control over the RGB channel encoding to do what they want to do. Hence, these "babl flips as currently coded" mean GIMP is not useable in many workflows. I can see why allowing user control over the TRC isn't on the list of bugs for 2.10. But I don't understand why this bug is being closed as "won't fix". Does this mean high bit depth GIMP will forever more use only the sRGB TRC and the user will be stuck with whatever "per op" TRC encoding is specified in the code? And there won't ever be even the simple ability for the user to say "please leave the RGB channel values alone"?
See comment #2 babl will NOT add API to short-circuit TRC manipulation and make "RGB" == "R'G'B'"; which is what the title of this bug reports suggests. The needs raised will hopefully be addressed in other - more predictable ways. Some operations warrant having a user choice of linear or "the other" TRC - for now and until babl has support for customized primaries and TRCs that other TRC will be the sRGB TRC. Futher into the future it might be that such "work on linear" toggles, are no-ops on linear data and only do something if the chosen R'G'B' is not already a linear color space. A challenge in draining the swamp of 8bpc assumptions in GIMP is doing so in a manner that improves and empowers most users workflows; without adding more confusing global UI toggles.