[CREATE] [Mypaint-discuss] Linear light workflow

[Andrew Chadwick]

On 05/04/12 01:51, Martin Renold wrote:
> On Thu, Mar 29, 2012 at 10:15:47AM +1030, David Gowers (kampu) wrote:
>> 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.

Every PNG-supporting app should do that really, without exception. I
have some experimental code written here which does just that using lcms2.

>> 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.

Non-RGB spaces are already excluded in practice thanks to the use of the
PNG format.

We should not force apps to cope with arbitrary compositing spaces. It's
better, IMO, to define the space in which each compositing operation
works, and state that the svg:* Porter-Duff ops must be applied in
linear RGB (I think any linear RGB space would do for separable P-D ops,
including ones with imaginary primaries, but I may be wrong). I think
leaving working space undefined gives app developers the most
flexibility in implementation, which is something you want if the format
is to be adopted. Plus associating each compositing op with a working
space is closer to the way GEGL works...

IMO, all apps should just write the best and most complete PNG files
they can, which pretty much means embedding ICC profiles for offbeat RGB
variants. The PNG spec defines a *really* nice fallback mechanism which
can be used by apps which don't handle ICC-based transforms or the fancy
sRGB gamma curve if the PNGs are correctly written.

It adds complexity to support additional ICC profiles describing the
data, and also leaves room for the PNG files to be undetectably
incorrect. If a user wants to break open a .ora file and work with the
PNGs inside directly, they should be able to.

> 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.

Yeah, linear RGB data using the sRGB primaries looks horrid when stuffed
into an 8-bit container even with a profile for "linear sRGB" attached.
Rounding will do that. It's fine to gamma-compress the same data before
downsampling and saving of course, but representation should be a
decision left to app developers

No objection to permitting 16-bit PNGs in ORA containers, but apps
should support any permissible PNG bitdepth. My test code does this
(I'll push it soon, honest).

I think the only stipulation MyPaint should insist on in PNG files is
that they must not be interlaced :D

> 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.

8bit sRGB as a working space is a bad idea for many reasons, and I don't
see any reason why OpenRaster should help perpetuate it. I'm still
happier now with the idea that defined compositing ops should have
defined working spaces, and leave working space undefined.

> 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).

I'd be happy for an sRGB requirement on mergedimage.png, let's do that.
We already state that it may be either 8 or 16bpc.

-- 
Andrew Chadwick