[CREATE] Re: raw processing

[Will Stokes]

I think it's only appropriate we bring Andreas Huggel, the author of
exiv2 (www.exiv2.org) into this discussion as well. While exiv2 is a
C++ library, based on messages that have come through on the exiv2
yahoo group I believe it has successfully been used already in at
least one C# project, see:
http://uk.groups.yahoo.com/group/exiv2/message/152

Andreas, we're all discussing the problems with dealing with RAW image
and metadata, the lack of a common open source library for handling
these tasks, and what to do about it. We really need a mailing list or
newgroup so the information in these emails is not lost to additional
participants that keep getting pulled into this discussing...

--------------------------------------------------------
Will Stokes         wstokes (at) gmail.com
Album Shaper   http://albumshaper.sf.net
--------------------------------------------------------

On 3/16/06, Larry Ewing <lewing at novell.com> wrote:
> 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
>
>