[CREATE] Re: raw processing

[Larry Ewing]

I think I'll jump in here an introduce myself.  I'm the lead developer
for F-Spot (see f-spot.org).  As was already mentioned it has some
limited RAW browsing support now, with plans to expand that in the
future.

On Thu, 2006-03-16 at 23:41 +0100, Udi Fuchs wrote:
> I am amazed at the interest that is shown here for raw image
> processing. I've being working for over a year now on UFRaw. There are
> a few people that contribute some code, but most of the work I do by
> myself in my free time.
> 

I think there has been a lot of work done on the various RAW formats and
processing in separate projects and probably too little communication.
Hopefully we can turn this around a bit.  One step we could start with
is dumping some of our combined knowledge about raw formats and raw
metadata somewhere public.  I'm sure we all of know a little bit about
various aspects of the problem space that would be good to share.

On the metadata side F-Spot has custom some custom code to read
jpeg/tiff/png/iptc/XMP metadata as well as partial support for several
other non tiff based raw formats.  The metadata writing support is much
farther behind right now but coming along.  Exiv2 looks very nice but
would be very difficult for me to use because of c#->c++ invoking issues
on mono.  Given that it is probably unlikely that everything can
standardize on using it, but on the positive side reading and writing
complex file formats is something where free software a whole probably
benefits in having more than one implementation, at least until we shake
out the bugs.

> I think that some people here are under estimating the complexity of
> raw conversion. It is no rocket science, but it is more complicated
> than just running dcraw. dcraw is responsible for decrypting the raw
> information and gives some basic conversion option, but you need a
> tool like UFRaw to fully control the conversion of the raw image to an
> RGB image that could be later handled by standard programs like the
> Gimp.

The ufraw conversion code is very interesting, I'd love to talk to you
about it sometime.

> If one of the above suggested libraries has a design document I would
> be glad to comment on it. It would be great if UFRaw could use such a
> library.
> 
> You are also welcome to join UFRaw's development. At the moment
> UFRaw's internal API cannot be exported as a library, but it could
> reach this point with enough work. We (Neils Bech who helps in UFRaw's
> development and I) have the best experience in maintaining code, which
> is updated regularly with dcraw.
>
> I think that UFRaw's code is a good basis for developing a library and
> in general for standardizing the raw work flow.
> 

The code is definitely a good start from moving away from using dcraw
via pipes.

--Larry