On Fri, Apr 18, 2014 at 4:22 PM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote: > I've been trying to summarize the discussion of whether some operations > don't work in unbounded mode sRGB, and if they really don't work, what can > be done to fix the problem. > > Is the following a fair summary of the BABL/GEGL/GIMP code? > > The BABL/GEGL/GIMP code is based on three centrally important premises: > > Premise 1: Any image in any source RGB color space can be losslessly > converted to the unbounded mode sRGB chromaticities. > > Premise 2: To provide consistent editing results, all editing should be done > using the sRGB chromaticities. An important side benefit of using the sRGB > chromaticities is that the performance impact of using LCMS for color space > conversions is thereby eliminated. Not entirely right as a premise; the premise is that editing/processing in ops should default to being done relative to XYZ; in pixel formats specifiable with babl (we control babl; and can decide how we extend it). > Premise 3: For any given editing/compositing operation, there is only one > correct color space in which that operation should be performed (for > example, linear light unbounded mode sRGB vs perceptually uniform unbouded > mode sRGB). As Alan Kay says, "simple things should be simple, complex things should be possible". Local; manual overrides of pixel format used would probably permit more complex workflows than global working-space overrides provides. > "Code-driving" conclusions follow from these three premises: > > Conclusion 1: For the sake of coding efficiency and consistent editing > results, images should be losslessly converted to the sRGB chromaticities > before editing the image. the sRGB chromaticities; or CIE Lab, or any other babl defined format. With a potential future babl lcms2 extension; the original pixels could even be kept in the layers raster storage.. doing so would have no effect on display of the pixels or processing of them since things are converted _on_demand_ to the pixel formats requested by the operations. Doing this would for the user not be functionally different in any way; apart from a risk of things being slower. > Conclusion 2: All required editing/compositing color spaces should be > hard-coded. The currently available editing/compositing color spaces > include: > a. unbounded sRGB with the perceptually uniform TRC. > b. unbounded sRGB with the linear gamma TRC. > c. CIELAB (the buffer is converted from unbounded sRGB to CIELAB) > d. HSL, HSV, Gray, etc (the buffer is converted from unbounded sRGB to > HSL, HSV, Gray etc). > e. ? (more can be added as needed). > > Conclusion 3: Every editing/compositing operations should be hard-coded to > use the correct editing/compositing color space for that operation. > > Hopefully the above summary isn't too far off the mark. > > Premise 1 is absolutely correct. Any image in any source color space can be > losslessly converted to any other color space as long as unbounded mode ICC > profile conversions are used. > > I have been trying to show that even though Premise 1 is correct, some > editing operations fail after an image is converted from the source color > space to unbounded mode sRGB > (http://ninedegreesbelow.com/gimpgit/unbounded-srgb-what-works-what-does-not.html). > > Some of the GIMP developers seem to agree that some editing operations do > seem to fail after an image is converted from the source color space to > unbounded mode sRGB. > > The proposed solution seems to be to modify the code that follows from > Conclusions 2 and 3: > > * Add code that remembers the source color space metadata. This way the > source color space chromaticities can be used to add to the list of color > spaces that are available for various editing/compositing operations. > > * When one of the affected editing operations is invoked, automatically > convert, or else provide the UI option to convert, the buffer to the source > color space chromaticities. Yes; this could also possibly be done in specific group of pixelformats :] > The arguments *against* adding an editing color space based on the source > color space chromaticities can be summarized as follows: > > 1. My demonstrations of where editing in the unbounded mode sRGB color space > fails are all *corner cases*, variously described as involving: > > * Highly image-specific colors (quoting from IRC, "an example of highly > input data dependent photo that with other colors would not have the > striking amount of data in the blue channel"). > > * A highly image-specific workflow (quoting from IRC, "workflow is > highly scene/data dependent; and might not make general sense") > > * Extreme, hence meaningless editing moves. At least some of them do - and not seeing out of gamut colors in the histogram in headroom/footroom on the sides are UI bugs. Apart from maybe color selectors GIMP-2.9 is a 8bit image editing UI with backend capabilities for more. Picking a different flower with other hues; would make redistribution among the components less of an issue. > 2. An unacceptably large amount of new and complicated code and UI > modifications would be required to accomodate the corner cases where > unbounded mode sRGB image editing fails. Or put differently; allowing the user to override processing globally at will - effectively _destroys_ actual color management, making whether things are color managed or plain wrong a highly likely choice in user configuration. As far as I have seen work has barely started in GIMPs UI with dealing with >8bpc images. > 3. When considered from the point of view of colors located in XYZ space, > HDR colors and out-of-gamut colors are essentially the same thing. So > many/most/all of the corner cases that I posted as examples of operations > that fail in the unbounded mode sRGB color space will be handled by code > modifications that are required anyway to enable GIMP to handle HDR images. > > Is this a fair summary of the discussion so far about operations that don't > work in the unbounded mode sRGB color space? Or from my point of the view I summarise it as stubborn operators/developers that want to be able to manually misconfigure/override color management like they are used to instead of dependable color management and consistency of operations. There are ways of achieving the goals that Elle is trying to achieve in the examples; that can fit into GEGLs strongly color managed internal architecture. Globally overriding the "working-format" is the approach that is most contrary to the architecture and removes the benefits it is meant to bring. /pippin _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
