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
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?
Color management and free/libre photography
gimp-user-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list