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

[Tibor Blenessy]

Tibor Blenessy wrote:
>>     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...

I've studied proposals in the wiki more carefully, and I've found that 
always storing modified image on disk and only track connections to the 
original (plus changes made) is partial solution to this problem, sorry 
for overseeing it. There is still another problem - changes made to the 
original picture outside of digikam, this can be solved by tracking 
image identity (also in wiki).

I've also studied TIFF image format, which support custom headers with 
no limitations. This can be used to store modified images and include 
changes in custom digikam tiff tags. TIFF also support multiple images 
in one file, so one can store original as another image in TIFF. libtiff 
is already capable of doing this. More info at 
http://remotesensing.org/libtiff/   Developing such change-tracking tiff 
files can be very useful to other projects too, this may be done using 
kipi-plugins?  Mirroring this change-tracking data in db maybe also 
useful, but putting it directly into file is more generic and solves 
automatically problems with changing location of original and derived 
image. Also other sw will be able to read and alter modified image data 
from such file, and digikam will be able to restore original image data 
despite outside modifications.

Tibor Blenessy