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@xxxxxxxxx> wrote:
>
> On Oct 15, 2014 4:19 PM, "Elle Stone" <ellestone@xxxxxxxxxxxxxxxxxxxx>
> wrote:
>>
>> 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@xxxxxxxxx
> List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
>
>
_______________________________________________
gegl-developer-list mailing list
List address: gegl-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
