GNOME Bugzilla – Bug 339648
[2.7.5.1] some EXIF flags are filtered out
Last modified: 2007-05-09 11:38:58 UTC
Not all the EXIF flags of a JPEG image are shown. I've noticed that Comment and Categories are not displayed. note that Comment is used by Konqueror to add, exactly, comments.
*** Bug 326856 has been marked as a duplicate of this bug. ***
src/gth-exif-data-viewer.c has an array called "usefull_tags". gthumb iterates through this array, and displays the tags in the array in the order that they appear in the array. Tags not in the array are not displayed. Some have been deliberately disabled, like "EXIF_TAG_ARTIST" and "EXIF_TAG_USER_COMMENT". I'm not sure why - it should be easy to remove this filtering (and add any missing non-GPS tags). Also... I marked bug 326856 (GPS information not displayed) as a duplicate of this, but that may not have been a good idea. The GPS info is stored in a separate exif IFD, with differently-defined tag IDs! I believe that the get_exif_tag function in libgthumb/gth-exif-utils.c iterates through all IFDs, and returns the first tag that matches the requested ID number. The code might have to be changed to return the LAST matching tag, if it is a GPS tag. Or something like that. It's a little confusing. (I think the GPS IFD always comes after the non-GPS tag IFD, but I'd have to stare at http://www.exif.org/Exif2-2.PDF to be sure.) - Mike
The GPS tag overlap is noted in the libexif source code: libexif-0.6.13/libexif/exif-tag.h - Mike
(In reply to comment #2) > src/gth-exif-data-viewer.c has an array called "usefull_tags". > > gthumb iterates through this array, and displays the tags in the array in the > order that they appear in the array. > > Tags not in the array are not displayed. Some have been deliberately disabled, > like "EXIF_TAG_ARTIST" and "EXIF_TAG_USER_COMMENT". I'm not sure why - it > should be easy to remove this filtering (and add any missing non-GPS tags). I think we should show all tags, because they contain useful information. Of course some tags are more interesting than others, but we should not make that decision for the user. This is one of the reasons I use eog for viewing tags. Iterating over all the tags which are actually present in the image is not very difficult, because the code is already in gthumb (see gth-exif-utils.c). (In reply to comment #3) > The GPS tag overlap is noted in the libexif source code: > libexif-0.6.13/libexif/exif-tag.h I don't understand why this was necessary, because an enums can contain duplicate values. But once we iterate over all tags in the image, this is not a problem anymore.
Thanks for your comments, Jef. That gives me some ideas for attacking the code. (I know that it has nothing to do with rotation - but you are still the Exif tag expert :-) - Mike
I have a patch coming... However, libexif 0.6.13+ is required. Earlier versions don't reported GPS-ifd tag names corrected, it seems. - Mike
OK, I've committed a patch to CVS. All Exif tags are supposed to be shown now, including GPS tags. I'm not sure that all of the GPS tags are appearing (like the timestamp and map datum fields), but I don't have enough sample images to be sure, so please test! The lat/long coordinates do appear. This requires libexif 0.6.13 (not present on FC5 - upgrade to FC6). - Mike
Oh, I forgot to say: the tags are displayed in the order in which libexif finds them in the image file. I'm not sure that this is better or worse than any other sorting scheme. Comments? - Mike
Maybe you could add Makernotes as well? It's not very complicated. You could use my patch 70677 (from bug 350809 for eog) as a start.
I'm looking into it. - Mike
Jef, Can you provide a sample image that libexif is supported to support (for mnotes)? - Mike
Never mind, found some. - Mike
OK, I've committed a patch that adds MakerNote support. Please have a look! If anyone wants to take a stab at tidying up the order in which the tags are displayed, please feel free to suggest/patch... - Mike
Created attachment 77636 [details] [review] Remove date and aperture filter This is already much better. But there is still room for improvement: 1. The prefix system (file, exif and note) look really ugly. There are much better alternatives to separate them. One possibility is using tabs for each type of metadata. EOG uses this model already for file and exif data. We could add another tab to show iptc data too. I think we only use iptc for comments and keywords now? Another nice feature of eog, is the presentation of the tags in a nice treeview. We could do something similar to get rid of the prefix and/or to group related tags together. For the grouping we could use the IFD (e.g Primary image, Thumbnail, Exif, GPS and Interoperability). The gexif utility (distributed with libexif) does it like this. Or we could use the same grouping like EOG does. 2. The makernotes are cutting the block of exif tags in two parts. 3. Some tags (date and aperture) are still filtered out. 4. The exif_content_get_ifd function is used, while the ifd was already known. There is no need to look it up again. The last two items are fixed with the attached patch.
Jef, 1+2) Yes, I agree that the display could be much better - tabs and/or trees would both be an improvement, and grouping by IFD makes sense. However, these UI improvements are beyond my skills, currently (hence the lame text prefixing - it's better than nothing). I've taken the UI as far as I can go. If you want to try it, please go ahead and I'll re-open this bug. If you (or anyone else) plays with this, please keep in mind that this code is also used in one of the tabs of the "Properties" dialog (not just the sidebar). 3+4) Oops, some cruft survived the first pass. I've committed your patch. Thanks! - Mike
I'm working on the tree view for the image metadata...
The tree view is now in CVS.
Created attachment 77678 [details] Screenshot: duplicate MakerNote tags with same name Paolo, That is much nicer, but something is now broken in the duplicate tag removal code. See the attached screenshot. It is full of MakerNote tags like "Settings (Part 1)", which are sub-tags that libexif doesn't understand. - Mike
Created attachment 77679 [details] Sample image with Canon MakerNote tags This image is a Canon photo with the "Settings (Part 1)" duplicated tags.
Fixed.
I think EXIF fields should be sorted such a way to group together camera properties, image properties, etc. maybe using a second tree level. Can someone prepare a list of fields for each of these sub-categories ?
Paolo, we can copy some categorization from eog: http://cvs.gnome.org/viewcvs/eog/libeog/eog-info-view-exif.c?rev=1.10.4.1&view=markup - Mike
Those duplicate MakerNotes are not real duplicates. Like Michael already mentioned, they are unsupported sub tags for which libexif returns the name of the parent tag. Hiding all those unsupported tags is probably a good idea, because they are not very meaningful to the user. But by removing duplicates, there will always be one unsupported tag left behind. I don't think we can detect those tag with libexif. There is the option EXIF_DATA_OPTION_IGNORE_UNKNOWN_TAGS, but that is only used for the normal exif tags. That option would be really useful for makernotes too! I'll check that with the libexif developers. BTW, the latest libexif from cvs supports many more canon makernotes than version 0.6.13.
The categories from eog are a good start. Also the exif specification itself groups the tags: IFD 0 & 1: Tags relating to image data structure Tags relating to recording offset Tags relating to image data characteristics Other tags Exif IFD: Tags Relating to Version Tag Relating to Image Data Characteristics Tags Relating to Image Configuration Tags Relating to User Information Tag Relating to Related File Information Tags Relating to Date and Time Tags Relating to Picture-Taking Conditions Other Tags GPS IFD Interoperability IFD Not all of them are very useful in this context, but some are (e.g. GPS).
Mike, thanks for pointing me to that file. Now the code is in CVS. Tags are displayed in the same order they appear in the mapping array, I think they should be reordered in such a way that the most important tags are displayed before the others.
Paolo, 1) There is a problem with the categorization patch - it has to take into account the IFD, because the tag IDs in the GPS and non-GPS overlap a bit. As a result, GPSLatitude and GPSLatitudeRef are appearing in the "Camera" section, and GPSLongitude and GPSLongitudeRef are appearing in the "Other" section. (This is because the GPS_LATITUDE_REF overlaps with INTEROPERABILITY_INDEX, and EXIF_TAG_GPS_LATITUDE overlaps with INTEROPERABILITY_VERSION.) There should be a separate GPS category section, too. I don't have time to look at patching it today... 2) There is a problem with the duplicate tag code, I think - it should only work within the assigned category, so that if "ExposureTime" (for example) is in the standard Exif tag AND in a MakerNote, they should both be displayed. Does the duplication code serve any purpose now, other than removing non-understood Canon tags like "Settings (Part 1)"? - Mike
Actually, patching the GPS/IFD categorization issue should be trivial... I'll try to squeeze it in at the end of the day. - Mike
Created attachment 77736 [details] Sample image with GPS tags
OK, I've committed a patch that handles the GPS tags correctly. Paolo, there is an unrelated problem in the add_to_exif_display_list function that I don't understand, so I've added a debugging printf to it that prints the category, tag name, and position to the console. For the sample image in comment 28, the first few lines of debug output are: cat 0, Name, pos -6 cat 0, Dimensions, pos -5 cat 0, Size, pos -4 cat 0, Modified, pos -3 cat 0, Type, pos -2 cat 2, ImageDescription, pos 4 cat 1, Make, pos 3 cat 1, Model, pos 4 cat 2, Orientation, pos 6 cat 1, XResolution, pos 8 cat 1, YResolution, pos 9 cat 1, ResolutionUnit, pos 10 cat 1, Software, pos 11 cat 2, DateTime, pos 7 cat 2, Artist, pos 8 but ONLY ImageDescription is actually appearing in the "cat 2" (Image Data) tree. The other "cat 2" items listed above are appearing in "cat 1" (Camera) tree. Could you take a look at that function? - Mike
Mike, the problem is fixed now, and I removed the check for duplicated tags in categories other than the makernote category because, if I understand it correctly , it's needed only in that category, isn't it ?
I submitted a patch to libexif to hide unsupported canon makernotes [1]. With this patch libexif returns NULL for unsupported tags instead of the name of the parent. If it gets accepted, there is no need to check for duplicates anymore, because gthumb will skip them automatically. [1] http://sourceforge.net/mailarchive/message.php?msg_id=37600464
It turns out that IFD0 (main image tags) and IFD1 (thumbnail tags) share duplicate tags (with different values). I've committed a patch that puts thumbnail-related data into its own category. Eventually we'll get this right! - Mike
Just as a note, the tag order and categorization needs to be tweaked a bit. The ordering isn't ideal yet (EXIF_TAG_INTEROPERABILITY_INDEX before EXIF_TAG_MODEL??), and the categorizaton needs to pay more attention to what the Exif standard says, as per Jef's comments. I'll look at that when I have a free moment. In the meantime, I could use some help with bug 362854... - Mike
Created attachment 77823 [details] [review] Quick patch to use exif ifds as categories I agree with Michael that the categories will need more tweaking. Many tags appear in the wrong category. I think it will be difficult to assign and maintain good categories (but it's not impossible). That's why I came up with the idea to use the IFD as categories. This is very simple and is actually not that bad. This also eliminates all problems with duplicate tags (they appear in different IFDs) and overlapping tags (also in different IFDs). What do you think of this approach? This patch is what I would call a quick and dirty patch. It's only a proof of concept and will need some more cleanup.
Jef, I think you are right. I didn't fully understand the IFD structure when I started, otherwise I would have taken that approach, I think. (I'm printing out the full Exif spec, finally, for some detailed study.) The current code has developed into an odd hybrid, which will be hard to maintain. I'll take a look at improving your patch - sorting is still an issue. The Thumbnail, Exif, and Interoperability categories can share one sort enum. The GPS category would have a separate sort enum. The MakerNotes and Other categories would be unsorted, I guess. Tags that aren't in our sort lists will have to be dumped into the "Other" category, regardless of their original IFD, otherwise they mess up the sorting. Sound reasonable? - Mike
Actually, after thinking a bit more... I'm not sure that your approach has any real advantages over the current basic scheme, since all the tags have to be listed somewhere for sorting purposes anyways. We could just revise the categories to be consistent with the IFDs / Exif standard. The current scheme accommodates duplicates and tag overlap through categorization already, so we don't actually gain anything there. It all depends on the details of the sorting, really. What do you think? - Mike
I think I now see how we can combine the best of the two approaches... I'll try it later. - Mike
The reason why I didn't bother implementing any sorting, is that I'm not convinced that it's really useful. The only reason I can think of, is to show the most "interesting" tags first. But that is a very subjective criteria. It can and will be different for other persons, or even for the same person (e.g. comparing pictures shot with a different camera setting). Also, if you are looking for one or more specific tags, an alphabetic ordering is certainly better than any arbitrary sorting method. With the current scheme, we'll have to list every single tag in the lookup tables, to prevent them from going into the 'Other' category. Another problem for which we don't have a solution, are duplicate tags (in different IFDs) but with different values. Which one do we choose in this case?
Jef, OK, I'll have to disagree respectfully here - I think some sorting is essential. That means that every tag has to be listed, but I think it's a price worth paying. No sort order will please everyone, but I think a well-chosen one will be better than none at all. (The current one isn't well-chosen, unfortunately.) The duplicate tag issue is dealt with by checking the IFD. For instance, some tags can legitimately appear in both IFD0 and IFD1. Currently, if they appear in IFD0 we dump them into the category determined from exif_tag_category_map. If they appear in IFD1, the category is "overridden" to be "Embedded Thumbnail". (The GPS tag ID overlap is handled similarly.) I think that is the only legitimate duplicate tag case. Are you aware or concerned about any others? (If so, some sample images would help clarify the issue.) Grouping by IFD is too coarse, I think. I've been staring at the Exif spec, and its "official" groupings (within IFDs) aren't great either, from a user's point of view (for instance: DateTime and Model, two very interesting tags, are in "Other"). So I'm inclined to think that I will refine the current "hand-made" categorizations, rather than changing the basic scheme. Please correct me if I'm misunderstanding anything! - Mike
For the time being, I've committed a minor patch that improves the categorization in exif_tag_category_map. To do: not all tags in libexif/exif-tag.h are yet present in exif_tag_category_map. - Mike
I've added the extra categories. I'm happy with the code now. - Mike
Created attachment 77957 [details] List of exif tags grouped by ifd Things look already much better now! I did read the exif specification again and found some things I didn't noticed before. That information is valuable for defining our categories. First the exif ifds have a hierarchical structure: IFD 0 (Primary image) + EXIF IFD + Makernotes IFD (not always a real IFD) + Interoperability IFD + GPS IFD IFD 1 (Thumbnail image) The two main ifds (IFD 0 & 1) can contain the tags defined by the TIFF 6.0 specification. (Actually, the tags listed in the exif specification are only a subset of the full tiff specification. I can't find whether the other tags are also allowed in exif images. libexif has a few of those extra tags from tiff, but not all of them.) This means both ifds can contain the same tags. The exif, gps and interoperability ifds are additional sub ifds, defined by the exif specification. The tags are private (e.g. not found in the main ifds), and can only appear in their own ifd (e.g. every ifd has different tags). According to the exif specification, the interoperability contains only one tag, but the DCF standard adds three more. The makernotes are in proprietary format, often without documentation. Some can be (partially) decoded by libexif. Based on those observations, I think these categories are obvious: * File (filesystem data) * Primary Image (IFD_0, IFD_EXIF and IFD_INTEROPERABILITY) * Thumbnail Image (IFD_1) * Makernotes * GPS (IFD_GPS) Only the "Primary Image" category could use some extra subdivision. There are mainly three types of tags: * General - Camera (model, make,...) - User (comments, copyright, software, artist,...) - Data/time - Versions * Picture-Taking Conditions - Camera settings (iso, shutter, aperture) - Flash - ... * Image Structure - Dimensions, resolution,... - Colorspace - ... This is more or less what we have already, with a few exceptions. First of all, I think the interoperability tags and the version do not deserve a special category, because they are not that important. And second, if we are listing all tags for sorting purpose, there is no need for the "Others" category. But we could keep it just in case. And there are still some tags missing! During reading of the exif specification, I created a modified version of 'exif-tag.h' with tags re-arranged by IFD (see attachment). This could be useful to add the missing tags. For the TIFF section, I indicated which tags are not defined in exif, but only in tiff (some of them are also in libexif). Add the and there are some tags which are present in libexif, but not in the exif or tiff specification.
Jef, My general reading of the exif standard agrees with yours. I want to keep the version and interop stuff in its own category because no one cares about those tags, and that way they can be placed at the bottom of the display list. The "General" category is interesting, so it seems a waste to clutter it up with useless version/interop tags. We need to keep the "Other" category, for overlooked, new, or proprietary tags. Thanks for mentioning the DCF standard - I was wondering where those extra tags came from! Regarding TIFF tags - I guess the TIFF tags should be included, because (in principle) exif files can be tiff files (not just jpeg), so we should be prepared to handle that, even if it doesn't work yet. (This came up during our rotation discussions too.) Eventually, we should track down some sample exif/tiff files, and see what happens with them... Do you want to work up a patch that slips in the remaining tags into the existing categories? - Mike
I can create a patch to add the remaining tags, but I'm not sure if I can get it done before next week (busy weekend coming). Some other ideas: 1. If we are going to keep the "Other" category, we could also move the version and interoperability tags there. That seems a good compromise to me. 2. I think the issue on the missing TIFF tags will depend on the reason why they are not mentioned in the exif specs. If it was on purpose (e.g. when they are not allowed in exif files), they should stay removed (including the ones already in libexif). But if they are allowed, they should be added. I posted a message on the libexif-devel mailinglist about this, but got no response so far. However, if you take a closer look at the tags, you'll notice that almost all of them are related to the internal image data representation. Which means they are probably not very interesting for the user anyway.
Jef, Moving those tags to "Other" means we lose the sorting, which is a little unattractive. Plus I'd prefer to put only real oddballs in "Other", because that will alert us to new/unusual tags that haven't been accounted for. If you identify any tags that you think should be included, let me know, and I can patch them in. - Mike
Created attachment 78125 [details] [review] Small improvement to the categories Almost all exif tags were already present (my local copy was not up-to-date). I only had to add one or two and removed a few tags not in the exif specification. The largest part of this patch consist of a re-arrangement of the tags inside the categories and moving a few to another category. I think related tags are closer to each other now. I also suggest placing the "image" category after the "conditions" category, because that last one contains the most valuable information. (This is not included in the patch.)
Patch committed and "image" category moved. Thanks! - Mike
I just checked in the following change to the libEXIF's CVS repository: EXIF_DATA_OPTION_IGNORE_UNKNOWN_TAGS is now propagated to Canon makernote and used to ignore unknown subtags of Settings1, Settings2, FocalLength & Panorama makernote tags. The patch proposed by Jef (see Comment #31) is not 100% correct. It would return NULL also for all supported makernote tags that don't have subtags (ImageType, FirmwareVersion, ImageNumber, OwnerName, SerialNumber & CustomFunctions).
Thanks Jan! It's nice to see some maintenance on libexif! Is there any chance that you can fix these frequently-reported bugs: bug 391004 (libexif exif_set_sshort bug) bug 373857 (libexif gettext bug) - Mike