[CREATE] Linear light workflow
Andrew Chadwick
a.t.chadwick at gmail.com
Wed Mar 28 11:33:58 PDT 2012
On 28 March 2012 17:08, Boudewijn Rempt <boud at valdyas.org> wrote:
> I tested today in krita -- it's a little known thing that Krita supports a linear-light workflow perfectly well. Basically, it's a matter of using the right icc profile to define the working space and the example Andrew showed just works in Krita.
>
> Wouldn't it be easier to just define the working space with a profile in openraster, and take it from there?
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...
Thinking about colour-management chunks in the PNGs actually gives us
another way of distinguishing legacy "composite in nonlinear sRGB"
MyPaint ORAs from Krita's "composite in linear whatever" ORAs.
Historically MyPaint *hasn't* saved any colour management chunks at
all, and Krita *has*. MyPaint+1 could easily look for layers without
{sRGB, cHRM, gAMA, iCCP} chunks[1], and assume historical behaviour if
the first one it sees is such a layer. Perhaps that's sufficient for a
MyPaint-specific workaround; in that case, OpenRaster could just
specify that compositing operations must happen in linear-foo (linear
display?) space, which is cleaner than faffing around with extra
attributes.
Short form; if people want to chase colour management in ORA, let's
consider using the existing PNG definition as the vehicle for it.
[1] http://www.w3.org/TR/PNG/#11addnlcolinfo
--
Andrew Chadwick
More information about the CREATE
mailing list