[Digikam-devel] proposal: use tags for album collections & image grouping

[Tibor Blenessy]

> 
>     I think, that db is wrong place to place modifications of file. 
> 
> 
> No. Later we can add a search UI to scan modification over image 
> versions... This is a very powerfull features. Imagine a query like this 
> : "I want to found all photo where i have apply Red Eyes Correction" 
> tool...
>  
> 
>     Maybe to
>     include this modification to custom jpeg  header (as digikam makernote) 
> 
> 
> No, a JPEG hearder can break interoperability. It's dangerous. And JPEG 
> is not the only one format used in photograph world. Do you know RAW ? 
> Pro photogrpah use it. This format is Read only...
> 
> Makernote (Exif in general) is dedicaced to store camera settings used 
> to take the picture. Better place is to use IPTC or, XMP I work 
> currently on XMP support.
> 
> Unforget than with JPEG, Exif or IPTC or XMP are stored in a JPEG 
> section which is limited to 64Kb.
>  
> With DB, we don't have limitation.
> 
> 
>     or use (develop?) custom image format (something based on xml + jpeg
>     blob, maybe svg is able to do this).
> 
> 
> I'm not agree to use sidebar file. We have already aDB dedicaced for 
> that. Using a sidebar will reduce the capability, especially for 
> searching. A metadata is a metadata. It must be stored in file when it's 
> possible. This is true with JPEG, TIFF and PNG.
> 
> Of course, and XML (XMP in fact with pictures) must be add in the 
> future, to improve interroperability.
> 
> RAW file is another problem. With Exiv2 library project, we will try to 
> give RAW writting support with all RAW files based on TIFF file format 
> (CR2, MRW, NEF, etc.) But it's not yet done...


Problem, as I see it, is, that such modification to the image are not 
meta-data anymore. This is kinda about definition of meta-data, but 
applying filters you change actual data of picture, not meta-data. So 
solution here is to create image format capable of tracking changes made 
to it. This is already implemented in XCF in gimp and psd in photoshop 
and in similar formats native to their editor. SVG is capable to store 
original bitmap and apply filters on it, but maybe this will be too 
complicated to adapt and implemented because SVG filters are simple 
convolution operations (i may be wrong with this).

As main problem to store such changes in DB I see this situation - I 
have original image, on which I've removed red eyes. When seeing this 
file in digikam, I see red eyes removed. I want to print that image 
using some internet photo lab. So I open my browser, locate file on fs, 
upload to the photo lab. Of course browser has no idea about digikam db 
and I will send original picture with red eyes to photo lab. Oops... I 
don't see solution to this. Only by using some other image format 
capable of tracking changes. For searching, this changes can be mirrored 
in db (like it is done already with some exif fields). Using different 
file format doesn't provide solution to photo lab problem, but at least 
it prevents it to happen (what I see in digikam, is what will be printed 
in photo lab). Ideal way will be, if photo lab will understand to that 
change-tracking-capable format and apply changes before printing photo. 
Maybe if that format will be successful enough...


Tibor Blenessy