GNOME Bugzilla – Bug 599702
Sometimes Cropping creates a blank (black) image
Last modified: 2018-07-01 09:02:05 UTC
I cannot consistently reproduce this, but I have observed it on several occasions. It appears to happen when a crop selection is performed that overlaps the image boundary. I have attached an image in which it happens (for me). If I start the selection somewhere in the bottom left quarter then drag it to overlap the left edge, then select crop, the new version is a black image (verifiable outside f-spot) that corresponds to the dimensions of the cropped area. If I do not overlap the image boundary, this does not happen. One theory I had was that it was camera specific (Coolpix S600) but I have tried it on other images on this model and it usually does not happen. I have yet to be able to reproduce this consistently but I've now encountered it on sufficient number of occasions to feel that it might be a bug.
I have tried this on another image in the same batch and found the same problem. Here is the output from f-spot when I perform the crop: (f-spot:560): GdkPixbuf-CRITICAL **: gdk_pixbuf_copy_area: assertion `src_x >= 0 && src_x + width <= src_pixbuf->width' failed value = f-spot version 0.6.1.1 len = 22 value = 2009:10:26 21:31:04 len = 19 Saved 6790 bytes (f-spot:560): GdkPixbuf-CRITICAL **: gdk_pixbuf_loader_close: assertion `GDK_IS_PIXBUF_LOADER (loader)' failed Syncing metadata to file... old = " " new = " " heading = "ASCII" value = 2009:10:24 12:22:57 len = 19 _:bnode-2053645568 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag> . _:bnode-2053645568 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "Temple Park" . _:bnode-2053645568 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "Harrier League" . _:bnode-2053645568 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "Elvet Striders" . _:bnode-2053645568 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "races" . <http://fakebase.f-spot.org/internal/> <http://purl.org/dc/elements/1.1/subject> _:bnode-2053645568 . value = f-spot version 0.6.1.1 len = 22 value = 2009:10:26 21:31:08 len = 19 value = f-spot version 0.6.1.1 len = 22 value = 2009:10:26 21:31:08 len = 19 Saved 6886 bytes
Further experiments confirm that if I do not cross the left hand image boundary the problem does not occur. In the following two bits of output I do not cross the boundary on the first attempt, but I do on the second. On the second attempt f-spot reports: (f-spot:560): GdkPixbuf-CRITICAL **: gdk_pixbuf_copy_area: assertion `src_x >= 0 && src_x + width <= src_pixbuf->width' failed I cannot see any pattern that explains why it only occurs on certain images (although it might be something to do with images I've rotated thru 90degrees - not checked this). # CROPPING RIGHT TO LEFT WITHOUT CROSSING IMAGE EDGE value = f-spot version 0.6.1.1 len = 22 value = 2009:10:26 21:36:38 len = 19 Saved 6910 bytes Syncing metadata to file... old = " " new = " " heading = "ASCII" value = 2009:10:24 12:22:57 len = 19 _:bnode-1811923200 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag> . _:bnode-1811923200 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "Temple Park" . _:bnode-1811923200 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "Harrier League" . _:bnode-1811923200 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "Elvet Striders" . _:bnode-1811923200 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "races" . <http://fakebase.f-spot.org/internal/> <http://purl.org/dc/elements/1.1/subject> _:bnode-1811923200 . value = f-spot version 0.6.1.1 len = 22 value = 2009:10:26 21:36:40 len = 19 value = f-spot version 0.6.1.1 len = 22 value = 2009:10:26 21:36:40 len = 19 Saved 6886 bytes # CROPPING THE SAME IMAGE - THIS TIME CROSSING OVER THE IMAGE BOUNDARY # (DRAGGING THE AREA FROM RIGHT TO LEFT) (f-spot:560): GdkPixbuf-CRITICAL **: gdk_pixbuf_copy_area: assertion `src_x >= 0 && src_x + width <= src_pixbuf->width' failed value = f-spot version 0.6.1.1 len = 22 value = 2009:10:26 21:38:25 len = 19 Saved 6910 bytes Syncing metadata to file... old = " " new = " " heading = "ASCII" value = 2009:10:24 12:22:57 len = 19 _:bnode-406062336 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag> . _:bnode-406062336 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "Temple Park" . _:bnode-406062336 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "Harrier League" . _:bnode-406062336 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "Elvet Striders" . _:bnode-406062336 <http://www.w3.org/1999/02/22-rdf-syntax-ns#li> "races" . <http://fakebase.f-spot.org/internal/> <http://purl.org/dc/elements/1.1/subject> _:bnode-406062336 . value = f-spot version 0.6.1.1 len = 22 value = 2009:10:26 21:38:28 len = 19 value = f-spot version 0.6.1.1 len = 22 value = 2009:10:26 21:38:28 len = 19 Saved 6886 bytes
I think this is connected with rotation. I can reproduce it on a photo taken portrait and rotated within f-spot, but the problem does not occur on a subsequent photo taken landscape.
Created attachment 164084 [details] f-spot with --debug
still happening in 0.7.0
(In reply to comment #3) > I think this is connected with rotation. I can reproduce it on a photo taken > portrait and rotated within f-spot, but the problem does not occur on a > subsequent photo taken landscape. can you provide this picture?
I'll attach two photos - before and after cropping. Same image.
Created attachment 164126 [details] File after cropping
Original uncropped photo too large for upload. Examples of originals (and cropped versions) available at http://nisbet.fotopic.net/c1862899_1.html
Most recent test shows that cropped image is a fraction of the size of the original, even though deliberately attempted to crop as little of the original as possible. Sizes before and after: dougie@pheonix:/jpegs/2010/06/19$ ls -lh *5506* -rwxr-xr-x 1 dougie dougie 3.0M 2010-06-20 13:28 IMG_5506.JPG -rw-r--r-- 1 dougie dougie 138K 2010-06-20 13:59 IMG_5506 (Modified).JPG dougie@pheonix:/jpegs/2010/06/19$
Created attachment 164136 [details] screenshot showing area to crop This attachment shows the area I am about to crop. I've deliberately attempted to crop as little as possible to see how the file size compares of the cropped image.
Created attachment 164137 [details] After clicking on Crop button This attachment shows the black/blank image after clicking on crop.
Created attachment 164138 [details] Output using f-spot --debug
Just a further observation. This definitely seems to be connected with orientation. Photos taken portrait have the problem. Same session with same camera. Photos taken portrait mode have this issue, but not the ones in landscape. My 'rotation' comments are not relevant. Rotation is not required to reproduce the bug.
This needs to be investigated. One fact is that the way Orientations are currently handled in f-spot is rather bad. I've been meaning to look into correcting this (and might do so soon). Doing so might help this bug and will hopefully even fix it.
Still getting this in 0.7.2 It can be a bit frustrating as it creates a useless and undeletable version of the photo.
Still present in 0.8.0 [8 Debug 20:59:37.692] Invalid thumbnail, reloading: file:///jpegs/2010/09/18/IMG_3124.JPG [8 Debug 20:59:37.697] open uri = file:///jpegs/2010/09/18/IMG_3124.JPG [1 Debug 20:59:54.984] FSpot.Editors.CropEditor can be applied? False [1 Debug 21:00:07.876] FSpot.Editors.CropEditor can be applied? True [1 Debug 21:00:07.881] open uri = file:///jpegs/2010/09/18/IMG_3124.JPG Domain: 'GdkPixbuf' Level: Critical Message: gdk_pixbuf_copy_area: assertion `src_x >= 0 && src_x + width <= src_pixbuf->width' failed Trace follows: at GLib.Log.PrintTraceLogFunction(System.String domain, LogLevelFlags level, System.String message) at Gdk.Pixbuf.gdk_pixbuf_copy_area(IntPtr , Int32 , Int32 , Int32 , Int32 , IntPtr , Int32 , Int32 ) at Gdk.Pixbuf.CopyArea(Int32 src_x, Int32 src_y, Int32 width, Int32 height, Gdk.Pixbuf dest_pixbuf, Int32 dest_x, Int32 dest_y) at FSpot.Editors.CropEditor.Process(Gdk.Pixbuf input, Cms.Profile input_profile) at FSpot.Editors.Editor.TryApply() at FSpot.Editors.Editor.Apply() at FSpot.Widgets.EditorPageWidget.Apply(FSpot.Editors.Editor editor) at FSpot.Widgets.EditorPageWidget+<ShowEditor>c__AnonStoreyD.<>m__42(System.Object , System.EventArgs ) at System.Reflection.MonoMethod.InternalInvoke(System.Object , System.Object[] , System.Exception ByRef ) at System.Reflection.MonoMethod.Invoke(System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) at System.Reflection.MethodBase.Invoke(System.Object obj, System.Object[] parameters) at System.Delegate.DynamicInvokeImpl(System.Object[] args) at System.MulticastDelegate.DynamicInvokeImpl(System.Object[] args) at System.Delegate.DynamicInvoke(System.Object[] args) at GLib.Signal.ClosureInvokedCB(System.Object o, GLib.ClosureInvokedArgs args) at GLib.SignalClosure.Invoke(GLib.ClosureInvokedArgs args) at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) at Gtk.Application.gtk_main() at Gtk.Application.Run() at FSpot.Driver.Startup() at Hyena.Gui.CleanRoomStartup.Startup(Hyena.Gui.StartupInvocationHandler startup) at FSpot.Driver.Main(System.String[] args) [1 Debug 21:00:09.121] IndicesOf took 9E-06 [1 Debug 21:00:09.122] Invalid thumbnail, reloading: file:///jpegs/2010/09/18/IMG_3124 (Modified%20(2)).JPG
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.