GNOME Bugzilla – Bug 340155
some images don't import- utterly bizarre
Last modified: 2006-07-26 21:51:20 UTC
About 1/3rd of the images in a recent set of jpg scans Krissa did of some old negatives won't import for some reason. I'll attach a few of them, but there are no errors in the GUI, no errors on the command line, and most bizarrely, they import just fine when the exact same pictures are imported from a CD-ROM. So the process goes something like this: * insert CD containing nothing but pictures * import all of them to f-spot; voila, everything works fine. * nuke them all. * copy them to the place where all my other pictures are stored with: cd $location; cp -r /media/cdrom/* . * import $location * note that there are now 115 pictures imported instead of 165. And nautilus can see/thumbnail them fine on both the CD and in $location; the files are bit-for-bit identical according to md5sum, and essentially permissions are the same. I'm completely mystified. Any pointers on debugging?
Tried with cp -a just to be certain; same results. totally bizarre.
hmmmm very strange. What is the path of one of the images that won't open? Does f-psot --view <path> work?
I'm having the same kind of behaviour with version 0.1.11 on Ubuntu Dapper except that I'm not importing from a CD but from my hard disk. Some photos just don't import. I'm getting following message to command line: loading exif data Error importing /home/user/Desktop/00029.jpg System.ArgumentNullException: Argument cannot be null. Parameter name: src in <0x00000> <unknown method> in (wrapper managed-to-native) System.Runtime.InteropServices.Marshal:copy_from_ unmanaged (intptr,int,System.Array,int) in <0x00013> System.Runtime.InteropServices.Marshal:Copy (IntPtr source, System. Byte[] destination, Int32 startIndex, Int32 length) in <0x00050> Exif.ExifEntry:get_Data () in <0x00054> FSpot.JpegFile:get_Description () in <0x0006d> PhotoStore:Create (System.String newPath, System.String origPath, G dk.Pixbuf thumbnail) in <0x000cd> FileImportBackend:Step (.Photo photo, Gdk.Pixbuf thumbnail, System. Int32 count) Could not import file Stopping Using $ f-spot --view /home/user/Desktop/00029.jpg shows the photo all right. Some photos from the same folder, taken with the same digital camera get imported and some don't.
timing issue?
luis, if you changed options while the import was running I just commited a fix that could potentially have caused this.
Touko, your bug is a different bug, which is now fixed (it has to be different based on the fact that luis' photos imported normally.
Created attachment 68005 [details] The exif dump of the file before being rotated in gThumb
I have the same problem, and I receive the same messages like Touko. I'm using F-Spot 0.1.11 on Ubuntu Dapper. In my case, all the photos that were not importing were old vertical shots that were rotated with gthumb (2.7.6). Lo and behold, once I rotated a photo with gthumb it no longer imported into F-spot. Rotating it back to the original position does not fix the import problem. I've attached the exif probe outputs for the file before and after the rotate.
Created attachment 68006 [details] The exif dump of the file after being rotated in gThumb
By adding a few checks to ExifEntry.get_Data(), everytime the exception is thrown _handle->size <= 0 and _handle->data == IntPtr.Zero. The get_Data() function appears to be called when trying to get the UserComment field. Looking more closely at the EXIF dump for the failed import, I noticed that the UserComment field is UserComment [7 =UNDEFINED 0] = EMPTY (value=0) when originally it was UserComment [7 =UNDEFINED 125] = @0xcb8=3256 Maybe the fact that the field is being erased is a gThumb bug, but as all other programs gracefully handle this, f-spot also should. Here is a simple fix ( also attached as a file) diff -aur f-spot-0.1.11/src/Exif.cs f-spot-0.1.11_new/src/Exif.cs --- f-spot-0.1.11/src/Exif.cs 2005-12-07 02:49:44.000000000 -0500 +++ f-spot-0.1.11_new/src/Exif.cs 2006-06-28 00:13:54.000000000 -0400 @@ -525,6 +525,10 @@ public byte [] Data { get { unsafe { + if ((_handle->size <= 0) || (_handle->data == IntPtr.Zero)) + { + return null; + } byte [] data = new byte [_handle->size]; Marshal.Copy (_handle->data, data, 0, (int)_handle->size); return data; diff -aur f-spot-0.1.11/src/JpegFile.cs f-spot-0.1.11_new/src/JpegFile.cs --- f-spot-0.1.11/src/JpegFile.cs 2006-02-28 23:12:25.000000000 -0500 +++ f-spot-0.1.11_new/src/JpegFile.cs 2006-06-28 00:13:56.000000000 -0400 @@ -61,7 +61,9 @@ if (entry == null) return null; - + if (entry.Data == null) + return null; + UserComment comment = new UserComment (entry.Data, entry.ByteOrder == Exif.ByteOrder.Intel); return comment.Value; } I suppose I could have chosen to catch the exception "Invalid UserComment value, no charset found" instead of checking in entry.Data is null _OR_ checked for null data in the UserComment constructor. In addition, it probably would be helpful during import to list files that failed to import. I only found out by noticing a large number of missing pictures in my library. This is only my $0.02, but it seemed to work for my case. One little caveat, now all my pictures import, but some files always show up in thumbnail and edit photo mode with the original rotation. With other application the photos have the correct rotation. If I have f-spot rotate the photo, the thumbnail then correctly matches the image. Sorry for the long post, but hopefully it helps! Regards, Michael Ihde
Created attachment 68102 [details] [review] Proposed patch This patch only fixes the import process...however, now that it imports correctly other oddities begin to show up.
Sorry for not doing my homework, but this seems to have been fixed in the CVS version...my apologies!
re #12 no problem, thanks for the patch even if it is already fixed.
I'm closing this as fixed.