[CREATE] OpenRaster

[Øyvind Kolås]

The scope and aim for designing the format is unclear. I think the
goal of the initial version of the format should be exchange of
layered images. Extra bells and whistles, for efficienct or arcane
features, that might be desireable to serialize the entire state of an
application should not be part of the initial core standard.

I think that for a core standard, with few compositing operators and
available layer effects, it should be possible to agree upon the
desired output.

On 6/21/06, Boudewijn Rempt <boud at valdyas.org> wrote:
> > * Image data should be stored in either PNG or "raw bits" - lossless
> > formats that are easy to access.  PNG should be used for any data
> > that which is compatible with it, and "raw bits" for anything that is
> > not (eg. CMYK or Lab data, floating point, etc.)
>
> Oyvind Kolas proposed to make it possible to also store jpegs as read-only
> layers. I'm not sure how to make that work without, though. Are you sure it's
> a good idea to make it impossible to store non-float rgb/grayscale data in
> the same way as cmyk/lab? Oh, and by "raw bits" -- do you mean no structuring
> of the pixel layer data in tiles?

My rationale for wanting JPEG data is the ability to exchange
compressed "preview" versions of a document, with the structure
intact. This can be useful as example material for tutorials and
similar, where download size matters. The biggest problem with JPEG is
that it doesn't support an alpha channel. (this can be worked around
by storing, and applying a layer mask).

Reusing existing single layer raster formats for the layers have
advantages. PNG is a good candidates since it supports RGB an
grayscale, with and witthout alpha in 8 and 16bit and is widely
supported. In my personal opionion OpenEXRs biggest problem is that
the interface is based on C++.

> > * I would use SVG Tiny/Basic for handling both Paths and Text.  I
> > think supporting the full ODF grammar for text layers is simply
> > overkill for this - and will tend to keep many implementers
> > away.  SVG 1.1/1.2 provide, IMO, all the text and path features you
> > should need.
>
> Probably, but don't we want OpenDocument compatibility here? Of course, paths
> and text can be viewed separately from compound documents that embed
> OpenDocument text and drawing documents. Compount documents really are
> needed.

Compound documents are not a must have feature in my opinion. Being a
bit conservative with scope creep.  (I have better understanding for
embedding OpenRaster in other documents than embedding spreadsheets or
audio as layers.)

/Øyvind K.

-- 
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/