On Oct 15, 2014 4:19 PM, "Elle Stone" <ellestone ninedegreesbelow com> 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