[KimDaBa] EXIF tags

[Jesper K. Pedersen]

Shawn Willden <shawn-kimdaba at willden.org> writes:

| On Saturday 03 January 2004 03:04 am, Jesper K. Pedersen wrote:
| > Well if you could supply me with code for reading EXIF data, then we are
| > a
long way, the rest I could easily handle.
| 
| Here's a snippet that retrieves date and time from EXIF tags and puts it 
| into a QDateTime object.  Note that this code is derived from some that is 
| known to work, but has been modified to remove it from its original 
| context and hasn't been tested.  It should work, though ;-)
| 
| -----------------------------------
| #include <time.h>
| #include <sys/time.h>
| #include <libexif/exif-data.h>
| #include <qdatetime.h>
| 
| QDateTime exifDateTime(QString filePathName) 
| {	
|     // Get date/time from EXIF tags
|     ExifData* data = exif_data_new_from_file(filePathName.latin1());
|     ExifEntry* entry = exif_content_get_entry(data->ifd[EXIF_IFD_EXIF], 
|                                               EXIF_TAG_DATE_TIME_ORIGINAL);
| 
|     QDateTime exifDateTime;
|     if (entry)
|     {
|         struct tm tmTime;
| 	strptime(exif_entry_get_value(entry), "%Y:%m:%d%t%T", &tmTime);
| 	exifDateTime.setTime_t(mktime(&tmTime));
|     }
| 
|     exif_data_free(data);
|     return exifDateTime;
| }
| ---------------------------------------
Thanks, I'll have a look as soon as time permits.

| > My greatest concern about all this EXIF stuff is to rely on 3rd party
| > libraries.
| 
| I don't think libexif should be too much of a problem that way.  There are 
| already a few bits of KDE that depend on it, plus lots of other apps that 
| require it, like gphoto2 and the GIMP.  So although you'll want to add a 
| config test to see that the libexif development files are available, 
| libexif is almost certainly available anywhere that KimDaBa might go.
right.
 
| > | Another feature I'd like to add is the ability to change thumbnail
| > | size on 
 the fly, with a pulldown box in the menubar.  Any comments
| > | on this one?
| >
| > I'm not sure about the released version, but in the one in CVS,
| > changing
 the size in the options dialog, and pressing OK, changes the
| > size right away.
| > I'm not sure how useful it would be to have the possibility to change
| > stuff
 on the toolbar anyway - personally I've always only used one icon
| > size, namly 128, which seems to be just perfect.
| 
| I find that I often want to use a 64px thumbnail for scanning large 
| collections, but I want to bump it up to 128px or even 256px to see more 
| details of a given image.  I tend to take lots of pictures of a given 
| scene in order to get a really good one, so sometimes I need to get a 
| better view.
OK, I'll give it a second though over night.

| Another approach, which might even be better, is to have a feature that 
| pops up a larger version (say, 256px), along with the other data, similar 
| to what Konqueror previewing does.
I'm not sure what you are referring to here, could you elaborate please.

|  I suppose I could click on them to get 
| a larger view, but that's slow.  Perhaps the viewer-sized images should be 
| cached along with the thumbnails?
hehe, originally I cached all images, and then someone told me that they
didn't have 1Gb of ram as I did ,-)

Smart caching is indeed something KimDaBa would need in the future for say
the slide show feature.

Cheers
Jesper.