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 _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
