Version: (using KDE 4.3.1) OS: Linux Installed from: Fedora RPMs I have a JPG with EXIF data (camera, time/date, etc.) - I upload this unretouched image to Flickr, and view the meta data. Everything looks fine. I then use the convert to PNG function in digiKam. I upload this PNG image to Flickr, and view the meta data, everything again appears fine, i.e. the convert function appears to correctly copied the EXIF data to the PNG image file and Flickr recognizes and displays the data. I then use the Geolocation function to add the location data. I do this for the JPG and PNG images. After I upload to Flickr, the EXIF data (camera, time/date, etc.) is now gone.
Sound like a bug in Flickr, not digiKam. Anyway Exif data still compatible and managed in background by Exiv2 library... Gilles Caulier
Actually it's not a Flickr bug but a Flickr feature, and not a digiKam bug but a missing Kipi Plugins feature :P When uploading to Flickr, you can specify tags, comments, safety level etc., but not the location. If you want to do that, you have to make a separate web call which at the moment isn't done. I'll see if I can implement that. In the meantime, there's a Flickr setting to let it recognize the locations. If you go to http://www.flickr.com/account/?tab=privacy, you'll see the option "Import EXIF location data". Turn that on and Flickr will always read the location from your Exif data.
Well, a picture is worth a thousand words.... ;-) www.flickr.com/photos/9550073@N03/ Here is the photostream which explains a bit better what I am talking about. When you click on the picture, you can see the meta data by adding "/meta" without the quotes to the URL displayed. The basejpg, basepng photos are the photos from digiKam before I tried to add the geolocation information. The geojpg, geopng photos have the location information added. If you look at the meta data you will see it appears that all the information shown in the base photos is now gone. I wouldn't think that adding the location information would then make all the other info to disappear, but that is what apparently is happening.
This looks strange. Does digikam still show meta information for the geo-files?
Yes, the meta data (including location coordinates) show fine under digiKam.
Ok, there are two things you could try. 1. use exiftool on that files. Does it show meta data? if it doesn't 2. use image -> write metadata to image and see again if the meta data are really present in the file
I ran the exiftool command, and indeed the display is now different for the base and geo files. The base file displays the following sections: File, IFD0, ExifIFD, Canon, InteropIFD, IFD1 and Composite. The geo file displays only File, JFIF and Composite. digiKam shows the information for the geo file in the EXIF section, so I know the information isn't lost, but apparently it is stored in a place where Flickr and exiftool aren't looking. Is this the way it is suppose to work?
I also checked with the gqview package - the exif info also appears there, even though it doesn't show up using the exiftool program.
Digikam has some options to set whether to store meta data in the exif tags etc. or only in its internal database. Did you also try the second step I proposed? Otherwise you could try to set the options to store information in the exif data and try it again.
Johannes, This way must work, but witha recent of kipi-plugins. I remember to have fixed a bug to flickr tool to not lost Exif data when image are resized before to upload. Anyway, with KDE4 version, we can now get GPS info from digiKam database. libkipi and digiKam kipi interface can do it. We just need to pass these info to flickr API. Gilles Caulier
Johannes, Some pointers : http://lxr.kde.org/source/extragear/graphics/digikam/utilities/kipiiface/kipiimageinfo.cpp#147 http://lxr.kde.org/source/KDE/kdegraphics/libs/libkipi/libkipi/imageinfo.cpp#78 Gilles
Johannes, No I did not try the second option, since I really didn't understand how to use the image command. I did however display the exif data using the gqview program, and the information is showing in the exif using that program, but it doesn't show when using exiftool. Interestingly enough, for jpg files, picasaweb can see the information and appropriately shows the correct map information - but does not recognize anything for the png files.
(In reply to comment #12) > No I did not try the second option, since I really didn't understand how to use > the image command. Digikam stores some infos in an internal database. If you select an image and use this command, digikam writes all information present in the database back to the image, if they are somehow supported by exif, iptc and so on. So it would be worth to select one of the geo-files and use this menu option. It cannot destroy more than that single image. ;) So it would be worth a try if the exif information is correct after that. > I did however display the exif data using the gqview program, and the > information is showing in the exif using that program, but it doesn't show when > using exiftool. > > Interestingly enough, for jpg files, picasaweb can see the information and > appropriately shows the correct map information - but does not recognize > anything for the png files. After this ans playing a bit with gqview I suspect that there is something damaged in the exif information stored in the geo files. Opening this file in gqview creates this warning: exif tag unknown data size mismatch Gilles: Using the flickr api to set the location is of course something to be implemented, but as far as I can see this bug is more about somehow damaging the exif structure in the files. I'm really not into how this works. Who knows how to debug this?
Me and Andreas, can help you. Andreas is Exiv2 author. Exiv2 is used here to restore, through libkexiv2 interface all metadata from origianl image to resized image uploaded to flickr. Test to do : 1/ Identify if a non resized image is not corrupted by flickr. If yes, it's not an Exiv2 problem. 2/ Isolated resized image in local, before uploading. Compare metadata with original, using ExifTool. Code relevant is there : http://lxr.kde.org/source/extragear/graphics/kipi-plugins/flickrexport/flickrtalker.cpp#625 3/ Post information here, and follow Andreas tips. He is in CC. Gilles
I want to make sure we are not going down the wrong path here. I did not use the upload function within digiKam to upload the images to flickr. I used the basic web upload from the flickr website. Also, after I uploaded the photos to flickr, I then downloaded them (original size) back to my computer and then did a diff to compare, they are identical. So, that tells me that nothing is being changed by uploading the pictures to flickr. All I did was use the function within digiKam to write geo data - I made no other changes to the base photos. I hope that explains the situation. You can duplicate by downloading one of the base photos (original size) from Flickr and then adding geotag information.
Ok, this is of course a useful information. But I can't reproduce your problem here. What I did was: 1. Downloading your original jpg from flickr 2. Adding it in a digikam album 3. Adding coordinates to it via image -> geo localization -> add coordinates Afterwards all exif information seems to be good. Can you please provide a step by step description of what you have done including the image files used.
Thanks for your assistance. What I did was use the basepng.png file. I then selected the file from the album view so the file was highlighted, but the rest of the photos still showed in the folder. I then selected image, geolocation, edit coordinates. This added the geolocation information to the png file. I then used the convert function to create the jpg version of the image. The basepng.png file was created from the original source file from the camera using the convert function. This gives me the geojpg.jpg and the geopng.png files. So are you saying you do the same thing and the exiftool shows the correct information for both the basepng.png and geopng.png file? When I do it, it is different (as you can see from the files I uploaded to flickr).
Ok, now I see the problem. The exif corruption seems to happen when assigning the gps coordinates to the png file. The strange thing is that this only happens for the png file you provided. I've tested it with other png files of my own and even with a png converted from your original jpg. None of them showed the same problem. Does this happen for you with every png you got or created the same way like the one you uploaded to flickr?
Yes, this has happened to all the files I have tried to upload to Flickr so far. What I have been doing is using the convert function on jpg files to switch them to PNG for archiving purposes. I then geotag the file. I converted the geotagged png file back to jpg to upload since png wasn't working. I then discovered the problem. It is good you were able to re-create. Hopefully it can be determined what the problem is.
Do you use Exiv2 0.18.2 ? I have implemented PNG support to Exiv2. I recommend to use this version Look in Help/Components Info for details... Gilles Caulier
Yes, I use Exiv2 0.18.2
I received my response back from Flickr support today, which is basically what we have already discovered: After using the geolocation function and prior to uploading to Flickr, does the file on your computer still show the EXIF? Because the originals posted in your Flickr photostream, geopng and geojpg, do not have any EXIF metadata embedded within them and our upload servers do not do any processing to the originals. It is probably best to ask the developer of the image editing software about the lack of EXIF after using the geotagging function.
Created attachment 37587 [details] output from exiv2 -pa geopng.png
OK, I found and installed the exiv2 program. The output is too long put put in the comments so I have attached the output in a file. Here is the command I ran: exiv2 -pa geopng.png > exiv2pa_geopng.png I also receive this message which Johannes referred to above which about and unknown entry in the file. This shows each time I run the command: Warning: Directory Image, entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1. If you look at the attachment, you will see the geo information is in the file. What I do not understand is why it shows when using the exiv2 command rather than the exiftool command? As I mentioned earlier, Flickr replied and they do not see EXIF information either. I hope this helps discover the issue. Thanks again!
OK, I think I have figured out exactly what is going on. When I convert a JPG to a PNG file, the conversion causes corruption of the EXIF data buy adding the "Exif.Image.0x0001". This corrupted tag is causing Flickr and EXIFTOOL not to function properly. EXIV2 shows the correct part of the EXIF data and issues a warning regarding "Exif.Image.0x0001". I found I can use EXIV2 to remove the corrupted tag by issuing the following command: exiv2 -M "del Exif.Image.0x0001" image_file_name wildcards also appear to work, so I can delete the corrupted tag for all png files in the directory by entering: exiv2 -M "del Exif.Image.0x0001" *.png You should be able to recreate by taking a jpg file, and using the convert function (Select the file, then use Batch, Convert). If you enter exiv2 -pa file_name - you will see the warning: Warning: Directory Image, entry 0x0001 has unknown Exif (TIFF) type 0; setting type size 1. after you do the convert from jpg to png. Then try: exiftool -a -u -g1 file_name You will not see the complete EXIF information. Then delete the invalid tag: exiv2 -M "del Exif.Image.0x0001" image_file_name and when you run the exiftool command again, everything should be OK. So the badness is being introduced by whatever does the convert from JPG to PNG.
No. it's not a problem to file format conversion, but metadata transfert. This is a problem with Exiv2 library. Please report to Exiv2 bugzilla... Gilles Caulier
I opened bug 650 under Exiv2: http://dev.exiv2.org/issues/show/650 I also discovered this evening that even though I can apparently remove the invalid tag, something is still wrong with the file which causes the tag information to not be viewable by Flickr. I consider this a serious issue since unless people are checking their files with Flickr, they may be unknowingly introducing corruption - and if they haven't backed up their source (and they may not since they consider PNG their archive), they will be stuck with a corrupted file. If they do have original backups they will have to redo all their tags.
Let's continue the discussion here rather than heading over to the Exiv2 bug tracker. For now I don't understand what needs to be fixed. 1. Where do the invalid tags come from? From an Exiv2 perspective these tags are not immediately a problem: Exiv2 will add such tags if instructed to do so, and that's not a bug. It is only an issue if Exiv2 adds them without the user's instructions. Gilles, have you checked if these are added by the application? If they aren't, how do I get Exiv2 to add these tags by itself - a reproducer would be helpful? Can you point me to the relevant code that onverts from JPG to PNG? 2. Why does Flickr not see the GPS tags in the image without the invalid tag? After removing the invalid tags, exiftool also considers the metadata valid. I'm at a loss as to what prevents Flickr from seeing the GPS tags. Gerald, with two open-source programs having no problems with the metadata, maybe you can convince the good people at Flickr to take a closer look at the image and advise what they think is wrong with it. Andreas
Andreas, Converting JPG to PNG use libjpeg to open image data and libpng to write image data. In all case, metadata are not transfered by this way. All is deegate by libkexiv2 and Exiv2. I'm sure that no tags like this is added by digiKam and code. Why we will do it ? Relevant code: PNG save image : http://lxr.kde.org/source/extragear/graphics/digikam/libs/dimg/loaders/pngloader.cpp#555 Metadata transfert : DMetadata = libkexiv2 customization for digiKam http://lxr.kde.org/source/extragear/graphics/digikam/libs/dimg/loaders/dimgloader.cpp#194 That all (:=))) Each Exif, Iptc, Xmp block are transfered as well from JPG to PNG. As you know PNG image structure do not depand of metadata. Each metadata block are hosted in a dedicated png chunk. It's clean and better than TIFF... Gilles
Thanks again for everyone helping with this. I have an open case with Flickr on this issue. I have done some additional testing. Here is the copy of the note I sent them. I will let you all know what they say. Here is the note: ================== OK, I found a tag of: "Exif.Image.0x0001" which was causing some issues with some programs. When I used the exiv2 tool, it issued a warning for this tag. When I used the exiftool utility, it wouldn't display the exif info, so I deleted the tag and both programs were able to read. I then downloaded the file basepng.png from Flickr. I added the geotag information. I then used a conversion utility to create a jpg version of this file. I then uploaded both of these files to Flickr. The link for the PNG version is: http://www.flickr.com/photos/9550073@N03/4017660506/meta The link for the JPG version is: http://www.flickr.com/photos/9550073@N03/4016899647/meta I also attached two files: The exiv2jpg shows the tag information for the jpg version The exiv2png shows the tag information for the png version As you can see the tag information is identical, and remember the jpg file was created from the png version with no additional processing. And both of the files above were created from the basepng.png file which was downloaded from Flickr. For some reason, Flickr is still not showing the PNG file after it has been tagged with the geo information. However, the tag information shows up fine in the basepng file which is here: http://www.flickr.com/photos/9550073@N03/4001381895/meta What is happening? ==================
Created attachment 37637 [details] Output from exiv2 -pt corrected_geo.jpg
Created attachment 37638 [details] Output from exiv2 -pt corrected_geo.png
An additional note of clarification I didn't put in the note to Flickr which I am sending now. You will notice that the tag information is showing correctly (including the geo information for the corrected_geo.jpg file - it is not showing for the corrected_geo.png file. This gets a bit confusing, so I try to explain as follows: 1. I downloaded the basepng.png file from Flickr ===> http://www.flickr.com/photos/9550073@N03/4001381895/meta 2. I removed the bad tag by: exiv2 -M "del Exif.Image.0x0001" basepng.png (yes, the file which is showing tag information on Flickr has the invalid tag which the exiftool program does not like - but apparently Flickr doesn't care) 3. I copied basepng.png to corrected_geo.png 4. I added the location information to corrected_geo.png (note, adding the geo information does not add the bad tag. That appears to be introduced when using the convert function. I validated using exiftool and exiv2 that the tag information was correct and included the location information.) 5. I created corrected_geo.jpg by converting the corrected_geo.png file (with the location information added in step 4) to a jpg file. 6. The corrected_geo.jpg now has an invalid tag. I remove by issuing: exiv2 -M "del Exif.Image.0x0001" corrected_geo.jpg 7. I verify that the tag information can be seen using exiv2 and exiftool for both files 8. I upload corrected_geo.png to Flickr http://www.flickr.com/photos/9550073@N03/4017660506/meta ====> The tag information is NOT showing <===== 9. I upload corrected_geo.jpg to Flickr http://www.flickr.com/photos/9550073@N03/4016899647/meta ====> The tag information IS showing (including the location information) <==== To recap: 1. basepng.png on Flickr shows tag information correctly 2. corrected_geo.png created from basepng.png with location information added does not show tag information on Flickr 3. corrected_geo.jpg created from corrected_geo.png SHOWS tag information correctly
Here is the latest communication from Flickr. There developers are going to research, but they asked me to pass this information along. If you look, you will notice there is a difference between the tags in the PNG file and the JPG file which was created from the PNG file. My comments back to Flickr are at the beginning of the note: ========== Cris, Thanks for the reply and again for your looking into this. I would expect to see some differences between the jpg and png files since they are different formats. However, what I am curious about is why the EXIF information shows up in the png file here: http://www.flickr.com/photos/9550073@N03/4001381895/meta - which is the basepng.png file in the photo stream and not in the png file which has the geo information? Also, its weird that the jpg version shows "unknown tag" information, and displays alot of the info on Flickr whereas the png version appears to show the info fine using exiftool below (with no unknown tags) but basically shows nothing on Flickr. I'll run this information below by the developers and see what they say. In the meantime, I think we'll all be interested in what Flickr says. Thanks again! On Fri, Oct 23, 2009 at 13:28, Flickr Support <case1305438@support.flickr.com> wrote: - Hide quoted text - > Hello, > > Actually, we do see a difference in metadata between these > two images. This is the EXIF from the originals on Flickr, > so I'm not at all sure what the software company is > referring to. You may want to run this data past them. > > As I mentioned earlier, our developers are going to take a > look at this case to see if we're displaying the metadata > that we normally display. Bear in mind that we do not alter > the originals posted to Flickr and that if the metadat that > we expect to find in the file is not there, then we won't be > adding it to the More Properties page. > > Thanks, > Cris > > > ==== metatdata examples (2) ==== > > 1. This photo does not have metadata on Flickr: > http://www.flickr.com/photos/9550073@N03/4017660506/meta > > > ---- ExifTool ---- > ExifTool Version Number : 7.89 > ---- System ---- > File Name : > 4017660506_81fce130de_o.png > File Size : 10 MB > File Modification Date/Time : 2009:10:23 09:22:35-07:00 > ---- File ---- > File Type : PNG > MIME Type : image/png > Exif Byte Order : Little-endian (Intel, II) > ---- PNG ---- > Image Width : 3264 > Image Height : 2448 > Bit Depth : 8 > Color Type : RGB > Compression : Deflate/Inflate > Filter : Adaptive > Interlace : Noninterlaced > Pixels Per Unit X : 7086 > Pixels Per Unit Y : 7086 > Pixel Units : Meters > ---- IFD0 ---- > Make : Canon > Camera Model Name : Canon PowerShot S80 > Orientation : Horizontal (normal) > Y Resolution : 180 > Resolution Unit : inches > Modify Date : 2007:08:11 07:59:01 > Y Cb Cr Positioning : Centered > ---- ExifIFD ---- > Exposure Time : 1/1000 > F Number : 4.0 > Exif Version : 0220 > Date/Time Original : 2007:08:11 07:59:01 > Create Date : 2007:08:11 07:59:01 > Components Configuration : Y, Cb, Cr, - > Compressed Bits Per Pixel : 3 > Shutter Speed Value : 1/1002 > Aperture Value : 4.0 > Exposure Compensation : 0 > Max Aperture Value : 2.8 > Metering Mode : Multi-segment > Flash : Off, Red-eye reduction > Focal Length : 5.8 mm > User Comment : > Flashpix Version : 0100 > Color Space : sRGB > Exif Image Width : 3264 > Exif Image Height : 2448 > Focal Plane X Resolution : 11412.58741 > Focal Plane Y Resolution : 11439.25234 > Focal Plane Resolution Unit : inches > Sensing Method : One-chip color area > File Source : Digital Camera > Custom Rendered : Normal > Exposure Mode : Auto > White Balance : Auto > Digital Zoom Ratio : 1 > Scene Capture Type : Landscape > ---- Canon ---- > Macro Mode : Normal > Self Timer : Off > Quality : Fine > Canon Flash Mode : Off > Continuous Drive : Single > Focus Mode : Single > Record Mode : JPEG > Canon Image Size : Large > Easy Mode : Landscape > Digital Zoom : None > Contrast : Normal > Saturation : Normal > Sharpness : 0 > Camera ISO : Auto > Metering Mode : Evaluative > Focus Range : Auto > AF Point : Auto AF point selection > Canon Exposure Mode : Easy > Lens Type : Unknown (-1) > Long Focal : 20.7 mm > Short Focal : 5.8 mm > Focal Units : 1000/mm > Max Aperture : 2.8 > Min Aperture : 8 > Flash Bits : (none) > Focus Continuous : Single > AE Setting : Normal AE > Zoom Source Width : 3264 > Zoom Target Width : 3264 > Spot Metering Mode : Center > Photo Effect : Off > Manual Flash Output : n/a > Focal Type : Zoom > Focal Length : 5.8 mm > Focal Plane X Size : 7.44 mm > Focal Plane Y Size : 5.59 mm > Auto ISO : 100 > Base ISO : 50 > Measured EV : 10.31 > Target Aperture : 4 > Target Exposure Time : 1/1002 > Exposure Compensation : 0 > White Balance : Auto > Slow Shutter : Off > Shot Number In Continuous Burst : 0 > Optical Zoom Code : 0 > Flash Guide Number : 0 > Flash Exposure Compensation : 0 > Auto Exposure Bracketing : Off > AEB Bracket Value : 0 > Control Mode : Camera Local Control > Focus Distance Upper : 65.53 > Focus Distance Lower : 0 > F Number : 4 > Exposure Time : 1/1002 > Bulb Duration : 0 > Camera Type : Compact > Auto Rotate : None > ND Filter : Off > Self Timer 2 : 0 > Flash Output : 0 > Canon Image Type : IMG:PowerShot S80 JPEG > Canon Firmware Version : Firmware Version 1.00 > File Number : 100-0544 > Owner Name : > Canon Model ID : PowerShot S80 > Num AF Points : 9 > Valid AF Points : 9 > Canon Image Width : 3264 > Canon Image Height : 2448 > AF Image Width : 3264 > AF Image Height : 204 > AF Area Width : 588 > AF Area Height : 37 > AF Area X Positions : -588 0 588 -588 0 588 > -588 0 588 > AF Area Y Positions : -38 -38 -38 0 0 0 38 38 > 38 > AF Points In Focus : 4,7 > Primary AF Point : 4 > Thumbnail Image Valid Area : 0 0 0 0 > Date Stamp Mode : Off > My Color Mode : Off > Firmware Revision : 1.00 rev 6.00 > ---- InteropIFD ---- > Interoperability Index : R98 - DCF basic file > (sRGB) > Interoperability Version : 0100 > Related Image Width : 3264 > Related Image Height : 2448 > ---- GPS ---- > GPS Version ID : 2.0.0.0 > GPS Latitude Ref : North > GPS Latitude : 37 deg 48' 38.88" > GPS Longitude Ref : West > GPS Longitude : 119 deg 29' 8.19" > GPS Altitude Ref : Above Sea Level > GPS Altitude : 2569 m > GPS Map Datum : WGS-84 > ---- IFD1 ---- > Compression : JPEG (old-style) > X Resolution : 180 > Y Resolution : 180 > Resolution Unit : inches > Thumbnail Offset : 2506 > Thumbnail Length : 3857 > ---- Composite ---- > Aperture : 4.0 > Drive Mode : Single-frame shooting > GPS Altitude : 2569 m Above Sea Level > GPS Latitude : 37 deg 48' 38.88" N > GPS Longitude : 119 deg 29' 8.19" W > GPS Position : 37 deg 48' 38.88" N, 119 > deg 29' 8.19" W > ISO : 50 > Image Size : 3264x2448 > Lens : 5.8 - 20.7 mm > Lens ID : Unknown 5-20mm > Scale Factor To 35 mm Equivalent: 4.6 > Shooting Mode : Landscape > Shutter Speed : 1/1000 > Thumbnail Image : (Binary data 3857 bytes, > use -b option to extract) > Circle Of Confusion : 0.006 mm > Field Of View : 67.4 deg > Focal Length : 5.8 mm (35 mm equivalent: > 27.0 mm) > Hyperfocal Distance : 1.30 m > Lens : 5.8 - 20.7 mm (35 mm > equivalent: 27.0 - 96.2 mm) > Light Value : 15.0 > > > > === > 2. This photo does have metadata on Flickr: > http://www.flickr.com/photos/9550073@N03/4016899647/meta > > ---- ExifTool ---- > ExifTool Version Number : 7.89 > ---- System ---- > File Name : > 4016899647_c93c8e10fd_o.jpg > File Size : 4.1 MB > File Modification Date/Time : 2009:10:23 09:34:34-07:00 > ---- File ---- > File Type : JPEG > MIME Type : image/jpeg > Exif Byte Order : Little-endian (Intel, II) > Image Width : 3264 > Image Height : 2448 > Encoding Process : Baseline DCT, Huffman > coding > Bits Per Sample : 8 > Color Components : 3 > Y Cb Cr Sub Sampling : YCbCr4:2:2 (2 1) > ---- JFIF ---- > JFIF Version : 1.01 > Resolution Unit : inches > X Resolution : 180 > Y Resolution : 180 > ---- IFD0 ---- > Make : Canon > Model : Canon PowerShot S80 > Orientation of image : 1 > Resolution unit : inch > File date and time : 2007:08:11 07:59:01 > Y and C positioning : centered > -- Exif IFD -- : > Exposure time : 1/1000 s > F number : 4.0 > Exif version : 0220 > Date and time of original data generation : 2007:08:11 > 07:59:01 > Date and time of digital data generation : 2007:08:11 > 07:59:01 > Meaning of each component : reserved > Image compression mode : 3.0 > Shutter speed : 10.0 APEX = 1/1002 s > Aperture : 4.0 APEX = F4.0 > Exposure bias : 0.0 > Maximum lens aperture : 3.0 APEX = F2.8 > Metering mode : Pattern > Flash : reserved > Lens focal length : 5.8 mm > -- Canon IFD -- : > Unknown tag (1) : {92,2,0,3,0,0,0,4,65535,1,...} > Unknown tag (2) : {2,5800,293,220} > Unknown tag (3) : {0,0,0,0} > Unknown tag (4) : {68,0,128,330,128,319,0,0,0,0,...} > Unknown tag (0) : {1,0,0,160,0,0} > Image Type : IMG:PowerShot S80 JPEG > Firmware Version : Firmware Version 1.00 > Image Number : 1000544 > Owner Name : > Unknown tag (13) : {0,1,0,985,13,13,-6,0,0,0,...} > Unknown tag (16) : 24510464 > Unknown tag (0) : {0,0,0,0,0,0,0,0,0} > Unknown tag (18) : > {9,9,3264,2448,3264,204,588,37,64948,0,...} > Unknown tag (19) : {0,0,0,0} > Unknown tag (24) : > Unknown tag (25) : 1 > Unknown tag (28) : 0 > Unknown tag (29) : {32,1,0,2,2,2,2,0,0,0,...} > Unknown tag (30) : 16778752 > -- End of Canon IFD -- : > User comments : 264 bytes > Supported Flashpix version : 0100 > Color Space : sRGB > Valid image width in pixel : 3264 > Valid image height in pixel : 2448 > -- Interoperability IFD -- : > Interoperability Index : R98 > Interoperability Version : 0100 > Related Image Width : 3264 > Related Image Height : 2448 > -- End of Interoperability IFD, EXIF IFD continues : > Focal plane x resolution : 11412.6 (1632000/143) ppi (pixel > per inch) > Focal plane y resolution : 11439.3 (1224000/107) ppi (pixel > per inch) > Focal plane resolution unit : inch > Sensing method : One-chip color area sensor > File source : DSC > Custom image processing : Normal process > Exposure method : Auto exposure > White balance : Auto white balance > Digital zoom ratio : 1.0 > Scene capture type : Landscape > -- Main IFD continues -- : > -- GPS IFD -- : > GPS tag version : 0,0,0,2 > North or South Latitude : N > Latitude : 37°48'38.88" > East or West Longitude : W > Longitude : 119°29'8.19" > Altitude reference : Sea level > Altitude : 2569.0m > Geodetic survey data used : WGS-84 > -- Thumbnail IFD -- : > Compression scheme : JPEG > X resolution : 180.0 ppi (pixel per inch) > Y resolution : 180.0 ppi (pixel per inch) > Resolution unit : inch > Offset to JPEG SOI : 2486 > Bytes of JPEG data : 3857 > > >
Any news from Flickr?
I'm rejecting the related exiv2 bug (http://dev.exiv2.org/issues/show/650). Nothing can be done without specific information about what is wrong. Andreas
New digiKam 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ?
Gerald, digiKam 5.0.0 is published. This problem still reproducible with this release ? Gilles Caulier
closing following comment #36