GNOME Bugzilla – Bug 529469
Empty EXIF added
Last modified: 2008-10-30 20:12:35 UTC
Please describe the problem: GIMP adds empty EXIF information to JPEG files. You cannot choose not to due to the disabled option in the the "Save as..." dialogue. (This bug concerns the gimp-win project. I was lead here by their project website.) Steps to reproduce: 1. Open an image (png, jpeg, whatever) 2. Save it via <Ctrl><Shift><S> (File --> Save As...) 3. If the Option "Save EXIF information" is disabled ("unclickable"/greyed), GIMP will save the JPEG image with empty EXIF information, when you hit the save button. Actual results: Expected results: Does this happen every time? Yes Other information: This bug was already within GIMP 2.2.x: After opening a bmp or png image and "converting" it to JPEG, the option "Save EXIF information" was disabled. When you opened a jpeg image, the option was still clickable. As I heard from GIMP for Linux this bug does not show up on *nix systems.
What makes you think that "empty EXIF information" would be saved?
Created attachment 109771 [details] A wallpaper created with IInkscape and Gimp This image should come with empty EXIF information.
xnView shows an EXIF symbol. MediaWiki also shows present EXIF tags containing no information. I uploaded a selfmade wallpaper.
Then these tools are buggy. The exif utility clearly shows that this file does not contain EXIF data. And the code in the JPEG plug-in also quite certainly doesn't add any empty EXIF data blocks. Closing as INVALID.
Hm... graphicsmagick does show and is able to export an empty exif profile, though.
So, a just second "buggy" tool?
Perhaps these tools just show an empty profile when there is none?
Probably because they're looking for "EXIF" or "Exif" in the JPEG header - as it /is/ within the header of the image I uploaded? I just took a look with the Windows Editor: "ÿØÿà JFIF 5 5 ÿá Exif " So there /is/ an exif tag within the header, and it is empty.
You probably chose to include a thumbnail in the image then. Anyway, this bug report is pointless, as it doesn't even point out a problem. The "Save EXIF" button is disabled because there's no EXIF information attached to the image.
Created attachment 109954 [details] A screenshot: "Save as..." dialogue in German with disabled. No, i did not. You really think that I'm THAT stupid? The option to save a miniature thumbnail is turned off. Always, and I always check whether or not this option is turned off. This screenshot is taken by Gimp-win 2.4.5 shows the "Save as..." dialogue in German as I usually save JPEG files and also has the "Exif" key word within its header. The only options I sometimes change are: "Qualität", "Zwischenschritte" and "DCT-Methode", and that's all. The problem is (again): Gimp-win saves JPEGs and puts some weird EXIF tag into their headers WITHOUT being asked/told to do so. 3 tools confirmed that there IS this behaviour, and I'm running three different Windows systems where this happens. The user can't do anything to stop this because the option is disabled - because there is no reason to save an EXIF information where no EXIF information was. Thanks for nothing. This is so f*cking ridiculous to argue on this minor bug because it seems I just can't convince you that there IS a bug. So do what you want, but just quit playing that "developer fools noob" game, okay?
Christoffer, thanks for taking the time to report this. Please understand that GIMP get several bug reports per day and that the developers have no chance of knowing whether the reporter is experienced or not. I am sorry that you feel insulted. I think we should not close this until it is clear what is going on. Reopening.
Could this be due to the fix bug bug #517077?
I am still not convinced yet that there is a bug at all. As far as I can see, there is no code in the JPEG plug-in that would write an Exif header to the file if the Exif and thumbnail options are turned off. And the Exif tools that I trust all show that the attached image file doesn't contain any Exif data. So unless someone can show where the actual problem is, this bug report should be closed as INVALID.
I have same problem. I'm using Debian GNU/Linux unstable, and GIMP 2.4.5-1+b2. I'm currently learning about JPEG file format using hex editor. When I reading a jpeg file that saved by GIMP[1], I noticed it contains EXIF marker. [1] Run GIMP, create a new image, save it as foo.jpg. (Of course, "Save EXIF data" checkbox is disabled and is unchecked.) Here is a dump for foo.jpg: $ hexdump -C -n 100 foo.jpg 00000000 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 48 |......JFIF.....H| 00000010 00 48 00 00 ff e1 00 16 45 78 69 66 00 00 4d 4d |.H......Exif..MM| 00000020 00 2a 00 00 00 08 00 00 00 00 00 00 ff fe 00 13 |.*..............| 00000030 43 72 65 61 74 65 64 20 77 69 74 68 20 47 49 4d |Created with GIM| 00000040 50 ff db 00 43 00 05 03 04 04 04 03 05 04 04 04 |P...C...........| 00000050 05 05 05 06 07 0c 08 07 07 07 07 0f 0b 0b 09 0c |................| 00000060 11 0f 12 12 |....| 00000064 As you can see, it has EXIF marker. (FF E1 00 16 "Exif\0") Also, a image file that original bug reporter attached has EXIT marker. $ hexdump -C -n 100 FairyTailLogo.mywall.jpg 00000000 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 35 |......JFIF.....5| 00000010 00 35 00 00 ff e1 00 16 45 78 69 66 00 00 4d 4d |.5......Exif..MM| 00000020 00 2a 00 00 00 08 00 00 00 00 00 00 ff db 00 43 |.*.............C| 00000030 00 05 03 04 04 04 03 05 04 04 04 05 05 05 06 07 |................| 00000040 0c 08 07 07 07 07 0f 0b 0b 09 0c 11 0f 12 12 11 |................| 00000050 0f 11 11 13 16 1c 17 13 14 1a 15 11 11 18 21 18 |..............!.| 00000060 1a 1d 1d 1f |....| 00000064 jpeginfo tells me that they are EXIF. $ jpeginfo foo.jpg foo.jpg 420 x 300 24bit Exif N 1098 But exif utility tells me that they has no EXIF data. (I don't know why.) $ exif foo.jpg 'foo.jpg' does not contain EXIF data! I checkout the source of GIMP from SVN and built it. Once I did the same as [1], GIMP shows following message. $ ./gimp-2.5 This is a development version of GIMP. Debug messages may appear here. jpeg-save: saving EXIF block (20 bytes) jpeg-save: saving image comment (17 bytes) According to gimp/plug-ins/jpeg/jpeg-save.c, EXIF marker will be written if jsvals.save_exif or jsvals.save_thumbnail is TRUE. jsvals.save_thumbnail will be TRUE if the image has exif data, otherwise it will be FALSE. That's OK. However, jsvals.save_exif will be TRUE always. (Actually jsvals.save_exif can be FALSE only when we unchecked "Save EXIF data" checkbox explicitly.) I think jsvals.save_exif should be FALSE if the image has no exif data. I suggest following patch. --- plug-ins/jpeg/jpeg-save.c (revision 25799) +++ plug-ins/jpeg/jpeg-save.c (working copy) @@ -1004,6 +1004,8 @@ G_CALLBACK (make_preview), NULL); + if (! exif_data) + jsvals.save_exif = FALSE; gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toggle), jsvals.save_exif && exif_data); Regards,
Thank you for a very good analysis Sho-san! Reopening since we should consider the above patch.
The patch is wrong as the jsvals struct must not be changed due to the image we are saving. This struct contains the user settings for saving JPEG images. But there was indeed a bug in the logic. We need to check if jpvals.save_exif is TRUE _and_ exif_data is not NULL. I have done this change in both branches now.
I can confirm the problem were fixed in svn. Thanks for your quick response and fixes.