https://bugs.kde.org/show_bug.cgi?id=319001--- Comment #2 from Cristian Klein <
[hidden email]> ---
Hi Marcel,
Let me address your comments inline.
On 2013-04-28 18:46, Marcel Wiesweg wrote:
> The problem you encounter sooner or later (with gphoto cameras sooner than with
> UMS cameras) is that the time you need to compute the hash, by accessing the
> Exif data, will be disproportional to the gained functionality.
I'm not sure I agree with this. When importing photos through UMS, the
user is presented with a preview of each photo, so very likely the EXIF
tag is already read in by digiKam. Even if the EXIF tag is for some
reason not read by digiKam (e.g., using seek), the kernel will cache
whole disk blocks (usually 4KB in size), therefore, reading the EXIF tag
would have a minimum performance impact. I have already presented
several use-cases when smart "already-downloaded" detection would help,
so I don't find the cost disproportional.
I'm not sure what would be the performance impact for gphoto cameras.
Isn't the EXIF metadata read in anyway as part of image preview?
> Regarding the
> use of make, model and name, let's have a look at the DownloadHistory database
> header file:
> /**
> * Queries the status of a download item that is uniquely described by the
> four parameters.
> * The identifier is recommended to be an MD5 hash of properties describing
> the camera,
> * if available, and the directory path (though you are free to use all
> four parameters as you want)
> */
> static Status status(const QString& identifier, const QString& name,
> qlonglong fileSize, const QDateTime& date);
For UMS, "identifier" depends on the media ID and not on the photo
metadata. Therefore, if I receive the same photo through two source,
DownloadHistory will mark the photo incorrectly as
not-previously-downloaded. For me, this is cumbersome.
> For me all points are very minor problems, yes we could make wild guesses that
> pictures on the camera were already downloaded based on some parameters, yet
> file name is not useful as there can be renames, file size is not useful as
> metadata can have been edited, date alone is by far too weak.
I agree that for legacy cameras, this might be difficult. However, like
I wrote, newer cameras include a "unique photo ID" (something like a
UUID) in the EXIF tags of each photo. Users might already have access to
such cameras (I do), why not take advantage of it?
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
