On 11/05/2014 08:22 AM, Jon Nordby wrote:
    What you just described IS side-by-side implementations of
    operations. In an ICC profile color-managed application, sRGB is
    just another RGB working space. You don't need to special-case sRGB.


No it is not. There will be one implementation of say "multiply". It
will be able to work on any RGB color space. Including sRGB, but without
need for special casing.

    Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc.

    In Pippin's originally planned "unbounded sRGB architecture",
    "bablRGB" meant "convert the image to unbounded sRGB before
    perfoming *any* editing operation". Now the plan is that bablRGB
    will mean "convert to unbounded sRGB for *some* operations".


The meaning of the "bablRGB" specifiers has not, and will not change.
The vast majority of operations will just stop using them (because they
have hardcoded sRGB parameters), and instead use the new specifiers, as
per the roadmap.


For the babl code that converts an sRGB image to grayscale for use as a layer mask, do you plan to add a new set of functions that convert from UserRGB to grayscale?

That code would, of course, need to pull Y values from UserRGB. Which of course means that the new code for UserRGB would also work for sRGB images.

For the babl code that converts from color to Y for painting on a mask, that code currently is hard-coded to use sRGB Y values. Do you plan to add a new set of functions that convert from UserRGB to Y for painting on a mask? That code would also, of course, need to pull Y values from UserRGB. Which of course means that the new code for UserRGB would also work for sRGB images.

For all the GIMP UI functions that currently use hard-coded sRGB Y values sprinkled through babl, GEGL, and GIMP, do you plan to add a new set of alternate functions that will use Y values pulled from UserRGB? Again, that new UserRGB code will also work for sRGB images.

How is this not side-by-side implementation?

Why would any sane developer want to write all the new code and have it exist side by side with equivalent hard-coded sRGB functions?

What part of the latest new plan am I missing? Could you explain the purpose that is served by having all the functions with hard-coded sRGB parameters sit side by side with equivalent functions that use UserRGB parameters?

Or are you really getting rid of *all* the hard-coded sRGB parameters? In which case, what is the new purpose for the bablRGB formats that "will not change" their meanings?

Best regards,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography
_______________________________________________
gimp-user-list mailing list
List address:    gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Reply via email to