Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise



On 10/04/2014 11:59 AM, Øyvind Kolås wrote:

Internally GEGL doesn't use ICC for this but
BablFormats which represents a subset of possible ICC formats. The
"profile connection space" used by babl is linear RGB with sRGB
primaries, since this permits very low overhead for doing operations
in this color space; a color space which also is suitable for these
operations (most layer compositing modes and blurring).

Do you think sRGB primaries are more suitable than other RGB working space primaries for editing images produced by today's digital cameras when shooting raw, and/or images intended for either printing on a wide gamut printer or displaying on a wide gamut display?

The problems you've pointed
out with for instance multiply have led to a consensus that we will
also need a target-space/working-space choice, perhaps two; one linear
and one more perceptual.

The target profile colorants will need to be retrieved and held in memory to deal with editing operations that fail when done using the sRGB primaries. Multiply is not the only such operation.

There aren't many places in the BABL/GEGL/GIMP code base that use hard-coded sRGB parameters. So why not pass the user's preferred RGB working space ("target") colorants to the operations that currently use hard-coded sRGB? This will allow GIMP to be a properly color-managed image editor.

For example, the code base currently uses hard-coded sRGB Y values, mostly retrieved from #define statements. Use the target colorant Y values instead.

You cite overhead as a reason for using hard-coded sRGB.

How much overhead difference could there possibly be between calculating Luminance using hard-coded sRGB Y values retrieved from #define statements, compared to using the target RGB working space colorant Y values retrieved from memory?

You frequently cite the BABL conversion from sRGB to XYZ and then to LAB as a reason to use the sRGB primaries as your "PCS". Why not rewrite that conversion to use the target profile colorants to convert from the user's chosen RGB working space to XYZ? The current code needs to be rewritten anyway because it uses D65 sRGB xy values to convert to XYZ, so the resulting LAB values are wrong.

Respectfully,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography


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