GNOME Bugzilla – Bug 25272
The thumbnails do not always match the image.
Last modified: 2006-11-06 08:48:27 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: -- -- Problem description: The thumbnails (.xvpics) are generated from the visible layers of the current image, but this may be totally different from the contents of the saved file. This can be very dangerous if you do not notice that a channel mask is active when you save your image as JPEG, TIFF, PNG or other formats because the mask is saved instead of the layers but the thumbnail shows the correct image. If you trust the thumbnail without reloading and checking the saved image, then you may loose your work without knowing what happened (it almost happened to me on a 5000x6000 PNG image). Here are some cases in which there can be a mismatch between the thumbnail and the image: - A channel mask is active. Most file formats (JPEG, GIF, PNG and others but not XCF) will only save the mask as a grayscale image and will ignore the layers. - The current layer has a non-zero offset. The thumbnail will only show the visible area, but some file formats (e.g. JPEG) will save the full layer and ignore the canvas size and the offsets. - The image has multiple layers and you only save one of them (in the "Export" dialog, choose "Ignore" when you are asked to flatten the image). The thumbnail shows the visible image (with all layers) instead of showing only the layer that is saved. There may be some other cases, but I only tested the ones described above. -- -- How to repeat: - Open an image or create a new one and draw something in it. - Select some area of the image. - Use Select->Save To Channel. - Save the image as JPEG, GIF, TIFF, PNG, or any other format that saves only the current drawable. What gets saved is the channel mask, not the image. But the thumbnail shows a preview of the full image, so you might think that you saved your image correctly. You can reproduce similar problems by resizing the canvas and changing the offset of the layer, or by creating an image with multiple layers and saving only the current layer. -- -- Other comments: -- ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 11:00 ------- This bug was previously known as bug 25272 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=25272 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.
I have created a more detailled report of the problems with the File->Save plug-ins. It is available in bug #51114. The bug with the thumbnails is a consequence of that other bug. The thumbnails show (more or less) what the user sees, but the plug-ins save something different. The only thing that is not covered by #51114 is this: - Create or open an image with multiple layers. - Save as PNG, TGA, JPEG or any image format that triggers the Export feature. - Choose "Ignore" in order to save only the current layer. - The image will contain only the current layer, but the thumbnail will incorrectly show the whole image.
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Contrary to what I wrote above, solving bug #51114 does not solve the problems with the thumbnails: if you save a layer mask or a channel instead of a regular layer, the thumbnail will still show the contents of the image (visible layers) instead of showing the real contents of the file. This can be really confusing. Besides, selecting "Ignore" in the Export dialogs (any of them) will also generate incorrect thumbnails. This bug is caused by the fact that the thumbnails are generated by the core (main gimp app) instead of being generated by the plug-ins. The function gimp_image_construct_composite_preview in app/gimpimage.c has no way to know if the save plug-in supports layers (if it will save the whole image or only the active drawable) or if the Export dialog was called (and whether the user selected Export or Ignore). Adding a new PDB function that would be called by all file_save plug-ins to generate the thumbnails could solve this problem. This function would be called by the plug-ins after gimp_export_image(). It would also be called in app/fileops.c from the Open dialog if the user wants to (re-)generate a thumbnail (the problems described above do not exist when loading an existing file, so the thumbnails can be created within the core). This would require all file_save plugins to be modified. I think it should be done for 1.2.x, but if you disagree you can set the target milestone to 1.3.x.
This is really hairy to fix and won't be done for 1.2, setting the target milestone to 1.3.x
Optimistically setting milestone to 2.0. Seems to me like the best way to fix this is to delegate thumbnail generation to a plug-in, and have that plug-in called for every save. I think that solves the problem more or less... Anyway, it should be looked at before the stable release. Dave.
This is dependent on the thumbnail API - marking this as a dependency of bug #113033. Dave.
Even when libgimpthumb would be available, this problem is still not easy to solve; moving to the 2.2 milestone.
It would seem that there is really only one way to *guarantee* that the thumbnail matches the file, and that is to load the file after it has been saved, and create a thumbnail from the result (i.e., do what the File Open dialog does when no thumbnail exists). This would of course take a lot of time potentially, but I wonder whether it could be done by a background thread, so that the user would not notice it so much?
No, it is not necessary to reload the file after saving it. That would be a waste of resources, especially if the image is very large (even as a low-priority background thread, the user would notice the performance hit due to disk access). Even though the GIMP has changed a lot in the last three years, the comments written in 2001 are still valid. Please re-read the comments above: this problem could be solved by delegating the thumbnail generation to the save plug-ins (no need to reload), potentially by using a dedicated PDB function that saves the thumnail automatically once the plug-in has generated it. Another way to solve this problem would be to generate the thumbnails in the core as this is done now, but make the core aware of any options that affect what part of the image is saved (mainly the choices made in the Export dialog). This could be done if some export features are moved into the core (see bug #119545) but may not be perfect if some options that could be selected in the plug-in's save options (after optional exporting) can affect the image in a significant way. IMHO, the best solution is to move the thumbnail creation to the save plug-ins and to provide some PDB calls or some new functions in libgimp to make this as easy as possible.
If the plug-ins do the thumbnail saving, what use is a PDB interface then? libgimpthumb also provides everything a plug-in needs to create thumbnails. The plug-in "just" needs to create a pixbuf of the appropriate size. The problem is however that for quite a few file formats even the file save plug-in doesn't know what the image will look like that it is saving. So the only perfect solution is indeed to open the newly created file and create the preview from that.
Using libgimpthumb would be a solution. I thought that it would be better to leave that to the core so that the plug-ins would not be required to link with this library and the core would be a better place to check user preferences and other policies that could evolve with future versions of the GIMP. But doing it all in the plug-ins could also make sense. As to what is "perfect", I think that the problem of not knowing exactly what is saved would not be a big issue. This could affect the plug-ins that rely on a third-party library, but only if the library transforms the image in a significant way without providing adequate feedback about what was changed. From my point of view, reopening the files is not an acceptable solution if the files are large (say, twice the size of the RAM). Letting the save plug-in generate the thumbnail would provide a solution that is fast and "good enough".
What is bad about the plug-ins linking with libgimpthumb? After all that's exactly why this code has been moved from the core to a library. If there are preferences to check then we need to introduce an API to do that.
OK, here's what we can do easily. It can even still go into 2.2 since basically everything is in place: When saving a file, don't write the thumbnail using the internal image preview. Instead have a look at the file-size of the saved image and if it is smaller than the configured thumbnail-filesize-limit, then try to load the file we just saved and create the thumbnail from the loaded image. The Open dialog shows that this is reasonably fast. We also now have the framework in place that allows us to make sure that no progress or message dialogs pop up while we are loading the image. Unless the filesize-limit is set to an insanely large value and the file is actually large, the user won't even notice.
The approach I outlined above has the drawback that no preview thumbnail will be available for images we can't read or for images that are larger than the configured filesize limit. For these images there would be no preview in the Document History and in the recently-used menu. We would at least have to special case the XCF file format. For XCF the image preview is always the right preview and the thumbnail should always be saved. Would that be a reasonable compromise?
Moving from the 2.2 milestone to Future. It's too late for such a change now.
*** Bug 339370 has been marked as a duplicate of this bug. ***
*** Bug 365257 has been marked as a duplicate of this bug. ***
Now fixed in CVS. We don't store thumbnails any longer when saving a file, but we still generate a preview when loading one and also from the File Open dialog. There's an exception to this rule: Since we know that the preview and meta information is correct for XCF files, we store a thumbnail when saving as XCF (or compressed XCF). 2006-11-05 Sven Neumann <sven@gimp.org> * app/file/file-save.c (file_save): only save a thumbnail if we are saving as XCF. Fixes bug #25272. * tools/pdbgen/pdb/fileops.pdb: create a libgimp wrapper for the "gimp-file-save-thumbnail" procedure. * app/pdb/fileops_cmds.c * libgimp/gimpfileops_pdb.[ch]: regenerated. * plug-ins/common/compressor.c (save_image): ask the core to save a thumbnail for compressed XCF files.