[CREATE] OpenRaster reference library - libora

Luka Čehovin luka.cehovin at gmail.com
Thu Jan 21 04:16:12 PST 2010


>>
>> So far I have left out filters and such, because I am not aware (call
>> me ignorant if you wish) of any application that would use them very
>> intensively.
> Well krita does since 1.5, and next version of Gimp will. But, both of them
> might not be the main customers of your library, at least for Krita, which has
> already its own facilities for open raster.

It is not _my_ library :D Anyway ... in what language is Krita open
raster support written in? Because no application is forced to use
libora, but libora could use some existing code perhaps ... just an
idea. My original idea for libora was that a lot of work should go
into making the IO operations as fast as possible ... and this is what
I think that everybody needs at the moment because OpenRaster IO is
very slow.

>
>> For now my plans are to add thumbnail support and global metadata (are
>> there any specifications on that?) ...
> No, not yet. I think we are aiming at support for RDF/XMP, with something like
> that:
>
> <layer ... metadata="data/layer1metadata.xmp" />
> and
> <image ... metadata="data/imagemetadata.rdf" />
>
> Unless we want to have more than one metadata file per-layer, and do something
> like:
> <layer ...>
>  <metadata type="xmp" file="data/layer1metadata.xmp" />
>  <metadata type="rdf" file="data/layer1metadata.rdf" />
> </layer>
>

This sounds like it is still being discussed. And I think this is the
main problem of the standard or the proposal ... almost nothing is
fixed. I really have little interest in implementing something that
does not have some consensus and formalization ... one can hardly call
it a standard then. What I am trying to propose from the beginning
(and nobody wants to comment apparently) is that some simple version
of the standard is formalized and everything that is still discussed
is postponed. We insert some version identifier in the format and call
the current standard version 1.0 for example. Then we start from there
and make things more complex. As the most evolved applications (like
Gimp and Krita) use their own formats I see no problem with that ...
and we can finally have some final version of the standard that can be
used by all the more simple specialized applications to gain at least
basic data-connectivity with ... lets say Gimp.

cheers,

-- 
Luka Čehovin
http://luka.tnode.com


More information about the CREATE mailing list