[CREATE] [Mypaint-discuss] Linear light workflow

[Martin Renold]

I may not understand color profiles fully yet, but I'll risk a response.

On Thu, Mar 29, 2012 at 10:15:47AM +1030, David Gowers (kampu) wrote:
> On Thu, Mar 29, 2012 at 5:03 AM, Andrew Chadwick <a.t.chadwick at gmail.com> wrote:
> > This is drifting a little far away from a discussion of compositing op
> > gamma, but just to remark that colourspaces can already be
> > encapsulated in each individual PNG layer graphic, and should probably
> > be used for conversion into whatever internal working space is used by
> > the program if they're specified. If you add another top-level
> > profile, you'd have to define which one takes precedence for a given
> > layer PNG...
> 
> The requirement for an ORA supporting app to be able to do colorspace
> management seems a bit heavyweight.

Maybe. At least the ability to do a single colorspace conversion is not very
exotic: even a couple of image viewers can do it, in order to display PNGs
with embedded color profile correctly.

> If any profile is included, IMO requiring all images to be in that
> colorspace will head off some complexity issues.

A single color profile that defines both the working space (for compositing)
and the internal encoding of the layers is a concept that fits into my head. 
If I understood everything correctly, there would be no need for a separate
"linear vs non-linear" concept once we have that.  Existing ORA files would
just default to sRGB as their working space.  We could make restrictions on
the allowed working spaces, e.g. restrict gamma to be either 1.0 or as
defined in sRGB, and exclude color spaces like HSV.

But we cannot use 8bit PNGs without gamma compression - that would be way
too lossy.  We could use 16bit PNGs (which are allowed anyway).  But if you
consider that any ORA application will probably allow to copy-paste a sRGB
PNG from the clipboard, it will have a way to convert a sRGB PNG into its
internal working space, so we can do that conversion at loading time, too.

Andrew Chadwick wrote:
> in that case, OpenRaster could just specify that compositing operations
> must happen in linear-foo (linear display?) space

Doing a linear-light "over" operation in an application that is using 8bit
sRGB as working space sounds complicated/unusual to me.  I'd guess that most
applications developers would prefer to change their internal working format
instead, if ORA forces them to choose one way or the other.

Obviously, applications that only support sRGB will only be able to work
with sRGB ORA files correctly, but as far as I see there is no reasonable
solution that prevents this problem.  (Except maybe include the fully
composited image in all ORA files, always as sRGB PNG).

-- 
Martin Renold