gmane.comp.kde.digikam.user

Re: Tags and metadata for photo and video

Jean-François Rabasse — 2012-05-17T15:28:37

Hello Cédric,
some comments as I see two different issues in your post.

On Thu, 17 May 2012, Cédric Macquat wrote:


The bad new is that (nothing but my own personal opinion) it doesn't
seem possible to expect setting up a tags strategy and keep it as is
along years or decades, and software changes.

Metadata world is a swampy and misty landscape. Some standards exist but
they mostly define data formats and labels, and are more unfocused on
data semantics and where to put what. A software development team may
have its own interpretation and another team may disagree and do
something different.
(Digikam itself does some interpretation in metadata handling, and not
everybody agrees.)

Also, software often needs some information not featured in standards
and will thus create its own namespaces for that.
Compatibility is then broken.
(Digikam does that. The tree structured tags system - a nice feature
indeed - is out of standards that propose only flat lists of keywords.
So, Digikam invents a special tag, xm

Tags and metadata for photo and video

Cédric Macquat — 2012-05-17T11:03:50

Hello,

I want to manage my photo collection and video collection with digikam.
With digikam I tagged my photos and I want to begin with the video. My
problem is the following: If I want to use another software to manage my
photos and video in the future (perhaps one time another one will fit
better to my needs, but for the moment digikam is perfect :-D) how can I
make sure I don't have to retag everything ? When I will have much more
photos and videos it won't be possible to do the work again. 
For the moment I did the following. At first I had photos in jpg format.
I had written the tags in the jpg files. But now I have a mixt of photo
in jpg and raw format. I can't write the tags in the metadata of the raw
format. It would be possible (I saw it's experimental for the moment) to
write in the raw files, but it's not advised. So I discovered the xmp
sidecar and I created for every tagged photos a .xmp file. 
But now I will tag my videos and with digikam it's not possible to
create a xmp file for videos. I th

Re: BUG? move to album / overwrite destination problem

Jean-François Rabasse — 2012-05-17T09:35:48

Hello,

On Wed, 16 May 2012, Remco Viëtor wrote:


Thanks for the detailed explanation Remco. Sounds like it's a matter
of trustworthy and reliability of open source software wrt proprietary
formats.

But ok, this for raw files. And about JPEG files :

On Wed, 16 May 2012, Peter Albrecht wrote:


Seems that both of you agree on « keep originals as they are » .
Should lead to the conclusion that the « zero risk » procedure is to
archive (e.g. USB drive) all out-of-camera data, then copy all or
selected images on main computer and work.
(And backup processed apart from original.)

Regards,

Jean-François
_______________________________________________
Digikam-users mailing list
Digikam-users-RoXCvvDuEio< at >public.gmane.org
https://mail.kde.org/mailman/listinfo/digikam-users

Re: BUG? move to album / overwrite destinationproblem

Peter Albrecht — 2012-05-16T19:50:48

In reference to "and perhaps a bad idea for original
out-of-camera jpgs as well":
Writing metadata to JPGs works very well for me, for several
years now.

The only drawback I can think of is the mentioned "changing
the original".

But I decided for me, to _not keep_ the original
out-of-camera-jpgs. So I can live with this "issue". But
this is a decision everyone has to make him-/herself.

Regards,
Peter

HDR and 2.6.0 RC

POTTIER Michel — 2012-05-16T15:14:25

Hello all,
 I am trying to make HDR with two jpegs. In the tools menus I choose "fusionner les images prises en fourchettes". 
A box appears with the names of the binaries (align_image_stack 2011.4.0 and enfuse 4.0). Then "next", another box  with the names of the two images. 
Then "next" I arrive on  "aligner les images". Next "cette operation peut prendre un peu de temps" and "Le prétraitement a échoué (Preprocessing failed)" . 
By clicking on "details" open another empty box.
Running digikam in a terminal, i obtain the following output:
digikam
QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work.

(digikam:5848): GStreamer-CRITICAL **: gst_debug_add_log_function: assertion `func != NULL' failed
digikam(5848)/KIPI (general) KIPIExpoBlendingPlugin::ItemsPage::slotAction: Unknown action
Last line is when the preprocessing failed.


KDE Platform Version: 4.6.5 
Linux 2.6.38.8-desktop-10.mga x86_64  (Mageia 1)
Is it a bug?
Thank you for your help

Re: BUG? move to album / overwrite destinationproblem

Remco Viëtor — 2012-05-16T09:10:54

...

For me, there are two reasons to avoid writing to RAW files:
- They are the original, irreplacable data that I like to keep in its original 
state.  (I have backups, but still...)
- There is no such thing as _a_ raw format: every camera maker has his own 
formats (yes, plural :( ) And those formats are poorly specified, especially 
wrt to the 'makerdata' EXIF section, so it's very easy to corrupt something 
when writing to such a file. The situation is getting better through a lot of 
hard work from volunteers (not me, I hasten to add), but given the sheer 
number of raw formats in existence, there will probably always be formats that 
are not understood.

Also, RAW files in general only have EXIF data, part of which can be pure 
binary data, and possibly encrypted (makernote..)

Regards, 

Remco

Re: BUG? move to album / overwrite destination problem

Jean-François Rabasse — 2012-05-16T08:39:43


Hello,

I happened, at some occasions, to use hard links in a (maybe) similar way
as John does (have a folder with a bunch of images and some other folders
with selected images subsets).

I confirm Digikam doesn't recognize/handle links. When pathnames are 
different, the images are seen as different even if it's the same file,
and database entries are different too.

What I used to do for final cleanup after tagging/rating/indexing was :
  - Run the « Find duplicates » function on the root folder (nearest root
    above linked images),
    As linked files are the same, obviously the two images are found to
    be duplicates,
  - In the duplicates search results view, set the display filter to
    show only unrated/untagged images,
  - Select all, Ctrl-A, then delete.
  - After that, move, reorganise the remainding (rated/tagged) images.

(This worked well. I must say I no longer work like that. Now I tend to
copy SD-card content into a new folder, then browse the images and tag
those I want to keep, the

Re: BUG? move to album / overwrite destinationproblem

John Stumbles — 2012-05-16T08:16:49


I just checked and dolphin has the same problem so it's really a bug in 
kde. Maybe I'm missing something but overwriting - bitwise copying - one 
file to another in order to move it seems like a really stupid thing to 
do! I wonder why kde doesn't actually do a `mv` when the source and 
destination are on the same filesystem? Maybe it was a bit of q&d coding 
(saving having to check whether a mv is possible) that hasn't been 
refined? (I know: it's open source, I should fix it myself instead of 
complaining about it! But it's not like a little C file: there's a huge 
learning curve to get up to start hacking on something like kde ... 
would take me months to get going :-()



One of the main ways I enjoy my photo collection is having my better 
pictures displayed on kde's slideshow screen-saver when my PC is idle. I 
acheive this by, when I've uploaded a set of photos containing some I'd 
like to have on the screensaver, I `cp -rl` the album to a directory in 
the tree the screensaver accesses; then I go

Re: BUG? move to album / overwrite destinationproblem

Remco Viëtor — 2012-05-16T04:07:24

I think it's actually the hard linking that causes the problem:
Digikam sees that the file you want to copy to exists, asks for permission to 
overwrite, and then tries to open that file for writing, truncating the 
contents. But that file is also opened for reading through the other file 
name... 
And, if you simply move the modified files into the parent directory, you are 
just deleting one of the hard links. Then on next start-up, digikam would 
indeed see that the tagged files have disappeared, and removes the associated 
information from its database.
Also, storing metadata in the image files isn't recommended for RAW files (and 
perhaps a bad idea for original out-of-camera jpgs as well).

You seem to use the hard links to avoid making a temporary copy. You have to 
do that from outside Digikam, forcing Digikam to check the albums at startup 
(which does slow down startup). And Digikam has no choice but to consider the 
files independant, it has no notion of hard linking afaik. 
Is the use of hard lin

Re: BUG? move to album / overwrite destinationproblem

John Stumbles — 2012-05-15T20:03:32

Yes, I'm aware of that, and it generally detects movements of picture 
files quite reliably. However in the particular situation I have here 
there are identical picture files (they're actually hard-linked) so if I 
move the instance it has ratings for into the directory containing the 
one that's not rated I'm pretty sure it would simply think that the 
rated copy has been deleted.



That would use up unnecessary extra space in my snapshot-backup system 
storing new copies of picture files when their embedded metadata changed.

As I say I can workaround this (apparent) bug by deleting the un-rated 
copies of the files, getting dk to notice that these have disappeared, 
and then moving the rated copies. (Midnight Commander is quite handy for 
this as it can select all files in a directory which are different from 
those in another directory, and work on that selected set of files.)

Re: BUG? move to album / overwrite destinationproblem

Peter Albrecht — 2012-05-15T17:23:19

Hello John,

digiKam stores hash-keys for each picture in its database.
So it should be able to detect picture movement outside of
digiKam.

Another (safer) way would be to store the ratings _in_ the
jpg-file.

 "Settings" -> "Configure digiKam" -> "Metadata" ->
"Behaviour" -> [x] "Save image ratings in metadata embedded
in files"

In this case you can always start "read metadata from
image", to read them back in the digiKam database. But
digiKam should recognize those metadata in the files
automatically.

Regards,
     Peter

On 15.05.2012 01:25, John Stumbles wrote:

Re: how to lock the zoom level in the rightgeolocation view?

rawi — 2012-05-15T12:49:04

Hi Jean-François,

thank you for the infos!

The lost feature, it's a pity!

I hope the DK developers will stumble upon this issue some time.

Nonetheless, DK is great!

It seems that the majority of the users don't use the geo-gps function, or
don't bother about the zoom level.

Cheers

--
View this message in context: http://digikam.1695700.n4.nabble.com/how-to-lock-the-zoom-level-in-the-right-geolocation-view-tp4620072p4634413.html
Sent from the digikam-users mailing list archive at Nabble.com.
_______________________________________________
Digikam-users mailing list
Digikam-users< at >kde.org
https://mail.kde.org/mailman/listinfo/digikam-users

Re: Off-line Collection Browsing & DB cleanup

Jean-François Rabasse — 2012-05-15T12:36:22

On Mon, 14 May 2012, Nick Anderson wrote:


Many thanks Nick, this is the perfect example of the usefulness of a 
regular off-line data support.

1. Images collections on CD are always off-line. If it may be common for
someone to have a few dozens of CD/DVD, it's unlikely to have also a few
dozens of CD readers plugged onto the computer.

2. Images on CD aren't expected to be editable/processable
(even on CD/RW:-), so physical presence of the file isn't mandatory
and any built thumbnail would be up to date forever.

So, being able to read/index a CD, get images pathnames, read metadata,
build thumbnails, etc., then put back the CD into its box, could be
really helpful for future indexing, browsing, searching, along with
other images on the local disk.


Regards,
Jean-François_______________________________________________
Digikam-users mailing list
Digikam-users-RoXCvvDuEio< at >public.gmane.org
https://mail.kde.org/mailman/listinfo/digikam-users

BUG? move to album / overwrite destination problem

John Stumbles — 2012-05-14T23:25:34

I have an album containing pictures, and a sub-directory containing a 
sub-set of those pictures, plus some modified versions. I've rated the 
images in the sub-directory and now I want to put all pictures from the 
sub-directory into the main album. I know this will involve clashes with 
pictures that already exist in the main album but I just want to 
overwrite those.

So I select all pictures in the subdirectory, right-click to 'move to 
album' and select the main album directory. DK throws up a warning that 
a 'File Already Exists' and I press the 'Overwrite' button but DK just 
pops up a warning window about the same file again ... and again and 
again. It seems to be broken :-(

Incidentally the duplicate files in the main album and the sub-directory 
are hard links, not copies.

I guess I can overwrite the files using other tools, gui or cli, but I 
want to do it with DK so it remembers the ratings I've applied to files 
in the subdir: I suspect that if I move them outside of DK it will just 
seem the

Re: Off-line Collection Browsing & DB cleanup

Nick Anderson — 2012-05-14T13:25:03

Great, Ill take a look at it. I ended up writing a really simple bash 
script last night to do similar. Ill clean it up and share it if anyone 
else is interested.



Yeah everyones work-flow is different and in general I don't think DK 
should hamper whatever work-flow you prefer. This comes up for me 
because I basically have two trees. An import tree where I am tagging 
and renaming thats located on my laptop. I do local edits on those files 
with ASP/Bibble. When I am done I put them into the processed tree which 
is stored on my NAS.


I would agree that moving from one model to another is a huge task, but 
to me it doesn't seem that it would be very hard to add the off-line 
browsing/searching since the thumbs and metadata are already stored 
separately from the picture. A bunch of functions would need to be 
disabled for those but basic searching and browsing shouldn't require a 
ton of work. It would be nice to support the permanent off-line paths as 
you suggest but that kind of feature doesn't alr

Re: Off-line Collection Browsing & DB cleanup

Jean-François Rabasse — 2012-05-14T10:26:18

On Sun, 13 May 2012, Nick Anderson wrote:


No problem. I've attached the script I use to this e-mail, in case you 
or others would wish to play with it. It's really simple stuff,
just get it, read it, try it, hack it to suit your personal usage.


Yes, could be. I should point out that this is just a trick, a hack, 
not a regular way of full working with DK. It only provides a possible
solution to the original question « How can I browse my full collections
even if my original images aren't available at the moment ? »
Nothing more.
And clearly, images files processing/updating is off topic.

Using that kind of trick requires to clearly make a distinction between
images in processing state and images in archived state.
And it's possible to work in a « hybrid » mode, with a DK tree made of
mini images (as placeholders for off-line archived images) and regular
images files, full size, editable, processable.
New subfolders with new images can stay on a local disk several days or
weeks. When processing is c

Re: Off-line Collection Browsing & DB cleanup

Nick Anderson — 2012-05-13T22:51:44

Thanks for the response, it would  be great if you could share your scripts.

Your workaround seems like it would work ok but generating all the 
thumbnails and keeping them updated seems a pain.

Hopefully the developers see this as a useful feature and stub it in 
soon. Even read only browsing access would be better than not showing at 
all. It would be great to have some kind of offline metadata editing 
with some kind of synchronization feature but I would be content with 
just read only.

Re: how to lock the zoom level in the right geolocation view?

Jean-François Rabasse — 2012-05-13T21:16:50

On Tue, 8 May 2012, rawi wrote:


Hi Rawi,

I agree with you, the automatic full scale zoom factor isn't very 
convenient. I don't know if keeping the zoom scale accross images 
changes is possible. What I can say is that it was possible in former
versions of Digikam.
I have a DK 1.2.0 and a DK 2.2.0, and with the 1.2.0 version, once the
zoom factor is set, it remains unchanged when one selects another image.
With version 2.2.0, it doesn't.
This means that it's not a missing feature but a removed feature, and
removing functions in software is often leads by technical reasons.
But only DK developers could answer.

Regards,
Jean-François_______________________________________________
Digikam-users mailing list
Digikam-users-RoXCvvDuEio< at >public.gmane.org
https://mail.kde.org/mailman/listinfo/digikam-users

Re: Off-line Collection Browsing & DB cleanup

Jean-François Rabasse — 2012-05-13T21:02:10

On Sun, 13 May 2012, John Stumbles wrote:


Hi John,

If I follow your idea, you mean to trick Digikam with presentation of
images collection either as the full-size version, or reduce-size version ?
Well, could be a great idea if it works, but probably some point should be
tested before :
I don't know exactly how DK does decide, when scanning collections, what is
an existing image and what is a new image. If it's by full pathname check,
the idea would work. But if it uses also some image file specific signature
such as a MD5 or SHA digest, as files are different all images may be
considered as new ones, and all previous images as removed ones.
And the DB would then be reinit accordingly, loosing tags et al.

So, to be checked and if it works it could be a nice hint, especialy for
hotplug/udev gurus that could implement that simlinks swap upon plugging
and unplugging of USB devices.

I must admit I didn't investigate that point, for in most cases I use
both files trees at the same time; the reduced version

Digikam on liveubuntu: empty root folder ...

Julien T — 2012-05-13T20:37:06

Hello digikam users,

currently travelling (for a long time), I have my netbook which broke
recently. So I switched my working environment to a live lubuntu usb
key (12.04) and try to use digikam on it (which is very heavy on
persistent disk ~500MB but ...).
My problem is after restoring config files on my persistent disk, make
a symlink from my external disk as ~/Images, double checking digikam
config file (~/.kde/share/{config/digikamrc,apps/digikam*}, I still
have digikam showing me a empty root album folder ...

I don't have any error message outside of digikam saying it detects my
collection on a removable media (i try both ignore or mark as
removable collection).
I update permissions/user of db file and some of sub-images folder as
live ubuntu user is 999 (vs 1000 on most distrib).
Digikam is 2.5.0 pristine from lubuntu depository (and not ppa for now :)
No problem to access files w browser or gthumb.

Any ideas where the problem could be ?

Thanks a lot.
Cheers,

Julien

Re: Off-line Collection Browsing & DB cleanup

John Stumbles — 2012-05-13T14:03:51


...


...


Sounds a good idea: I might set that up on my laptop which doesn't have 
space for all my pictures.

I guess you could do the swapping between reduced-size collection and 
full-size collection with symlinks (on non-Windows systems) e.g. have 
your digikam root directory be a symlink to either your reduced-size 
image tree or the mount-point of your external drive. (You'd have to 
arrange things so your digikam database isn't in the dk root directory)