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 _______________________________________________ gegl-developer-list mailing list gegl-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gegl-developer-list
