[CREATE] OpenRaster, some open points

[Øyvind Kolås]

On 3/13/07, Cyrille Berger <cberger at cberger.net> wrote:
>  . mask handling, currently, while it's not clearly stated in the draft, masks
> are stored as children nodes of the layer on which they are applied. But a
> second proposition has been made: masks could be handled as a filter layer,
> The main drawback is that the XML looks heavier this way, but the
> implementation should be easier, as you won't need to add a special way to
> handle masks as they would be correctly handle by the allready existing
> filter mechanism.
>
>  . it needs to be bullet proof, I would like to know if there is any points
> that need clarification ?

Handling layer masks as a special filter effect was the way I
originally proposed, and I am glad it is moving back in that
direction. I hope to have the available time to do some OpenRaster
hacking in ruby on top of GEGL before LGM, for the immediate future I
have limited amounts of available hacking time though.

> - supported color spaces in baseline, RGBA (integer and float for HDR)
> 8/16bits, GRAYA (integer) 8/16bits, CMYKA (integer) 8/16bits are must have.
> But Krita and gegl supports (or will supports) a much broader variety of
> color spaces (LABA, XYZA, YCbCrA...), the question is : is there an interest
> to consider some of those as important for interoperability, and therefor,
> needed to be included in baseline ?
> - data storage specification
>  . png for RGBA integer 8/16bits and GRAYA integer 8/16bits
>  . exr for RGBA float 16/32bits

I think it makes sense to limit the baseline to RGB(A) and GRAY(A),
with 8bit/16bit precision, thus making PNG an adequate format.
OpenRaster is meant to be used primarily for work that is raster
graphics, our primary source of raster images are digital cameras and
digital cameras produce RGB images. The sensors of the human eye are
(linear) RGB. CMYK only makes real sense as an output format tied to a
specific output device (with a profile) not as an input image to do
compositing on. When mixing layers that are RGB and CMYK an
application will most probably have to convert the CMYK data to RGB to
do the compositing anyways.

> Some have expressed concern that having a specific data storage specification
> will make it complicated for a great variety of projects to write a complete
> implementation. On the other hand, at least CMYK 8/16bit is a must have, and
> none of the above fileformat supports it. And I also thinks that the above
> formats (or any other) are not unnecessarily the most efficient file formats
> for daily usuage in either the Gimp or Krita, and having either of them use a
> (even slightly) different fileformat will defeat one of the strongest
> interest of OpenRaster.

EXR allows storing an arbitrary amount of named components per pixel,
storing CMYK, HSV, CIE Lab or other arbitrary representations are
possible there.

When it comes to the issue of daily use I do not think it is
reasonable to expect a power user to be saving an exchange-ready
OpenRaster document when he is working on a project; it is more likely
that he would be exporting to exchange-compliant OpenRaster when
moving data between applications. I foresee for instance that a GEGL
using application might be using it's own internal swap format for the
buffers when working on the image for fast save/load times. When
archiving the project those buffers would be serialized as EXR/PNG as
appropriate.

> - vector layer, tinySVG (see http://www.w3.org/TR/SVGMobile12/) seems to be
> enough for the need of OpenRaster

Replying to a reply to this mail, I think the same issue applies here,
CMYK should not be the responsibility of OpenRaster, and neither
should final vector output be,
if in a layout in scribus the user wants to combine CMYK/spot color
based vector graphics over an image that vector graphics should
originate in scribus and not the OpenRaster document, for all purposes
a color managed RGB output _raster_ from an OpenRaster rendering
engine would be appropriate to turn into CMYK.

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