Re: [Gimp-developer] [Gegl-developer] babl roadmap

Yes, the majority of operations will operate in myfavoriteRGB space,
but you seem to be operating under the premise that absolutely *no*
filters can possibly exist that require a specific color space to
function properly. This isn't the case.

Take, for example, the color blindness simulation in gimp. This filter
tries to simulate color blindness so that artists can create images
that look good to people who are color blind. An operation like this
should not change based on which working space you choose to edit in;
it must always try to be as faithful to colorblindness as possible.
For an operation like this, being able to specify the working space on
the developer's side is a must. Otherwise, it can't work properly.

While operations like that might not be too common, it should still be
physically possible to create them. Before you say "okay, so a proper
icc color managed editor will convert between icc profiles, what's the
big deal?", realize this: babl is exactly the mechanism that we are
using to make that happen. These "background conversions" that you
seem to hate so passionately are exactly the same conversions that you
already admitted were necessary when copying and pasting between
images. Just because conversions shouldn't be common does not mean
they should be impossible, or removed altogether.

 -- Mike Henning

On Wed, Oct 15, 2014 at 1:27 PM, Jon Nordby <jononor gmail com> wrote:

On Oct 15, 2014 4:19 PM, "Elle Stone" <ellestone ninedegreesbelow com>

On 10/15/2014 08:30 AM, Øyvind Kolås wrote:

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone  wrote:

Hi, I fear you two are talking past eachother.

I will ask again:

For which specific RGB editing operations do you plan to convert the image
from fooRGB to unbounded sRGB before performing the operation?

Either the answer is "None. For color-managed fooRGB images, all RGB
operations will be done on data encoded using fooRGB primaries."

The answer is (to best of my understanding): Typically none. When chosing to
work in myfavoriteRGB for one "scene" (can be a GIMP document), all
operations which specify that they work in any RGB color space, using
babl_format("scene:RGBA float") will operate on myfavoriteRGB data. So if
there is myfavoriteRGB image as input, and that also is the desired output,
there will be zero data conversions.

Supporting any RGB spaces should be the case for the vast majority of
operations dealing with RGB data, including multiply/invert and similar.
With respect to the roadmap, these operations are *currently wrongly tagged*
to only work in unbounded sRGB. This is only because we don't have the new
architecture implemented yet!

I say 'typically' because if some operation *does* specify babl_format("RGBA
float") to indicate that it just works with unbounded sRGB, a conversion
will happen. This should of course *only be used in some cases*, when it
actually just works with the specific format. I can't immediably think of
any usecase for this, but there probably are some.

I hope this addresses some of your concerns,
Regards Jon

gegl-developer-list mailing list
List address:    gegl-developer-list gnome org
List membership:

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