[CREATE] OpenRaster fallbacks (proposal/RFC)

[Cyrille Berger]

On Saturday 29 August 2009, Martin Renold wrote:
> Maybe it's a bit ugly to require an application that can't deal with 16bit
> PNGs to recognize them by opening them...?
>
> I have now tested 16bit PNG layers. Krita and MyPaint seem to convert it to
> 8bpc and load the file.  DrawPile shows an error and doesn't load anything.
That sounds like a bug in Krita, it should be able to open it at 16bit, or 
maybe it's just that the main image is always marked as RGB 8bit (very likely) 
and the layer is actually 16bit, do you have the file so that I can check ?

Now that I think of it, I seems to remember there is a function in libpng that 
always return a RGB 8bit image (whatever the original image is, 8/16bit RGB, 
grayscale, indexed). It's very possible that MyPaint use that, and DrawPile 
doesn't.

But if there is that API, we can as well says that the fallback can be any 
kind of PNG, and people who only support RGB 8bit would be advised to use that 
API.

> The question that I was asking myself was: how could MyPaint (or any
> application) start saving data with more than 8bpc into OpenRaster files
> today, such that they also load correctly in all existing OpenRaster
> implementations?  And if that's not possible, what can OpenRaster provide
> to prevent such breakage with every new feature that gets added in the
> future?

On that point, I am not too concern about those breakage, I think that 
OpenRaster goal is interoperability, but if that goal can only be achieved in 
a year, it's not a big problem for me (as long as we communicate on this). So 
what it is important is that mypaint keeps being able to open old files created 
with older mypaint.

> > > Layer modes:
> > >
> > > Would a compositing mode other than OVER be implemented as an <effect>
> > > in OpenRaster?  Or would the mode be part of the <layer> tag, which
> > > then can also have a fallback?  If so, can a <stack> tag also have a
> > > compositing mode?
> >
> > I am more for the <layer> tag. And defaulting to OVER.
An other option is what we discussed on IRC with Øyvind is to have composition 
recorded as a filter (it's what SVG does). By default it is over, and it gives 
this when you want to change it
<filter type="SUB">
 <layer />
 <layer />
</filter>

It's a bit more cumbersome, but it allows to give parameters to composite op. 
And also allow more fine grained fallback.

> Okay, most applications work that way. But what would the fallback of a
> layer be?  Let's say I have a 64bit floating point layer with some
> compositing mode other than OVER that is not implemented in all
> applications.  Would the 8bpc fallback contain the layer data or the
> composited image stack?  Doesn't seem to work...
the fallback of, a CMYK layer would be the converted 8bpc RGB image. The 
fallback of the stack

> > > Filter/Renderer variants:
> > >
> > > Implementation might like to have a way to decide whether they can
> > > render something without fallback.  This can be solved with version=...
> > > attributes.
> >
> > I don't follow you, you mean different version of the filter ?
>
> I was thinking about adding attributes to an existing filter.  But maybe
> filters should be specified such that the application needs to verify all
> attributes.  If not, it cannot render it correctly and should use the
> fallback (and/or warn the user).
I think so.

-- 
Cyrille Berger









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/create/attachments/20090902/21437992/attachment.html