Bug 93468 - Show exif creation date under thumbnail
Summary: Show exif creation date under thumbnail
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Date (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-17 20:26 UTC by James Grant
Modified: 2020-08-29 15:00 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.1.0


Attachments
Patch to implement my wish (9.31 KB, patch)
2004-11-17 22:38 UTC, James Grant
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Grant 2004-11-17 20:26:08 UTC
Version:           0.7-CVS-2004-11-17 (using KDE KDE 3.3.1)
Installed from:    Compiled From Sources

Currently only the 'file modification date' can be displayed under the thumbnail.  A much more meaningful date for me (and most people I think) would be to show the EXIF creation date.  

I don't want to know (nor do I care) that I removed red-eye on 2004-11-17 (file modification date), I want to know that the picture was taken on 2004-11-02 (EXIF creation date).

Related (slightly) to 87780 and 90116 which ask for thumbnail sorting based on EXIF date.
Comment 1 James Grant 2004-11-17 22:38:57 UTC
Created attachment 8319 [details]
Patch to implement my wish

I had some spare time this afternoon, and figured it wouldn't be too tough to
add, so I implemented it myself.  Please review and if there's no objections, I
can commit it (or someone else can) :)
Comment 2 Renchi Raju 2004-11-18 18:04:18 UTC
i appreciate your effort in implementing the feature you requested. I have to agree with your first statement that, for users, the only important date is the EXIF date (if available). It doesn't make sense to show both dates at the same time. So this report is essentially a duplicate of bug: 87780. 

i have deferred this to 0.8, since it requires parsing the exif data to extract the date and storing it in the database (to be efficient). Since we are planning to update the database schema and import more possible metadata from the files, its best that its all done in one step at that time.
Comment 3 Mikolaj Machowski 2004-11-19 13:09:03 UTC
Good thing for printing would be something like 'album mode'
- printing with comments/information in various positions (like cdigi).

Amount of information should be configurable similar to configuration of
view of images in Digikam.

But maybe this is rather for reworked Print Wizard.

Comment 4 James Grant 2004-11-19 13:58:37 UTC
Okay, I understand that this whole system will be re-worked in 0.8, maybe even something I could help with... but for now, what if I modified the patch to combine the two dates?  'Show image date'  which would first use an EXIF date if available, otherwise fallback to the file modification date?  0.8 seems a long way out still and this is something simple that I feel would be important to have in the meanwhile.  (My 'technically challenged' mom is currently in the process of adding the EXIF date as the first line of ALL of her image comments so they show on the screen!)
Comment 5 Martin Laberge 2004-11-19 15:30:50 UTC
I totally agree that the EXIF date is the most important date of a photo.
I am experiencing the same technical challenge (my 'technically challenged' wife) of changing the names of the photos to the exif date-time of the photos (manually)

I vote for a quick implementation of displaying the exif date somewhere easily visible or accessible, (without having to click 6 times to view this date)

(and I dont care too about the last modification date, it could be buried under
six click away, I would not care)

Hope this will help a developper to decide to implement this very useful feature.
Comment 6 Renchi Raju 2004-11-29 07:29:11 UTC
replying to james, the problem with the exif date being used as the file modification date is that the exif date(from the kfilemetainfo) is retrieved with a short delay (along with the thumbnails). sorting is not done once this extra info is retrieved. it is possible to do the sorting as when the metainfo becomes available, but it can possibly cause the view to sorted again and again with quite an irritating effect for the user, if the user has items sorted by date. the only solution i can see is that the dates are available when the items are listed in the view, for which it has to be stored in the database.

a temporary solution (till 0.8 is released) is to extend the timeadjust plugin (in kipi-plugins) to set the date of the file to that of the exif date. there is already a wishlist for it (by me :) ) and i can spend some time implementing it.

from what i can see this is duplicate of 87780 and if you don't mind i will mark it as such.
Comment 7 James Grant 2004-11-29 14:26:13 UTC
I guess that would be an acceptable workaround until the exif date can be stored in the db.  But I really dont think this is a dup of BUG 87780, which asks for sorting based on EXIF date...  In this case, I dont care how the sorting is, as long as I can SEE the exif date under the thumbnail.

I can look into implementing it in the timeadjust plugin... How about something like, adding a new radiobox to the first group
[ ] Add
[ ] Subtract
[ ] Set to EXIF

and when Set to EXIF is selected, everything in the "Adjustment" group gets disbaled



Comment 8 Renchi Raju 2004-11-29 20:08:57 UTC
the reason why i consider it as a dupe for 9770, is because the same implementation (storing date in the database) will solve both the problems. As i mentioned before, the files will have only one date each (exif date if available, else file modification date). your concern was about showing the exif date and the 9770 concern is using the exif date for sorting. two different sides to the same problem. 

btw, the timeadjust plugin has already been extended to do exactly what you suggested. so a temporary solution is already in place.
Comment 9 James Grant 2004-11-29 22:29:42 UTC
Very well then, I'll update my kipi-plugins and run the timeadjust plugin.
I look forward to 0.8 :)

*** This bug has been marked as a duplicate of 87780 ***
Comment 10 caulier.gilles 2020-08-29 15:00:08 UTC
Fixed with #87780