libopenraw the story

[Hubert Figuiere]

Hi,

I suck a bit, I just joined the list. I thought that as an admin I was
automatically subscribed....

I read through the archives and I will try to debunk a bit all the
question you asked.

Unlike I announced, libopenraw is being written in C++. In fact I after
a bit if "experimentation" in order to settle to a direction to take, I
started rewriting in C++ because it makes my life either, On gobject
fanatics want to do OO programming in C.

I insist on having a pure C interface. The reason behind that is
language neutrality (bindings in C++ is still a PITA without a real
component model, hello Mono users!) and abstraction: all types are
opaque pointers.

The dependencies will be restricted as much as possible. libstdc++ at
most. Possibly libexif for the high-level EXIF handling (see later if
you have exiv2 in mind). No Qt, no glib. The file IO will be abstracted
to allow plugging gnome-vfs or kioslave if desired.

As for the licensing, it will be LGPL. I insist on this point for
several reasons. One of them is it is more compatible with other
licensing than GPL and with "media", who knows what the industry will
come up with in term of patent restrict and other to slow us down.
That will make it incompatible with Exiv2 per-see, even if there could
still be a library written to convert metadata to Exiv2 compatible
data.... (as a second library released under GPL).

API:

The set of API I have in mind include the following functionnal components:

-identify the raw file
-extract the thumbnail, preview and/or JPEG version
-extract the camera metadata as EXIF (possibily XMP to include specific
data not part of EXIF)
-set the processing parameters
-process using the "standard" algorithm
-process using the application provided algorithm.

File formats:
While I envision parsing as much files as possible, I plan to have:
CR2 (20D because this is what I have, but I have 5D sample as 30D should
be available), CRW since they are quite common and I have the spec of
the container format, and NEF (Nikon) for which there is a lot of sample
around too. DNG will logically come, because of it documented nature.
Off course any other format support is welcome, and don't intend to
restrict anything (unless you want to rely on a proprietary library to
do it).

That is the current dump of my memory as I haven't yet had the time to
spend to code much.
If you have any question, this list is here for that.


Hub