proposal: use tags for album collections & image grouping

[Tibor Blenessy]

Hi

I'm user of digikam and recently I've to organize quite a lot of photos.
While using digikam I've thought about some organization principles used
  in digikam. I've read several bugs (since 2004) and proposals for
allowing nested album collections, allowing grouping of modified,
bracketing images, etc. I was thinking about some easy way to implement
solution to this issues.

This solution is based on creating new tree of tags (I will refer to
this tree as system tags). This tree of tags will not be available
directly to the user, but it will be used internally by digikam.

I'm not familiar with digikam code. So sorry, if something is already
implemented. I've looked at database structure and done some high-level
code browsing through websvn to get overall look about architecture.

Using tags for album collections

Under system tags tree, there will be tag Albums. Each image will have
tag from Albums subtree which means, that particular image belongs to
this album. Image participation to albums will no more be connected
through image position in filesystem. Albums tags will be created
automatically by standard ways, that are now used for album creation.
Images will be placed still in folders, but folders will have no meaning
to digikam.
To help user organize images in filesystem, there will be some organize
files dialog (maybe you know it from Amarok). This dialog will enable to
rearrange filesystem according to Albums tag subtree.
Using this architecture image can belong to multiple albums (this can be
configurable). Organize files dialog can solve this by copying images,
symlinking or explicitly asking user where to place image file.
Creating directory structure should be configurable by album name, album
date, etc. To get inspiration see Amarok's organize files.

Using tags for image grouping

Under image grouping I understand something like micro-albums. In one
group belongs images taken by bracketing or sequence shots, shots of
same scene, but different composition, modified images (resized, color
adjustments,...)

Such group should be displayed by only several representative images. So
if you have three bracketing photos, you create group and set as
representative (visible) image one with best exposition. Also in each
group, there can be several original (source) images, and they derivates
(for example group representing panorama).

To implement this, I suggest to create new tag tree Groups in system tag
tree. This tag tree can have following structure:

root: Groups
1. level: group type (bracketing, modifications, sequence, general,...)
2. level: concrete groups
3. level: visible, original

In UI, when user groups images, it is queried for group type and than
concrete group tag is generated and assigned to all images in group.
User than can select which image is visible from group, and which images
  are original.

When showing group in album, only thumbs from visible images are shown.
But in thumbnail is some clickable icon to expand/collapse this group.

This architecture allows that image can be in multiple groups
(personally I often have bunch of bracketing images which differ in
composition, so I would like to have one composition group with all
images and several bracketing groups)

Creating of groups should be automated as much as possible, so user
don't get bored with it.
- automatically detect bracketing and sequence groups using EXIF (my
Minolta Z1 includes this in Exposure Mode, other cameras probably also)
- automatically detect groups, when images are taken in short time interval
- detect groups from images that have same GPS info
- detect groups when images have same filename beginning
- automatically create groups, when changes are done in editor

Concrete group tags should be named automatically (maybe according id of
visible image, or some unique group name generator)

There should be some UI tools to add/remove images in groups.

In digikam bugs db there were several wishes to create some language to
apply color changes, and similar on the fly, without modifying original
image. I think, that this is task for some full featured image editor
(like gimp) and special image format (mostly this is available in native
editor formats like XCF in gimp through undo/redo functions). digikam
should only be able to read such file (what is already done, imho). Such
file than can be grouped with source file using proposed group feature.

There can be possible problem in performance, because there will be more
  queries to the db. I'm unable to estimate this, maybe someone with
more understanding of sqlite. But from my point of view, I have quite a
lot of tags and loading albums and searches is lighting-fast. Proposed
features will add only 1 tag to each image (to indicate album) and to
some images 1 or more tags (to indicate groups), so it should be ok.

I'm willing to help to develop this. I can program in C++, but I have no
previous experience with Qt (I would like to learn it). Hope this
wouldn't be too difficult to develop, because it uses already developed
digikam's tags infrastructure.

So tell what do you think about it. Whether it can be done, etc...

Tibor Blenessy

ps. i'm not native english, so if you didn't understand something email
me, I'll try to correct myself






















_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> Hi
>
> I'm user of digikam and recently I've to organize quite a lot of photos.
> While using digikam I've thought about some organization principles used
>   in digikam. I've read several bugs (since 2004) and proposals for
> allowing nested album collections, allowing grouping of modified,
> bracketing images, etc. I was thinking about some easy way to implement
> solution to this issues.

Some time ago I have collected some proposals:
http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion
Currently we are working on storing more image fields in the db, which still
needs discussion on this list in the next days.
The multiple collection paths feature is also in the working.

>
> This solution is based on creating new tree of tags (I will refer to
> this tree as system tags). This tree of tags will not be available
> directly to the user, but it will be used internally by digikam.
>
> I'm not familiar with digikam code. So sorry, if something is already
> implemented. I've looked at database structure and done some high-level
> code browsing through websvn to get overall look about architecture.
>
> Using tags for album collections
>
> Under system tags tree, there will be tag Albums. Each image will have
> tag from Albums subtree which means, that particular image belongs to
> this album. Image participation to albums will no more be connected
> through image position in filesystem. Albums tags will be created
> automatically by standard ways, that are now used for album creation.
> Images will be placed still in folders, but folders will have no meaning
> to digikam.
> To help user organize images in filesystem, there will be some organize
> files dialog (maybe you know it from Amarok). This dialog will enable to
> rearrange filesystem according to Albums tag subtree.
> Using this architecture image can belong to multiple albums (this can be
> configurable). Organize files dialog can solve this by copying images,
> symlinking or explicitly asking user where to place image file.
> Creating directory structure should be configurable by album name, album
> date, etc. To get inspiration see Amarok's organize files.

It's a historic feature of digikam that Albums represent file system
locations. I have found that there is no sufficient benefit of removing and
replacing this system, it is simple and easy. "Organize files" features dont
work with this of course.
To have images in multiple albums: use Tags ;-)

>
> Using tags for image grouping
>
> Under image grouping I understand something like micro-albums. In one
> group belongs images taken by bracketing or sequence shots, shots of
> same scene, but different composition, modified images (resized, color
> adjustments,...)

I agree that tags are the right choice for this.

>
> Such group should be displayed by only several representative images. So
> if you have three bracketing photos, you create group and set as
> representative (visible) image one with best exposition. Also in each
> group, there can be several original (source) images, and they derivates
> (for example group representing panorama).
>
> To implement this, I suggest to create new tag tree Groups in system tag
> tree. This tag tree can have following structure:
>
> root: Groups
> 1. level: group type (bracketing, modifications, sequence, general,...)
> 2. level: concrete groups
> 3. level: visible, original

Be aware that this quickly becomes complex!

For database storage, it would be better to break it down to one-to-one
relations for derived images, tags for grouping, a visibility flag per image
for visibility.
For creating a panorama D from A,B,C:
A -> D
B -> D
C -> D

I need to think a bit about grouping, no aswer to that yet.

>
> In UI, when user groups images, it is queried for group type and than
> concrete group tag is generated and assigned to all images in group.
> User than can select which image is visible from group, and which images
>   are original.
>
> When showing group in album, only thumbs from visible images are shown.
> But in thumbnail is some clickable icon to expand/collapse this group.
>
> This architecture allows that image can be in multiple groups
> (personally I often have bunch of bracketing images which differ in
> composition, so I would like to have one composition group with all
> images and several bracketing groups)
>
> Creating of groups should be automated as much as possible, so user
> don't get bored with it.
> - automatically detect bracketing and sequence groups using EXIF (my
> Minolta Z1 includes this in Exposure Mode, other cameras probably also)
> - automatically detect groups, when images are taken in short time interval
> - detect groups from images that have same GPS info
> - detect groups when images have same filename beginning
> - automatically create groups, when changes are done in editor
>
> Concrete group tags should be named automatically (maybe according id of
> visible image, or some unique group name generator)
>
> There should be some UI tools to add/remove images in groups.

Yes certainly. All this UI is a lot of work though ;-)


>
> In digikam bugs db there were several wishes to create some language to
> apply color changes, and similar on the fly, without modifying original
> image. I think, that this is task for some full featured image editor
> (like gimp) and special image format (mostly this is available in native
> editor formats like XCF in gimp through undo/redo functions). digikam
> should only be able to read such file (what is already done, imho). Such
> file than can be grouped with source file using proposed group feature.

There is definitely need for such a feature, at least to provide
never-edit-the-original which is required for a proper image manager IMO.

>
> There can be possible problem in performance, because there will be more
>   queries to the db. I'm unable to estimate this, maybe someone with
> more understanding of sqlite. But from my point of view, I have quite a
> lot of tags and loading albums and searches is lighting-fast. Proposed
> features will add only 1 tag to each image (to indicate album) and to
> some images 1 or more tags (to indicate groups), so it should be ok.

We need to have a sane database schema, the rest is the task of the db we are
using. And not our problem.

>
> I'm willing to help to develop this. I can program in C++, but I have no
> previous experience with Qt (I would like to learn it). Hope this
> wouldn't be too difficult to develop, because it uses already developed
> digikam's tags infrastructure.

You are very welcome if you want to help with digikam development.
Qt4 is really a great piece of software, and it's fun to use. The
documentation is very good.
So first steps usually include:
- read some introductory docs on qt
- set up  a Qt4/KDE4 development environment - now that KDE4 beta1 is out,
things are settling down and this is not so much of a problem any more
- try to orientate yourself in the digikam source
- try to fix a bug, scratch an itch, there is enough of this in digikam for
KDE4
- visit the IRC channel, Gilles is usually there in the evening and I
sometimes too.
- you can always find help on this list


>
> So tell what do you think about it. Whether it can be done, etc...
>
> Tibor Blenessy
>
> ps. i'm not native english, so if you didn't understand something email
> me, I'll try to correct myself
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Tibor Blenessy]

>> Under system tags tree, there will be tag Albums. Each image will have
>> tag from Albums subtree which means, that particular image belongs to
>> this album. Image participation to albums will no more be connected
>> through image position in filesystem. Albums tags will be created
>> automatically by standard ways, that are now used for album creation.
>> Images will be placed still in folders, but folders will have no meaning
>> to digikam.
>> To help user organize images in filesystem, there will be some organize
>> files dialog (maybe you know it from Amarok). This dialog will enable to
>> rearrange filesystem according to Albums tag subtree.
>> Using this architecture image can belong to multiple albums (this can be
>> configurable). Organize files dialog can solve this by copying images,
>> symlinking or explicitly asking user where to place image file.
>> Creating directory structure should be configurable by album name, album
>> date, etc. To get inspiration see Amarok's organize files.
>
> It's a historic feature of digikam that Albums represent file system
> locations. I have found that there is no sufficient benefit of removing and
> replacing this system, it is simple and easy. "Organize files" features dont
> work with this of course.
> To have images in multiple albums: use Tags ;-)

I will try to list some advantages, I see, from using albums tag vs.
filesystem based albums.

- filesystem folder structure can be different from albums structure. I
personally use folder name in the form
[album date in ISO format][album name]
Nowadays I'm therefore forced to include album date in album title,
which is illogical. But having folder named like this is reasonable,
because if I order items by name in file manager, folders get sorted by
album date (I can't sort folders using filesystem folder date, because
that can be different from album date). I also often have photos from
the same event, but taken by different people. I like to have such
foreign photos in entirely different folder from mine photos. But I
would like to see their photos in the album of that event. This is
impossible with filesystem based albums, with tag albums it is something
very easy.

- using tags to have image in multiple albums is only partial solution,
  because it brings inconsistency and it is not user friendly.

- another advantage is nesting albums - albums can be nested, but
sometimes I don't want nesting in filesystem. I prefer filesystem photo
structure to be relatively flat (it's easier to copy and find physical
files), but I like rich albums structure.

- using tags for albums, brings bigger reuse of code and simpler code.
db schema is simpler (you can drop albums table, things like album date
can be property of tag). Managing albums and tags is more consistent
(everything is tag). Album icon is the same thing as tag icon. Many
parts of gui can be generalized - albums pane will be same thing as tags
pane, only with different root tag).

- using tags for albums will bring collection nesting with no
programming and changes in db

- I find "organize files" feature quite useful, sometimes I get photos
from other people and I want to sort it into mine collection. This can
include massive photos moves, sometimes during sorting I change my mind,
and sort it other way. This can include massive IO operations. Using
albums as tag, this will only mean changes in db. All the IO will be
done at the end (with nice progress bar) when I press organize files button.

I accept that historic feature has also some value (to provide some
continuation to users, who get used to it). I think that this albums
tags can be implemented like "Virtual albums" or something like that,
and provide albums both ways. Maybe it can be implemented like plugin -
only as a new pane on the left side of ui. But I would like to have this
album tags invisible in tags view (maybe provide some option to hide
certain trees in tags). What do you think about implementing it this
way?  But maybe it will be just too complicated to maintain both systems
in long term.

>> Using tags for image grouping
>>
>> Under image grouping I understand something like micro-albums. In one
>> group belongs images taken by bracketing or sequence shots, shots of
>> same scene, but different composition, modified images (resized, color
>> adjustments,...)
>
> I agree that tags are the right choice for this.
>
>> Such group should be displayed by only several representative images. So
>> if you have three bracketing photos, you create group and set as
>> representative (visible) image one with best exposition. Also in each
>> group, there can be several original (source) images, and they derivates
>> (for example group representing panorama).
>>
>> To implement this, I suggest to create new tag tree Groups in system tag
>> tree. This tag tree can have following structure:
>>
>> root: Groups
>> 1. level: group type (bracketing, modifications, sequence, general,...)
>> 2. level: concrete groups
>> 3. level: visible, original
>
> Be aware that this quickly becomes complex!
>
> For database storage, it would be better to break it down to one-to-one
> relations for derived images, tags for grouping, a visibility flag per image
> for visibility.
> For creating a panorama D from A,B,C:
> A -> D
> B -> D
> C -> D

Spliting it to one-to-one makes impossible for image to be visible in
one group but not in another. I'm thinking if this is something needed,
maybe not. Another disadvantage of spliting this is some loss of
information - derivate images are no more kind of group.


> Yes certainly. All this UI is a lot of work though ;-)

that's ultimately true

>> In digikam bugs db there were several wishes to create some language to
>> apply color changes, and similar on the fly, without modifying original
>> image. I think, that this is task for some full featured image editor
>> (like gimp) and special image format (mostly this is available in native
>> editor formats like XCF in gimp through undo/redo functions). digikam
>> should only be able to read such file (what is already done, imho). Such
>> file than can be grouped with source file using proposed group feature.
>
> There is definitely need for such a feature, at least to provide
> never-edit-the-original which is required for a proper image manager IMO.

Never edit the original could be implemented by grouping the original
file with modifications and intelligent editor, which automatically
create groups tags.

I think, that db is wrong place to place modifications of file. Maybe to
include this modification to custom jpeg  header (as digikam makernote)
or use (develop?) custom image format (something based on xml + jpeg
blob, maybe svg is able to do this).

>
>> There can be possible problem in performance, because there will be more
>>   queries to the db. I'm unable to estimate this, maybe someone with
>> more understanding of sqlite. But from my point of view, I have quite a
>> lot of tags and loading albums and searches is lighting-fast. Proposed
>> features will add only 1 tag to each image (to indicate album) and to
>> some images 1 or more tags (to indicate groups), so it should be ok.
>
> We need to have a sane database schema, the rest is the task of the db we are
> using. And not our problem.

I've seen in db structure that for representing tag tree two column
table with tag id and parent tag id is used. Have you considered using
another three representation in db? There are ways to represented three
in the way, that getting whole three path to the node is only one db
select. Of course this means more complicated inserts and updates. But
maybe it can significantly reduce number of queries. I have only article
in czech about it, I can try to google something in english if you are
interested.

>
> You are very welcome if you want to help with digikam development.
> Qt4 is really a great piece of software, and it's fun to use. The
> documentation is very good.
> So first steps usually include:
> - read some introductory docs on qt
> - set up  a Qt4/KDE4 development environment - now that KDE4 beta1 is out,
> things are settling down and this is not so much of a problem any more

Can you provide some links how to setup such environment? Info on
digikam page is kde3 only :-( . Are you using kdevelop or some other ide?


Tibor Blenessy

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/8/26, Tibor Blenessy <[hidden email]>:

>> Under system tags tree, there will be tag Albums. Each image will have

>> tag from Albums subtree which means, that particular image belongs to
>> this album. Image participation to albums will no more be connected
>> through image position in filesystem. Albums tags will be created
>> automatically by standard ways, that are now used for album creation.
>> Images will be placed still in folders, but folders will have no meaning
>> to digikam.
>> To help user organize images in filesystem, there will be some organize
>> files dialog (maybe you know it from Amarok). This dialog will enable to
>> rearrange filesystem according to Albums tag subtree.
>> Using this architecture image can belong to multiple albums (this can be
>> configurable). Organize files dialog can solve this by copying images,
>> symlinking or explicitly asking user where to place image file.
>> Creating directory structure should be configurable by album name, album
>> date, etc. To get inspiration see Amarok's organize files.
>
> It's a historic feature of digikam that Albums represent file system
> locations. I have found that there is no sufficient benefit of removing and
> replacing this system, it is simple and easy. "Organize files" features dont
> work with this of course.
> To have images in multiple albums: use Tags ;-)

I will try to list some advantages, I see, from using albums tag vs.
filesystem based albums.

- filesystem folder structure can be different from albums structure. I
personally use folder name in the form
[album date in ISO format][album name]
Nowadays I'm therefore forced to include album date in album title,
which is illogical. But having folder named like this is reasonable,
because if I order items by name in file manager, folders get sorted by
album date (I can't sort folders using filesystem folder date, because
that can be different from album date). I also often have photos from
the same event, but taken by different people. I like to have such
foreign photos in entirely different folder from mine photos. But I
would like to see their photos in the album of that event. This is
impossible with filesystem based albums, with tag albums it is something
very easy.

- using tags to have image in multiple albums is only partial solution,
  because it brings inconsistency and it is not user friendly.

- another advantage is nesting albums - albums can be nested, but
sometimes I don't want nesting in filesystem. I prefer filesystem photo
structure to be relatively flat (it's easier to copy and find physical
files), but I like rich albums structure.

- using tags for albums, brings bigger reuse of code and simpler code.
db schema is simpler (you can drop albums table, things like album date
can be property of tag). Managing albums and tags is more consistent
(everything is tag). Album icon is the same thing as tag icon. Many
parts of gui can be generalized - albums pane will be same thing as tags
pane, only with different root tag).

- using tags for albums will bring collection nesting with no
programming and changes in db

- I find "organize files" feature quite useful, sometimes I get photos
from other people and I want to sort it into mine collection. This can
include massive photos moves, sometimes during sorting I change my mind,
and sort it other way. This can include massive IO operations. Using
albums as tag, this will only mean changes in db. All the IO will be
done at the end (with nice progress bar) when I press organize files button.

I accept that historic feature has also some value (to provide some
continuation to users, who get used to it). I think that this albums
tags can be implemented like "Virtual albums" or something like that,
and provide albums both ways. Maybe it can be implemented like plugin -
only as a new pane on the left side of ui. But I would like to have this
album tags invisible in tags view (maybe provide some option to hide
certain trees in tags). What do you think about implementing it this
way?  But maybe it will be just too complicated to maintain both systems
in long term.

>> Using tags for image grouping
>>
>> Under image grouping I understand something like micro-albums. In one
>> group belongs images taken by bracketing or sequence shots, shots of
>> same scene, but different composition, modified images (resized, color
>> adjustments,...)
>
> I agree that tags are the right choice for this.
>
>> Such group should be displayed by only several representative images. So
>> if you have three bracketing photos, you create group and set as
>> representative (visible) image one with best exposition. Also in each
>> group, there can be several original (source) images, and they derivates
>> (for example group representing panorama).
>>
>> To implement this, I suggest to create new tag tree Groups in system tag
>> tree. This tag tree can have following structure:
>>
>> root: Groups
>> 1. level: group type (bracketing, modifications, sequence, general,...)
>> 2. level: concrete groups
>> 3. level: visible, original
>
> Be aware that this quickly becomes complex!
>
> For database storage, it would be better to break it down to one-to-one
> relations for derived images, tags for grouping, a visibility flag per image
> for visibility.
> For creating a panorama D from A,B,C:
> A -> D
> B -> D
> C -> D

Spliting it to one-to-one makes impossible for image to be visible in
one group but not in another. I'm thinking if this is something needed,
maybe not. Another disadvantage of spliting this is some loss of
information - derivate images are no more kind of group.


> Yes certainly. All this UI is a lot of work though ;-)

that's ultimately true

>> In digikam bugs db there were several wishes to create some language to
>> apply color changes, and similar on the fly, without modifying original
>> image. I think, that this is task for some full featured image editor
>> (like gimp) and special image format (mostly this is available in native
>> editor formats like XCF in gimp through undo/redo functions). digikam
>> should only be able to read such file (what is already done, imho). Such
>> file than can be grouped with source file using proposed group feature.
>
> There is definitely need for such a feature, at least to provide
> never-edit-the-original which is required for a proper image manager IMO.

Never edit the original could be implemented by grouping the original
file with modifications and intelligent editor, which automatically
create groups tags.

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...
 

>
>> There can be possible problem in performance, because there will be more
>>   queries to the db. I'm unable to estimate this, maybe someone with
>> more understanding of sqlite. But from my point of view, I have quite a
>> lot of tags and loading albums and searches is lighting-fast. Proposed
>> features will add only 1 tag to each image (to indicate album) and to
>> some images 1 or more tags (to indicate groups), so it should be ok.
>
> We need to have a sane database schema, the rest is the task of the db we are
> using. And not our problem.

I've seen in db structure that for representing tag tree two column
table with tag id and parent tag id is used. Have you considered using
another three representation in db? There are ways to represented three
in the way, that getting whole three path to the node is only one db
select. Of course this means more complicated inserts and updates. But
maybe it can significantly reduce number of queries. I have only article
in czech about it, I can try to google something in english if you are
interested.

>
> You are very welcome if you want to help with digikam development.
> Qt4 is really a great piece of software, and it's fun to use. The
> documentation is very good.
> So first steps usually include:
> - read some introductory docs on qt
> - set up  a Qt4/KDE4 development environment - now that KDE4 beta1 is out,
> things are settling down and this is not so much of a problem any more

Can you provide some links how to setup such environment? Info on
digikam page is kde3 only :-( . Are you using kdevelop or some other ide?

I'm use Kdevelop every time. There is a project file in svn.

Gilles Caulier

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Hi,

On Sunday 26 August 2007, Tibor Blenessy wrote:
> Can you provide some links how to setup such environment? Info on
> digikam page is kde3 only :-( . Are you using kdevelop or some other ide?
If you want to use KDevelop, there is also a techbase article I wrote at
http://techbase.kde.org/Getting_Started/Set_up_KDE_4_for_development#KDevelop.
Even if digikam provides its own .kdevelop file, you still should read it for
additional information.

Regards,
Thomas


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel