GNOME Bugzilla – Bug 101901
guillotine save is cumbersome
Last modified: 2004-09-15 10:56:44 UTC
Saving image pieces created by chopping up a larger image via guillotine is very time consuming. The user is always required to type in a name for each piece as the suggested name is always illegal and cannot be saved as is. The guillotine operation should choose sensible file names on its own and complete without prompting the user for anything.
The first step to solve this bug would be to use a sensible filename: cutting up a Picasso picture results in something like picasso.jpg-(0,1) It would make more sense to have picasso-(0,1).jpg instead. This is the easy part. Completing the saving without user interaction could be more problematic: for example when you save as jpeg you have to enter the compression level, etc. This again is something you don't want to do 100 times when you cut up a picture in 100 little pieces :)
The script could be extended by offering a selection of file formats that are likely to be used on the web, in a drop-down list like this: - do not save the images (current behavior) - PNG true color (RGB) - PNG indexed - JPEG high quality - JPEG medium quality - JPEG low quality - GIF Each of these options would have reasonable values for the other parameters of the file formats (JPEG qualities could be 90%, 75% and 60%). It would also flatten the images and convert them to indexed mode with the default options. If the user wants more control, then there would still be the opportunity to choose the current behavior: do not save the images. Below the drop-down list, there would be a checkbox "Close the images after saving". This could be useful if the default settings are fine and the user is only interested in getting the files and does not want to edit them anymore. Note that I almost never use the images produced by the guillotine plug-in directly: I always spend some time minimizing the number of colors in the palette for each slice so that I can reduce the size of each image. So these enhancements to the plug-in would not be very useful to me, although they would certainly be useful to some users.
Sounds good. Regarding your last paragraph I'd like to add that even though a user might desire the automatic saving of slices that does not neccessarily mean the slices would not be processed further, they simply might not be processed manually via Gimp. ImageMagick has an impressive array of command line tools that allow you to do many repetitive things in batch mode. For instance, replacing 1 or 2 pixel colors to create highlight effects for a fake image map. As terrific a tool as Gimp is I know of no way of doing this in batch mode via Gimp. And even if there is I doubt it would have the ease and convenience of ImageMagick's command line tools (Gimp's scrip-fu is a mess IMHO). The proposed enhancements certainly wouldn't hurt any current users of the guillotine functionality, but they would tremendously help anyone who plans to process the slices post-Gimp via some batch operation.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
better suggested filename: > picasso-(0,1).jpg it is a small point but I want to recommend against using parenthesis in the filename, as they dont really add anything. I would recommend like this. picasso-001.jpg picasso-002.jpg picasso-003.jpg ... picasso-999.jpg guillotine should be able to work with only (an improved version of) the generic Save dialog. Ideally the PNG options and things such as JPEG quality would be dealt with elsewhere in a generalised way rather than specific to the Guillotine. (In response to another feature I posted to the devel list suggesting how this this might be done). Could the naming problem be fixed in time for 2.0? (easy-fix?) It seems to be the biggest part of the problem.
Created attachment 30049 [details] [review] adding the coordinates before the extension This patch adds the -(x,y) coordinates before the file extension. It seems to work fine for me, but as this is actually my first real patch for GIMP, I'd rather have someone else review it.
Comment on attachment 30049 [details] [review] adding the coordinates before the extension The patch looks OK to me, except for the file naming convention chosen. I agree that putting parentheses in a filename just doesn't feel right. Might I suggest file-x-y.ext? The change would be trivial, and if there's some agreement, I think this could be committed.
file-x-y.ext sounds good to me (perl-o-tine and py-slice use a flat number system more like i suggested so if I want a number scheme more like I suggested I can always use them instead).
Suggest still adding leading zeros to the numbers, to maintain file sorting order: file-01-01.foo file-01-02.foo file-02-01.foo file-02-02.foo etc.
Created attachment 30538 [details] [review] patch with added padding This patch adds the correct amount of padding to keep the sorting order.
You could save the maxpad variable and improve readability by writing: hformat = g_strdup_printf ("%%0%i", MAX (hpad, vpad)); When looking for the extension, it's probably better to use strrchr() than g_strrstr(). Whatever you use, you must not free the return value since it's a pointer into the buffer you passed as input.
Created attachment 30753 [details] [review] using MAX(), not freeing extension
System headers such as <string.h> should be included before libgimp headers (but after "config.h"). Please change that, then commit your change. Thanks.
Commited: 2004-08-19 Michael Schumacher <schumaml@cvs.gnome.org> * plug-ins/common/guillotine.c: modified the coordinate insertion into the file name to leave the file extension intact, changed the format of the coordinates. Fixes bug #101901.
*** Bug 152705 has been marked as a duplicate of this bug. ***