[CREATE] raw processing

[Kai-Uwe Behrmann]

Why is David Coffin not included in this discussion?

For CinePaint, we would stay with the good support of Dave. Currently we 
have less problems with dcraw. Some add ons would be fine, but 
currently nothing, which is not possible with dcraw.

What would libopenraw provide? reading ...
ok, thumbnail access and extracting of metadata.
How is its relation to www.openraw.org ? Is the name clash a decission?
Will it adress the requirements of photographers stated at openraw.org?

Adobe is in critique for its raw2dng converter, because of a serious 
reasons - data loss, avoiding a well defined format by backdoors, 
incomplete specification ...
DNG writing is a sensible matter and chances are good to make many things 
worse compared to the original RAW.

Does standardisation really cope with the complex options arround the DNG 
format? In other words will every application handle a complex options 
file the same way? Or would it be more easier and relyable to export from 
one application into say PNG or TIFF and proceede from there?

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name


Am 15.03.06, 17:09 +0300 schrieb Alexandre Prokoudine:

> Greetings,
> 
> I usually try to avoid crossposting kind of stuff, but since some of
> concerned people are not subscribed to the list, let it be so this
> time.
> 
> For those of you who doesn't know what CREATE is: this is an
> umbrella-project where developers of graphics (and hopefully
> audio/midi too) applications meet and talk about uniform solutions and
> standards.
> 
> Details: http://create.freedesktop.org/wiki/index.php/About
> Activities: http://create.freedesktop.org/wiki/index.php/Main_Page#Specifications
> 
> Those who have experience of work with Windows software for processing
> RAW know that each and every application has its own way to store
> changes introduced to originals.
> 
> Adobe Camera Raw saves them to .xmp files for every changed file, e.g.
> if IMG_0001.CR2 file was changed, IMG_0001.xmp appears. Canon's native
> RAW processing software saves all changes to a database file
> ZbThumbnail.info on per-directory basis. Picasa saves Picasa.ini on
> per-directory basis. And there are many more 3rd-party and camera
> manufacturer's applications.
> 
> Thus, once you applied changes in one application, you cannot load
> them in some other one.
> 
> Currently we have UFRaw as standalone application and as GIMP plug-in,
> a couple of (obsolete) RAW loaders for GIMP, initial RAW loader
> plug-in for Krita, initial support for RAW processing in Digikam and
> plans to introduce RAW processing in F-Spot soon.
> 
> UFRaw can save its own ID files on per-file basis for further batch
> processing. F-Spot tends to keep everything in its own sqlite database
> kept in depths of ~/.gnome/. I don't know the way Digikam works,
> haven't tried latest version.
> 
> Does anybody else perceive it as a problem? If so, is there some way
> we could avoid situation we have on Windows/Mac OS X since workflows
> in these applications/plug-ins are different to some extent?
> 
> P.S. Some (most) of you are attending Libre Graphics Meeting this
> weekend, probably you could have a talk together ;)
> 
> Alexandre