Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL



In his last post on the topic Pippin said:

Once we have the vocabulary to also describe this aspect of the
pixelformats used by operations, the first thing we should do is to
annotate all the operations which are broken when done with sRGB
primaries, then we will be able to continue refactoring, profiling and
optimizing; without breaking existing functionality/rendering. Not
only in terms of making more operations request directly userRGB, but
also doing things like make some linear operations accept any of
userRGB or bablRGB (or other linear RGB); and creating output buffers
in the same format – to avoid unnecessary conversions in such cases.

Using a fixed linear RGB format instead of userRGB is what for some
operations will provide the consistent results for the same property
values / slider positions. Knowing which operations this is important
for is easier to determine when we have code providing the vocabulary
in babl. The further along on the roadmap, more of the road will have
to be laid/determined as we walk it.


Nothing in the above post shows that Pippin has given up on unbounded sRGB. If Pippin really understood anything I've been trying to explain, he wouldn't still be saying things like:

//begin quote
"Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. Knowing which operations this is important for is easier to determine when we have code providing the vocabulary in babl."
//end quote

There is not one single operation for which it is important that sliders produce consistent results. NONE. NOT ONE. The whole premise that sliders should produce consistent results is grounded in a misconception of the requirements for RGB image editing.

Anyone not indoctrinated in the whole unbounded sRGB mystique that's been perpetrated among the babl/GEGL/GIMP devs for the last however many years would be rolling on the floor laughing if they could fight their way past the nonstandard "color management" vocabulary enough to understand what you all have been talking about all these years.

I no longer have the time to continue being actively involved with GIMP development (OK, that cheering in the background isn't nice! :) ). My hope is to see the whole unbounded sRGB thing abandoned. Let bablRGB be UserRGB. You can deal with device-specific code with a UI warning. An RGB image editor should NEVER mess with the user's RGB data without the user's explicit request. Behind the scenes conversions to unbounded sRGB is just wrong.

GIMP is important to free/libre artists. GIMP is also important to would-be refugees from Adobe Cloud. Artists need non-proprietary alternatives and specifically they need software that doesn't lock the user's work inside proprietary formats that can't even be accessed without a subscription.

(To forestall one of Pippin's stock responses, no, I am not advocating that GIMP be a PhotoShop clone. One reason I switched to Linux and free software was because I was unhappy with PhotoShop limitations regarding linear gamma image processing; sadly Cinepaint capabilities were overrated; even more sadly, all these years later GIMP high bit depth image processing is saddled with the whole unbounded sRGB overlay.)

If GIMP can't get ICC profile color management exactly right, well, DarkTable partly fills the gap with its built-in masks. And Krita is frankly leaving GIMP in the dust in very many ways. Krita is a load of fun to use for painting. But Krita not aimed at photographers and it's not as easy to use for strictly RGB image editing as GIMP would be, could be, if unbounded sRGB is just abandoned and the devs starting listening to potential and actual GIMP users.

What free/libre photographers really need is for GIMP to be everything it could be if ICC profile color management is properly implemented across the board for all editing operations. This whole unbounded sRGB thing is a dead-end street.

Best regards,
Elle Stone


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]