IPTC, EXIF, Kphotoalbum

[Thomas Hummel-2]

I'm new to this list. I search hard for answers but I'm not sure I get
everything right and feel I might use your help :

My understanding is that :

  . EXIF tags are for technical picture info (focal, exposure, ...)

  . IPTC tags are more adequate to store comments or personnal info

  . digikam will be, through the soon-to-be-released Metadata Kipi
    plugin, able to write tags into IPTC tags fields in the picture file
    itself. Or maybe does it that already and the Metadata plugin is for a
    convenient way to edit them ? As well, would all digikam tags be
    writable into the picture file or just a subset ?

  . although able to write metadata into the picture file, digikam
    does have, I guess, for performance reason, its own "database"

  . does digikam automatically write those in-picture-file tags or
    does it store tags into its "database" only and flush them only when
    explicitly requested ?

  . concerning tagging : what's the difference with Kphotoalbum ? I
    mean is there some tag-oriented actions which are possible in one an
    not in another (or is it just a matter of how easily it is to perform
    those actions ?)

Though Kphotoalbum seems to better suit my needs, I worry about it not
writing tags into pictures (in the case of the need to step to another
software - I wouldn't lose all the tagging work done). digikam,
through IPTC tagging seem to produce more portable work.

Also, though digikam seem to leave my underlying file-system folder
layout intact, when importing a directory which holds only
sub-directories (and no pictures), it creates empty "Albums" named
after those sub-directories : is there a way to avoid that ?


--
Thomas Hummel    | Institut Pasteur
<[hidden email]> | Pôle informatique - systèmes et réseau
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-2]

Le Mardi 31 Octobre 2006 13:04, Thomas Hummel a écrit :
> I'm new to this list. I search hard for answers but I'm not sure I get
> everything right and feel I might use your help :
>
> My understanding is that :
>
>   . EXIF tags are for technical picture info (focal, exposure, ...)

yes

>
>   . IPTC tags are more adequate to store comments or personnal info

yes

>
>   . digikam will be, through the soon-to-be-released Metadata Kipi
>     plugin, able to write tags into IPTC tags fields in the picture file
>     itself. Or maybe does it that already and the Metadata plugin is for a
>     convenient way to edit them ?

yes, i working on. 90% completed. Look here :

http://www.digikam.org/?q=node/163

>     As well, would all digikam tags be
>     writable into the picture file or just a subset ?

yes. current implementation do it (future 0.9.0 release planed to Christmast).

http://www.digikam.org/?q=node/150&size=_original

>
>   . although able to write metadata into the picture file, digikam
>     does have, I guess, for performance reason, its own "database"

yes, of course. to perform search.

>
>   . does digikam automatically write those in-picture-file tags or
>     does it store tags into its "database" only and flush them only when
>     explicitly requested ?

both at the same time. A batch tool will be written to synchronise pictures
metadata with database, especially for picture already imported with digikam
< 0.9.0.

With digikam 0.9.0, when you import a new picture in collection, IPTC tags are
parsed to create in database the right Rating/Tags/Comments/Date
informations .

>
>   . concerning tagging : what's the difference with Kphotoalbum ? I
>     mean is there some tag-oriented actions
>     which are possible in one an
>     not in another (or is it just a matter of how easily it is to perform
>     those actions ?)

What do you mean by 'tag-oriented actions' exactly ?

Are you read the digiKAm handbook before to ask questions about tags ?

http://www.digikam.org/?q=docs

>
> Though Kphotoalbum seems to better suit my needs,

Why ?

> I worry about it not
> writing tags into pictures (in the case of the need to step to another
> software - I wouldn't lose all the tagging work done). digikam,
> through IPTC tagging seem to produce more portable work.

Already done (:=)))

>
> Also, though digikam seem to leave my underlying file-system folder
> layout intact, when importing a directory which holds only
> sub-directories (and no pictures), it creates empty "Albums" named
> after those sub-directories : is there a way to avoid that ?

Do you mean the root director on album collection ?

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

[Thomas Hummel-2]

Thanks for your answers.

On Tue, Oct 31, 2006 at 02:18:49PM +0100, Caulier Gilles wrote:


> What do you mean by 'tag-oriented actions' exactly ?
> Are you read the digiKAm handbook before to ask questions about tags ?
>
> http://www.digikam.org/?q=docs
> > Though Kphotoalbum seems to better suit my needs,

Sorry if I wasn't clear enough. I read the doc and gave a quick trial
at both digikam and Kphotoalbum.

Kphotoalbum felt simpler and seemed not limited by the album "concept"
boundaries (although those boundaries doesn't seem to be a problem in
digikam when looked closer).

Also I liked the xml database idea and the ro media indexing feature.

Note : Maybe digikam can not index pictures on read-only media
(although I wouldn't see why, since it could index in its database
only) ?

But it's true that I had the feeling that Kphotoalbum features were
included in digikam and that digikam provided in addition more, such
as

  . the album concept

  . the IPTC writing feature, which, to me, guaranties portability
    (does that make sense ?)

So I was wondering if I missed some essential differences between the
two softwares (left alone the editing features that I don't care about
for now).

Also, do you know if the Medata Kipi plugin would work in Kphotoalbum
(who shares that plugin mechanism) ?


> > Also, though digikam seem to leave my underlying file-system folder
> > layout intact, when importing a directory which holds only
> > sub-directories (and no pictures), it creates empty "Albums" named
> > after those sub-directories : is there a way to avoid that ?
>
> Do you mean the root director on album collection ?

No, I had something like :

foo/bar/aaa/pictures/*.jpg
foo/bar/bbb/movies/*.mpg
...etc...

and the import of foo resulted in
empty aaa and bbb albums in the album view.

--
Thomas Hummel

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

[Hubert Figuiere-3]

> Though Kphotoalbum seems to better suit my needs, I worry about it not
> writing tags into pictures (in the case of the need to step to another
> software - I wouldn't lose all the tagging work done). digikam,
> through IPTC tagging seem to produce more portable work.

The solution is to use sidecar XMP files. XMP is a standard for metadata
that is established by Adobe and encompass EXIF, IPTC and DublinCore in
a RDF (XML) container. It specifies writing metadata to various types of
files including JPEG, PNG and TIFF, and it has a pure XML form that can
be used for sidecar files.
Sidecar files are files that are stored next to the one they relate to.
Like img_1234.cr2 has img_1234.xmp as a sidecar file.
Sidecar files is the method chosen by various proprietary digital photo
management software including Adobe Lightroom.



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

[Gilles Caulier-2]

Le Mardi 31 Octobre 2006 15:08, Thomas Hummel a écrit :

> Thanks for your answers.
>
> On Tue, Oct 31, 2006 at 02:18:49PM +0100, Caulier Gilles wrote:
> > What do you mean by 'tag-oriented actions' exactly ?
> > Are you read the digiKAm handbook before to ask questions about tags ?
> >
> > http://www.digikam.org/?q=docs
> >
> > > Though Kphotoalbum seems to better suit my needs,
>
> Sorry if I wasn't clear enough. I read the doc and gave a quick trial
> at both digikam and Kphotoalbum.
>
> Kphotoalbum felt simpler and seemed not limited by the album "concept"
> boundaries (although those boundaries doesn't seem to be a problem in
> digikam when looked closer).
>
> Also I liked the xml database idea and the ro media indexing feature.
>
> Note : Maybe digikam can not index pictures on read-only media
> (although I wouldn't see why, since it could index in its database
> only) ?
>
> But it's true that I had the feeling that Kphotoalbum features were
> included in digikam and that digikam provided in addition more, such
> as
>
>   . the album concept
>
>   . the IPTC writing feature, which, to me, guaranties portability
>     (does that make sense ?)
>
> So I was wondering if I missed some essential differences between the
> two softwares (left alone the editing features that I don't care about
> for now).
>
> Also, do you know if the Medata Kipi plugin would work in Kphotoalbum
> (who shares that plugin mechanism) ?

yes. it's a kipi-plugins.

>
> > > Also, though digikam seem to leave my underlying file-system folder
> > > layout intact, when importing a directory which holds only
> > > sub-directories (and no pictures), it creates empty "Albums" named
> > > after those sub-directories : is there a way to avoid that ?
> >
> > Do you mean the root director on album collection ?
>
> No, I had something like :
>
> foo/bar/aaa/pictures/*.jpg
> foo/bar/bbb/movies/*.mpg
> ...etc...
>
> and the import of foo resulted in
> empty aaa and bbb albums in the album view.

Ah. I cannot reproduce it here. Witch version of digiKam you use ?

Gilles

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

[Gilles Caulier-2]

Le Mardi 31 Octobre 2006 15:23, Hubert Figuiere a écrit :

> > Though Kphotoalbum seems to better suit my needs, I worry about it not
> > writing tags into pictures (in the case of the need to step to another
> > software - I wouldn't lose all the tagging work done). digikam,
> > through IPTC tagging seem to produce more portable work.
>
> The solution is to use sidecar XMP files. XMP is a standard for metadata
> that is established by Adobe and encompass EXIF, IPTC and DublinCore in
> a RDF (XML) container. It specifies writing metadata to various types of
> files including JPEG, PNG and TIFF, and it has a pure XML form that can
> be used for sidecar files.
> Sidecar files are files that are stored next to the one they relate to.
> Like img_1234.cr2 has img_1234.xmp as a sidecar file.
> Sidecar files is the method chosen by various proprietary digital photo
> management software including Adobe Lightroom.
>

XMP metadata will be supported by Exiv2 in the future, and of course, by
digiKam.

No need to have a separate XML file to store these metadata : XMP is supported
by JPEG, PNG, and TIFF/EP, like an embeded metadata directly in file, exactly
like IPTC and EXIF are.

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

[Hubert Figuiere-3]

> XMP metadata will be supported by Exiv2 in the future, and of course, by
> digiKam.
>
> No need to have a separate XML file to store these metadata : XMP is supported
> by JPEG, PNG, and TIFF/EP, like an embeded metadata directly in file, exactly
> like IPTC and EXIF are.

Again, I must disagree. The pictures should be *read-only*. A piece of
software that rewrite my pictures behind my back get uninstalled
immediately.

Do you use a marker pen to write on your negative film strips?

This is exactly what it is about.

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

[Birkir A. Barkarson]

>> XMP metadata will be supported by Exiv2 in the future, and of course, by
>> digiKam.
>>
>> No need to have a separate XML file to store these metadata : XMP is supported
>> by JPEG, PNG, and TIFF/EP, like an embeded metadata directly in file, exactly
>> like IPTC and EXIF are.
>
> Again, I must disagree. The pictures should be *read-only*. A piece of
> software that rewrite my pictures behind my back get uninstalled
> immediately.

In some cases embedded information is preferred.  It seems both options
would be in order.

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

[Gilles Caulier-2]

Le Mardi 31 Octobre 2006 15:32, Hubert Figuiere a écrit :

> > XMP metadata will be supported by Exiv2 in the future, and of course, by
> > digiKam.
> >
> > No need to have a separate XML file to store these metadata : XMP is
> > supported by JPEG, PNG, and TIFF/EP, like an embeded metadata directly in
> > file, exactly like IPTC and EXIF are.
>
> Again, I must disagree. The pictures should be *read-only*. A piece of
> software that rewrite my pictures behind my back get uninstalled
> immediately.
>
> Do you use a marker pen to write on your negative film strips?
>
> This is exactly what it is about.
>

(:=)))... well, digikam witch drive IPTC is not a sofware for you (:=)))...

You cannot compare negatif film and picture file. It's not the same :

metadata are data added outside the image data. When digiKam write/update IPTC
for example, the image data (negatif film informations for you) are
untouched !

The metadata are stored in other place in file, especially in a JPEG section,
or in a PNG chunk, or in a TIFF tag. A lot of softwares, like photoshop for
example, store metadata like this !

Also, if you don't want write IPTC metadata in picture files, well just
disable the right option in setup.

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

[Gilles Caulier-2]

Le Mardi 31 Octobre 2006 15:32, Hubert Figuiere a écrit :

> > XMP metadata will be supported by Exiv2 in the future, and of course, by
> > digiKam.
> >
> > No need to have a separate XML file to store these metadata : XMP is
> > supported by JPEG, PNG, and TIFF/EP, like an embeded metadata directly in
> > file, exactly like IPTC and EXIF are.
>
> Again, I must disagree. The pictures should be *read-only*. A piece of
> software that rewrite my pictures behind my back get uninstalled
> immediately.
>
> Do you use a marker pen to write on your negative film strips?
>
> This is exactly what it is about.
>

Hubbert,

Do you know Nikon Capture NX software to handle NEF RAW files ?

It work exactly like this about versionning of pictures. All actions in
pictures editor are stored in a dedicaced TIFF/EP tag (Yes, NEF RAW files are
based on TIFF/EP format). The RAW image data are untouched, but a new tiff
tag is add to the pictures file to store a proprietary bytes array.


The data width are very small (around 5Kb) and store a list of actions
processed by the GUI to edit picture, like crop, rotation, and other stuff.

If i remember, you use a Canon camera... Well i give you an argument to never
toogle to Nikon in the future (:=)))...

Also, there is a file in B.K.O where we talking about a similar way to
implement versionning of pictures in digiKam, using a dedicaced IPTC tag to
store editor actions list. Look here :

http://bugs.kde.org/show_bug.cgi?id=125387

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

[Thomas Hummel-2]

Hello,

On Tue, Oct 31, 2006 at 03:27:44PM +0100, Caulier Gilles wrote:

> Ah. I cannot reproduce it here. Witch version of digiKam you use ?

I'm using Digikam 0.8.2 on KDE 3.5.5.

Actually, my files layout on disk looks something like :

aquatique/
aquatique/13_rangiroa-2006-10-20/
aquatique/13_rangiroa-2006-10-20/Diving - L'Eolienne/
aquatique/13_rangiroa-2006-10-20/Diving - L'Eolienne/Movie
aquatique/13_rangiroa-2006-10-20/Diving - L'Eolienne/Picture

[aquatique/13_rangiroa-2006-10-20/<Some others directories>]

aquatique/14_rangiroa-2006-10-21/Diving - L'Eolienne/
aquatique/14_rangiroa-2006-10-21/Diving - L'Eolienne/Movie
aquatique/14_rangiroa-2006-10-21/Diving - L'Eolienne/Picture
aquatique/14_rangiroa-2006-10-21/Diving - Passe de Tiputa/
aquatique/14_rangiroa-2006-10-21/Diving - Passe de Tiputa/Movie
aquatique/14_rangiroa-2006-10-21/Diving - Passe de Tiputa/Picture


[aquatique/13_rangiroa-2006-10-21/<Some others directories>]

So if I import, in the same collection, let's say,

  aquatique/13_rangiroa-2006-10-20/Diving - L'Eolienne/
and
  aquatique/14_rangiroa-2006-10-21/Diving - L'Eolienne/

I will end up with

  . empty Albums (Diving - L'Eolienne)
  . Albums with the same name (Movie, Picture, Diving - L'Eolienne)


Even if I'd reorganized my layout to look something like :

aquatique/Movie/...
aquatique/Picture/...

I could have duplicates Album names.

The only soluton would be I guess to make each nn-rangiroa-yyyy-mm-dd
directory a Collection.
 
Doesn't the hierachical tags concept imply that all pictures should
more or less be in a flat directory ?

In other words, if pictures are organized on a folder with sub-folders
directories on disk, hadn't be that hierarchy better to be represented
with tags ?

How to manage to keep that on-disk-organization AND the inside Digikam
one ?

--
Thomas Hummel

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

[Hubert Figuiere-3]

Caulier Gilles wrote:

> Do you know Nikon Capture NX software to handle NEF RAW files ?

I have contradictory information about that. But it looks like it create
a side car file as well. Even if they don't, Nikon has the knowledge of
their file, unlike anybody else.
>
> It work exactly like this about versionning of pictures. All actions in
> pictures editor are stored in a dedicaced TIFF/EP tag (Yes, NEF RAW files are
> based on TIFF/EP format). The RAW image data are untouched, but a new tiff
> tag is add to the pictures file to store a proprietary bytes array.

It does not matter. It is not because they do it that you should do it.
See my comment above about their intimate knownledge of the file format.
And the fact that they only handle one type of file: theirs.

> The data width are very small (around 5Kb) and store a list of actions
> processed by the GUI to edit picture, like crop, rotation, and other stuff.

Adobe software (Lightroom, Camera Raw) put that in the sidecar file.
Apple Aperture as well.


Hub

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

[Thomas Hummel-2]

On Wed, Nov 01, 2006 at 01:19:09PM +0100, Thomas Hummel wrote:
> On Tue, Oct 31, 2006 at 03:27:44PM +0100, Caulier Gilles wrote:
>
> > Ah. I cannot reproduce it here. Witch version of digiKam you use ?
>
> I'm using Digikam 0.8.2 on KDE 3.5.5.
>
> Actually, my files layout on disk looks something like :

[...]

> So if I import, in the same collection, let's say,
>
>   aquatique/13_rangiroa-2006-10-20/Diving - L'Eolienne/
> and
>   aquatique/14_rangiroa-2006-10-21/Diving - L'Eolienne/
>
> I will end up with
>
>   . empty Albums (Diving - L'Eolienne)
>   . Albums with the same name (Movie, Picture, Diving - L'Eolienne)

Actually, I'm talking of course about the Collection View. In Albums
sorted by folders, the nested album feature works.

Maybe it's a normal behavior.

--
Thomas Hummel

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

[Thomas Hummel-2]

On Wed, Nov 01, 2006 at 03:23:21PM +0100, Thomas Hummel wrote:

> On Wed, Nov 01, 2006 at 01:19:09PM +0100, Thomas Hummel wrote:
> > On Tue, Oct 31, 2006 at 03:27:44PM +0100, Caulier Gilles wrote:
> >
> > > Ah. I cannot reproduce it here. Witch version of digiKam you use ?
> >
> > I'm using Digikam 0.8.2 on KDE 3.5.5.
> >
> > Actually, my files layout on disk looks something like :
>
> [...]
>
> > So if I import, in the same collection, let's say,
> >
> >   aquatique/13_rangiroa-2006-10-20/Diving - L'Eolienne/
> > and
> >   aquatique/14_rangiroa-2006-10-21/Diving - L'Eolienne/
> >
> > I will end up with
> >
> >   . empty Albums (Diving - L'Eolienne)
> >   . Albums with the same name (Movie, Picture, Diving - L'Eolienne)
>
> Actually, I'm talking of course about the Collection View. In Albums
> sorted by folders, the nested album feature works.
>
> Maybe it's a normal behavior.

I'm pretty convinced now that digikam is the best open-source picture
management around. Thanks for that wonderful piece of software.

Still I'm coming back to the issue mentionned above :

Since each directory under the root picture directory is considered an
album, how can we "hide", in the Album-sorted-by-Collection view,
directories wich holds no picture but only sub-directories (on the
file system), in order not to end up with "empty" albums (should I say
"empty of picture", as they're not really empty since they contain
sub-albums) in this view ?

This makes me think about the same kind of "folder and mailbox"
concept implementations for IMAP : some consider a folder can only
contain a sub-folder or a mailbox (but only mailboxes may hold
messages), others don't mind considering a folder can, *in addition*,
be a mailbox (i.e. contain messages)...

thanks.

--
Thomas Hummel

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