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
_______________________________________________
gegl-developer-list mailing list
List address: gegl-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
