GNOME Bugzilla – Bug 25266
[gimp-bug] Load, Crop, then Save results in original (not cropped) image being saved
Last modified: 2009-08-15 18:40:50 UTC
Package: gimp Version: 1.1.25 Name........: Raphael Quinet Email.......: quinet@gamers.org Platform....: Linux/x86 and Solaris/Sparc GIMP Version: 1.1.25 GTK Version.: 1.2.8 WM/Version..: any -- Other system notes: This happens with 1.1.25 on several platforms (Linux and Solaris) and even with the Linux binaries delivered by HelixCode. -- -- Problem description: If you load an image (containing one or several layers) and the first operation that you do on this image is to crop a part of it with the crop tool, then the canvas is resized but the layers do not seem to be affected. If you then save the image without flattening it first, then the original layers are saved, ignoring the area that should have been cropped. The problem can be seen easily if you save the image in the JPEG format, because the preview will show an area that does not match what should be visible (the offset for the preview is <0,0>). This is a strange bug, because I was only able to reproduce it if I load the image from the File->Open dialog, not if I load it from the list of recent documents (why is there a difference?). Also, the crop tool should be the first thing that you use on the image and you should crop by clicking in the middle of the selected area, not by pressing the "Crop" button. If you crop, then undo, then crop again, then the operation is performed correctly and the bug cannot be reproduced. Same if you perform any other operation (color correction, any filters, ...) on the image before cropping. So this only happens in the sequence Load-Crop-Save. Very strange... To add to the confusion, the thumbnail that is saved with the image (in .xvpics/*) shows the cropped version! This means that if you look at the thumbnail, you will think that everything went fine but the image does not match the thumbnail. I was affected by this bug because I had to crop a large number of images, so I used the sequence Load-Crop-Save very often. It is only when I was halfway through that I reloaded one of the images and I saw the problem. I had to re-open all images one by one (because I could not trust the thumbnails), crop them again, and flatten before saving in order to be sure that everything would be OK. -- -- How to repeat: - Open an image using File->Open. - Use the crop tool to select an area in the middle of the image. - Click in this area to crop the image. - Save the image in any format (if you select JPEG, you will see that the preview is incorrect) -- -- Other comments: -- ------- Additional Comments From austin@gimp.org 2000-09-20 12:52:23 ---- Subject: Re: Bug#25266: [gimp-bug] Load, Crop, then Save results in original (not cropped) image being saved From: Austin Donnelly <austin@gimp.org> To: 25266@bugs.gnome.org, 23610@bugs.gnome.org Message-Id: <14792.60231.225540.59859@hornet.cl.cam.ac.uk> Date: Wed, 20 Sep 2000 17:52:23 +0100 On Wednesday, 20 Sep 2000, quinet@gamers.org wrote: > Package: gimp > Version: 1.1.25 > > Name........: Raphael Quinet > Email.......: quinet@gamers.org > Platform....: Linux/x86 and Solaris/Sparc > GIMP Version: 1.1.25 > GTK Version.: 1.2.8 > WM/Version..: any > > > -- Other system notes: > This happens with 1.1.25 on several platforms (Linux and > Solaris) and even with the Linux binaries delivered by > HelixCode. > > -- > > -- Problem description: > If you load an image (containing one or several layers) and > the first operation that you do on this image is to crop a > part of it with the crop tool, then the canvas is resized > but the layers do not seem to be affected. If you then save > the image without flattening it first, then the original > layers are saved, ignoring the area that should have been > cropped. This bug (or one very similar to it) is also present in gimp 1.0.4, and already has a bug open on it: see bug report #23610. I can reproduce that bug on 1.0.4 and 1.1.25, so I expect yours will fall into the same category. Austin > The problem can be seen easily if you save the image in the > JPEG format, because the preview will show an area that does > not match what should be visible (the offset for the preview > is <0,0>). > > This is a strange bug, because I was only able to reproduce > it if I load the image from the File->Open dialog, not if I > load it from the list of recent documents (why is there a > difference?). > > Also, the crop tool should be the first thing that you use > on the image and you should crop by clicking in the middle > of the selected area, not by pressing the "Crop" button. > If you crop, then undo, then crop again, then the operation > is performed correctly and the bug cannot be reproduced. > Same if you perform any other operation (color correction, > any filters, ...) on the image before cropping. > > So this only happens in the sequence Load-Crop-Save. Very > strange... > > To add to the confusion, the thumbnail that is saved with > the image (in .xvpics/*) shows the cropped version! This > means that if you look at the thumbnail, you will think that > everything went fine but the image does not match the > thumbnail. > > I was affected by this bug because I had to crop a large > number of images, so I used the sequence Load-Crop-Save very > often. It is only when I was halfway through that I > reloaded one of the images and I saw the problem. I had to > re-open all images one by one (because I could not trust the > thumbnails), crop them again, and flatten before saving in > order to be sure that everything would be OK. > > -- > > > -- How to repeat: > - Open an image using File->Open. > - Use the crop tool to select an area in the middle of the > image. > - Click in this area to crop the image. > - Save the image in any format (if you select JPEG, you will > see that the preview is incorrect) > > -- > > > -- Other comments: > > -- ------- Additional Comments From austin@gimp.org 2000-09-20 12:52:23 ---- Subject: Re: Bug#25266: [gimp-bug] Load, Crop, then Save results in original (not cropped) image being saved From: Austin Donnelly <austin@gimp.org> To: 25266@bugs.gnome.org, 23610@bugs.gnome.org Message-Id: <14792.60231.225540.59859@hornet.cl.cam.ac.uk> Date: Wed, 20 Sep 2000 17:52:23 +0100 On Wednesday, 20 Sep 2000, quinet@gamers.org wrote: > Package: gimp > Version: 1.1.25 > > Name........: Raphael Quinet > Email.......: quinet@gamers.org > Platform....: Linux/x86 and Solaris/Sparc > GIMP Version: 1.1.25 > GTK Version.: 1.2.8 > WM/Version..: any > > > -- Other system notes: > This happens with 1.1.25 on several platforms (Linux and > Solaris) and even with the Linux binaries delivered by > HelixCode. > > -- > > -- Problem description: > If you load an image (containing one or several layers) and > the first operation that you do on this image is to crop a > part of it with the crop tool, then the canvas is resized > but the layers do not seem to be affected. If you then save > the image without flattening it first, then the original > layers are saved, ignoring the area that should have been > cropped. This bug (or one very similar to it) is also present in gimp 1.0.4, and already has a bug open on it: see bug report #23610. I can reproduce that bug on 1.0.4 and 1.1.25, so I expect yours will fall into the same category. Austin > The problem can be seen easily if you save the image in the > JPEG format, because the preview will show an area that does > not match what should be visible (the offset for the preview > is <0,0>). > > This is a strange bug, because I was only able to reproduce > it if I load the image from the File->Open dialog, not if I > load it from the list of recent documents (why is there a > difference?). > > Also, the crop tool should be the first thing that you use > on the image and you should crop by clicking in the middle > of the selected area, not by pressing the "Crop" button. > If you crop, then undo, then crop again, then the operation > is performed correctly and the bug cannot be reproduced. > Same if you perform any other operation (color correction, > any filters, ...) on the image before cropping. > > So this only happens in the sequence Load-Crop-Save. Very > strange... > > To add to the confusion, the thumbnail that is saved with > the image (in .xvpics/*) shows the cropped version! This > means that if you look at the thumbnail, you will think that > everything went fine but the image does not match the > thumbnail. > > I was affected by this bug because I had to crop a large > number of images, so I used the sequence Load-Crop-Save very > often. It is only when I was halfway through that I > reloaded one of the images and I saw the problem. I had to > re-open all images one by one (because I could not trust the > thumbnails), crop them again, and flatten before saving in > order to be sure that everything would be OK. > > -- > > > -- How to repeat: > - Open an image using File->Open. > - Use the crop tool to select an area in the middle of the > image. > - Click in this area to crop the image. > - Save the image in any format (if you select JPEG, you will > see that the preview is incorrect) > > -- > > > -- Other comments: > > -- ------- Additional Comments From quinet@gamers.org 2000-09-22 03:56:35 ---- Subject: Re: [gimp-bug] Load, Crop, then Save results in original (not cropped) From: quinet@gamers.org (Raphael Quinet) To: 25266@bugs.gnome.org Message-Id: <200009220756.JAA04748@chapelle.eed.ericsson.se> Date: Fri, 22 Sep 2000 09:56:35 +0200 (MET DST) [I am re-sending this separately to 25266@bugs.gnome.org because sending a message to two addresses at the same time (25266 and 23610) does not work as expected and both copies are attached to the same report (23610 in this case). So even the bug reporting system has bugs...] [Additional details about #25266: the bug in the crop tool causes the canvas to be resized without cropping the layer (sometimes!). You can see the problem when you save the image (because of the Save bug described in 23610) but you can also be affected by the bug in other operations. For example, if you try Image->Colors->Levels->Auto after trying to use the crop tool, then you will get a different result than if the image had been cropped correctly. I noticed that several times and now I flatten the image after cropping it, just in case.] On Wed, 20 Sep 2000, Austin Donnelly <austin@gimp.org> wrote: > On Wednesday, 20 Sep 2000, quinet@gamers.org wrote: > > If you load an image (containing one or several layers) and > > the first operation that you do on this image is to crop a > > part of it with the crop tool, then the canvas is resized > > but the layers do not seem to be affected. If you then save > > the image without flattening it first, then the original > > layers are saved, ignoring the area that should have been > > cropped. > > This bug (or one very similar to it) is also present in gimp 1.0.4, > and already has a bug open on it: see bug report #23610. I can > reproduce that bug on 1.0.4 and 1.1.25, so I expect yours will fall > into the same category. I don't think that the two bugs are really related. Bug #25266 is related to a strange behaviour of the crop tool that only happens if cropping is the very first operation that you perform on an image. I cannot reproduce the bug if I do anything on the image before cropping it, or if I create a new image instead of loading one from disk (and even then, it depends on how you load the image). See the bug report for other strange details about that bug. It smells very much like uninitialized memory or something like that. Bug #23610, on the other hand, happens in a consistent way and is related to a design problem in the File->Save plug-ins. There is nothing random about it, and the problem can be explained very easily (if I am not mistaken). The problem is that the file plug-ins that only support a single layer will not trigger the "Export" feature when they are told to save an image that contains only one layer. The plug-in uses only the current drawable (layer) and ignores the canvas size. Most file plug-ins (except for PNG) ignore the layer offset as well. As a result, what gets saved in the file is the whole layer, even if only a part of it should be visible through the canvas. This problem is also described in bug #25272: the thumbnails are generated from the visible area, not from what gets saved, so the result is even more confusing. So the real problem of bug #23610 is that the File->Save plug-ins should compare the canvas size with the layer size and also check if the layer offset is <0,0> before attempting to save the layer. If they do not match, then only the visible part of the layer should be saved. Another solution (at least for Gimp 1.1.x) would be to trigger the "Export" option when the Gimp (main app) detects a mismatch in the layer size or offet. Flattening the image as part of the export process would solve the problem described here. The results are interesting with a PNG image, because the plug-in (in version 1.1.25) checks the layer offsets but ignores the canvas size. Try this for example: create or load an image in which all parts of the image can be easily identified (so that you can see if any offset is applied). Then resize the image to make it smaller, and move the layer so that you only see some area near the middle of the original image. Now save it as PNG, and load the result. You will get an image that has the original size because the layer size was used instead of the canvas size when saving, but parts of the layer will be out of the visible area because the offsets were saved in the PNG file. The other file plug-ins ignore both the canvas size and the offset, so it looks like no resizing occured. Hmmm... Now that I think about it, there is also a problem if you set the opacity of the layer to something less than 100%. What you see is a partially transparent layer, but what is saved is the fully opaque layer. This is another aspect of the problem of saving a layer as if it was isolated instead of considering all attributes of the image. So IMHO the bugs #23610, #25266 and #25272 have three separate causes even if they seem to be related: - #23610 is a problem in the file plug-ins. A workaround would be to use the Export option even on single-layer images, if the canvas size does not match the layer size or if the offets are non-zero. - #25266 seems to be a problem with the crop tool, although the exact cause is still a mystery to me. - #25272 is a problem in the way the thumbnails are generated. It is affected by #23610, but can also be caused by other means (e.g. if a channel mask is active). -Raphael ------- Additional Comments From sjburges@gimp.org 2000-09-22 17:29:22 ---- Subject: Possible Explanation From: Seth Burgess <sjburges@gimp.org> To: 25266@bugs.gnome.org Message-Id: <20000922212922.A22189@sjburges.dyndns.org> Date: Fri, 22 Sep 2000 21:29:22 +0000 Raphael, Did you check that the crop mode did not get stuck in "resize" mode? It has a habit of doing this at rather inopportune times. Regards, Seth Burgess sjburges@gimp.org ------- Additional Comments From quinet@gamers.org 2000-11-07 03:33:29 ---- Subject: Re: Possible Explanation for bug #25266 From: quinet@gamers.org (Raphael Quinet) To: 25266@bugs.gnome.org Message-Id: <200011070833.JAA16702@chapelle.eed.ericsson.se> Date: Tue, 7 Nov 2000 09:33:29 +0100 (MET) On Fri, 22 Sep 2000, Seth Burgess <sjburges@gimp.org> wrote: > Did you check that the crop mode did not get stuck in "resize" mode? It > has a habit of doing this at rather inopportune times. I think that your explanation was correct. In 1.1.25, the crop tool was apparently using the "resize" mode if this was the very first operation performed on an image. For some reason, performing any other operation on the image before cropping it did also reset the crop tool to the "crop" mode as expected. I haven't been able to reproduce this problem with 1.1.26 or 1.1.29, but I have only tried a couple of images. I don't know if the bug is fixed or if it has moved elsewhere (this could be hard to check if it is related to some uninitialized memory problem). If anyone who worked on the code recently (after 1.1.25) is confident that the bug is fixed and not simply hidden, then this bug report can be closed. But looking at the log of app/crop.c does not show any significant changes done after August, so I suspect that the bug could still be in the code. -Raphael <quinet@gamers.org> ------- Additional Comments From sjburges@gimp.org 2000-11-08 15:22:04 ---- Subject: Assuming modifier stuck is the problem From: Seth Burgess <sjburges@gimp.org> To: 25266-close@bugs.gnome.org Message-Id: <20001108202204.C1939@sjburges.dyndns.org> Date: Wed, 8 Nov 2000 20:22:04 +0000 Sorry to repeat a mail to you, I'm just gonna go ahead and assume it was resize that was the problem. If you find otherwise, please let me know and reopen this. Seth ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 11:00 ------- This bug was previously known as bug 25266 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=25266 Originally filed under the gimp product and general component. The original reporter (quinet@gamers.org) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, egger@suse.de.