OpenRaster/Open for comments

From Create Wiki

Jump to: navigation, search

Contents

Open for comments

This page is a summary of the point that are under discussions and need to be solved. Add your comments to this page.

Color Management

What level of color management ? Which color spaces ?

File formats

How many file formats should be defined and maintained directly by OpenRaster ?

Here is the list of possibilities :

- OpenRaster / Long-term Archiving
- OpenRaster / Printing
- OpenRaster / Panorama
- OpenRaster / Photography (it should be a list of filters embedded in PNG, JPEG or TIFF files)
- OpenRaster / Tutorial (using jpeg as storage)

A file format is usefull to specify what a reader who wants to achieve a certain level of interoperability need to implement.

Fallback

One of the objective of OpenRaster is to ensure interoperability and to ensure that a document can be opened in different applications and look the same. But the specification shouldn't be a limit to what an application can do, so it should be possible to extend OpenRaster, but to still provide a file that can be loaded on different applications. So this section is about choosing a solution to this problem.

projection

<filter name="nonstandard:somefilter">
  <projection src="projection_for_nonstandard_filter.png" />
</filter>

detail

<layer src="projection_for_nonstandard_filter.png" >
  <detail>
    <filter name="nonstandard:somefilter" />
  </detail>
</layer>

Data storage

Jpeg or not jpeg

There is two reasons in favor, if the original image is a Jpeg, there is no sense in decompressing it and recompresing it in a different file format, the second argument is that it could be usefull to creates small files to use on tutorial for internet.

The main inconvenient is that it could be misused and lead to a missconception that OpenRaster is a bad quality specification. An alternative is to allow Jpeg only in a limited number of file formats (such as OpenRaster / Photography or an OpenRaster / Tutorial).

Generic Data Storage

This is needed because most existing file format support a limited number of color spaces. But what level of features do we want ? Only scanlines or tiles ? Pyramid ?

Metadata

  • XMP
  • RDF
  • OpenDocument Metadata

filter tag

  • Currently filters are described like this in the layer stack specification
<filter name="standard:blur" type="standard:gaussianblur">
  <params>
    <param name="radius">10</param>
  </params>
</filter>

The main weakness is that this doesn't allow DTD/RelaxNG checking and validation.

  • An alternative is to defined them like this
<filter:standard:blur radius="10" />

or

<standard:blur radius="10" />
  • An other alternative would be
<filter:standard:blur>
 <radius>10</radius>
</filter:standard:blur>

The last two propositions have the advantage to allow DTD/RelaxNG validation, while still allowing extensability.

Personal tools