[Gegl-developer] Possible strategy for improving file format support in GEGL

[Jon Nordby <jononor gmail com>]

at LGRU in Bergen (http://www.piksel.no/pulse/lgru) we (mainly Øyvind
and I) have been discussing how to improve the file format support in
libre graphics applications, or more specifically how to use GEGL to
do this.

The following document is a summary of that discussion, including a
proposed plan for improving the situation. I believe that some of the
items are great material for a future GSOC project. I am willing to
mentor/help anyone working on these items (also outside the scope of
GSOC, of course).

-------------------------------------------------------------------------
Improving file format support in GEGL

== Current status ==
[v] Can import/export a render of most common
non-structured/single-layer raster formats
[x] No metadata import or export in files
[x] No import or export for structured formats like OpenRaster, PSD, SVG, XCF

== Notes ==
Different levels of file format support, from most basic to more advanced
1. Rendered import
2. Structured import
3. Structured export

Convention: the node returned from file load handlers is
always a document top-level node. This is the node where one can get
a render of the document, where document-level metadata is stored. Within
this node a subgraph may exist, allowing applications to access the structured
data.
Implementation: API for a file handler to get the node that represents
the top-level
document and where the information should be put. Important due to
gegl:load being
a meta-op.

For structured import it needs to be possible for an application
using GEGL to map the GEGL graph to the "proxy objects" that make up
the application document model. One approach to this is to define and
make use of "high-level" (meta) operations that would closely map to
what applications typically use in their document models. Examples:
Layer, Image, TextLayer

The GEGL graph to be exported to a structured format
may contains operations that cannot be natively represented in the
target format. This can be either because the application using GEGL allows
these operations, or that the import format is richer than the export format
in some areas. In these cases the export mechanism needs to gracefully fall
back so that as much data as possible is preserved.

Standardize on XMP as the internal representation. On import, well-known
file format specific metadata is normalized to XMP. Unknown metadata should
be preserved and made accessible in its original form.

== Tasks ==
Milestone 1: Allow ORA, PSD and XCF to be rendered in
any application making use of GEGL (or GdkPixbuf or QImage)

- Current file handler selection is based entirely on file extensions
 * Needs to allow selection based on mime-type and/or file-sniffing
 * Needs to be able to provide enough metadata about handle-able
   types to satisfy GdkPixbufLoader and QImageLoader interfaces.
- Provide a GEGL load file handler for PSD in GIMP (load-psd)
- Provide a GEGL load file handler for XCF in GIMP (load-xcf)
- Provide a GEGL load file handler for ORA in GIMP (load-ora)
- Provide a GdkPixbufLoader plugin in GEGL
- Provide a QImageLoader plugin in GEGL


Milestone 2: Basic meta data handling using XMP

- Implement XMP import of document-level metadata from XCF in load-xcf
- Implement XMP import of document-level metadata from PNG in load-png


Milestone 3: Structured import/export of OpenRaster,
pave the way for structured import/export of other file formats

- Implement a structured import/export handler for OpenRaster in GEGL
- Use this implementation in GIMP, maintaining a mapping between the
GEGL graph and GIMP document structure
- Use this implementation in MyPaint, maintaining a mapping between
the GEGL graph and MyPaint document structure

Milestone 4: Structured import/export of XCF, PSD

- Plan can be decided based on the experiences with milestone 3



-- 
Jon Nordby - www.jonnor.com