GNOME Bugzilla – Bug 23610
Resizing seems to work but the saved image still has old dimensions.
Last modified: 2009-08-15 18:40:50 UTC
Package: gimp Version: 1.0.4 Name........: Carl-Johan Kjellander Email.......: carljohan@kjellander.com Platform....: Dual Celeron PC, Linux 2.2.x GIMP Version: 1.0.4 GTK Version.: RedHat 6.1. don't know which. WM/Version..: Window Maker 0.61.0 -- Other system notes: -- -- Problem description: I have a png image which is 800x654. I resize it to 800x600 and save the file. when I open it again (in gimp or any other program) it is still 800x654. -- -- How to repeat: Open a picture in gimp. Resize it. Save it. Open it again. Still the old size. -- -- Other comments: -- ------- Additional Comments From quinet@gamers.org 2000-09-21 11:29:12 ---- Subject: Re: [gimp-bug] Load, Crop, then Save results in original (not cropped) image being saved From: quinet@gamers.org (Raphael Quinet) To: 23610@bugs.gnome.org, 25266@bugs.gnome.org Message-Id: <200009211529.RAA12119@chapelle.eed.ericsson.se> Date: Thu, 21 Sep 2000 17:29:12 +0200 (MET DST) 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 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 quinet@gamers.org 2000-09-21 11:29:12 ---- Subject: Re: [gimp-bug] Load, Crop, then Save results in original (not cropped) image being saved From: quinet@gamers.org (Raphael Quinet) To: 23610@bugs.gnome.org, 25266@bugs.gnome.org Message-Id: <200009211529.RAA12119@chapelle.eed.ericsson.se> Date: Thu, 21 Sep 2000 17:29:12 +0200 (MET DST) 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 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 ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 11:12 ------- This bug was previously known as bug 23610 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=23610 Originally filed under the gimp product and general component. Unknown version 1.0 in product GIMP. Setting version to the default, "unspecified". The original reporter (carljohan@kjellander.com) 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.
Try again with GIMP 1.2.1 and file a new bugreport if necessary (shouldn't though).
This bug is still open in the current version of the Gimp. I wrote a more detailled bug report that explains the problem a bit better, so I am marking this old bug as a duplicate of the new one (#51114).
*** This bug has been marked as a duplicate of 51114 ***
I tried to repeat the bug with gimp-1.2.1. -open a 800x654 image -resize the canvas to 800x600 -save the image. When saving a window popped up and informed that the image would be cropped. The resulting image was 800x600 as expected. Good work. Keep working on #51114.
The fix for bug #51114 was part of the stable release 1.2.3. Closing this bug.