From Create Wiki

Contents 1 Open for comments 1.1 Color Management 1.2 File formats 1.3 Fallback 1.3.1 projection 1.3.2 detail 1.4 Data storage 1.4.1 Jpeg or not jpeg 1.4.2 Generic Data Storage 1.5 Metadata 1.6 filter tag

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.

I think those should not be marketed as different file formats, but as compatibility-level that a given application has implemented. Like "application XYZ supports the full OpenRaster/Printing specification". I see no point in the statement "this is an OpenRaster/Printing document". Who would care that it is? Any application would just load everything that it understands, and use defaults for attributes that are missing. --Maxy 08:41, 15 December 2008 (UTC)

Hm actually I'm not so sure any more about this. Different file formats (with different extensions) could also help the user to be confident what applications can load it. But except for the "Long-term Archiving" you rather seem to have the default image quality in mind than the compatibility level. I don't see the need for different file formats just for the quality settings. --Maxy 16:13, 24 December 2008 (UTC)

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>

I strongly prefer that one, since a simple implementation can just ignore the detail tag. I assume that inside the detail, there should be the real source image for the filter? --Maxy 08:18, 15 December 2008 (UTC)

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).

IMO Tutorial is too much of a special case to support. I prefer not to allow jpeg, this also simplifies the minimal implementation. --Maxy 08:18, 15 December 2008 (UTC)

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 ?

Pyramids and tiles are something the application can build while loading. I don't see the big benefit of storing anything but scanlines. The application might even have to convert from the stored tilesize to its internal tile size! However a scaled-down version of the fully rendered image could be stored for thumbnails. --Maxy 08:18, 15 December 2008 (UTC)

Metadata

• XMP
• RDF
• OpenDocument Metadata

Most definitely support XMP IMO because it can express RDF and is pretty much the standard. Also, its what Creative Commons supports, Adobe, Microsoft, etc Jon Phillips 19:08, 1 January 2009 (UTC)

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.