[Gimp-developer] Annoying behavior of shared settings for file save plug-ins
On Thu, 30 Aug 2007 11:07:40 +0200, Raphaël Quinet raphael at gimp.org wrote: On Thu, 30 Aug 2007 00:57:44 +0200, gg at catking.net wrote: Gimp should not decide what is better because it cannot know what is required so cannot make that choice. This sort of surprise behaviour is precisely the kind of thing I was warning against in making covert changes to user data. I think that you are trying to shoot the wrong target. The main problem that I described in my previous message is not the fact that GIMP tries to preserve the quality of the original image or decide what is better. The problem is that some changes that you make when saving one file are propagated to all other files that you save later. The recent updates to the JPEG plug-in make this problem more obvious, but it also affects all other file plug-ins. Before jumping to conclusions about where the problem comes from, please try the following exercise: - Load or create a GIF animation (2-3 layers should be enough). - Save it as A.gif and let's pretend that you don't like the speed at which that animation runs so you set the delay to 333ms and check the box Use delay entered above for all frames. - Close that image. - Open or create a new, totally unrelated GIF animation. - Save that image as B.gif. Although you probably wanted to keep its settings or at least save it with the default values, you see that Use delay entered above for all frames is now checked. The settings from an unrelated image that is now closed are used for saving your new image. If you do not want to destroy the timing of your animation, you have to pay attention and uncheck that box before you save the file. Does it make sense that two unrelated images influence each other? But things are even more confusing if you keep some images open. Try the following exercise, with PNG this time: - Load or create a new image. - Save it as A.png but set its compression level to 0 because you want to waste some disk space and disable all other options because you do not want to save the image comment, creation date, etc. - Keep A.png open and load or create another image. - Save the second image as B.png. Although you probably wanted to use your default settings (which can be customized with the buttons Load/Save defaults), you see that the same parameters as A.png are now used when saving this image. You do not like this, so you set the compression level back to 9 (you can also check or uncheck some of the other boxes) and save the image. - With both A.png and B.png still open, load or create a third image. - Save that image as C.png. Now you see that C.png inherited the settings from B.png, the last image that was saved. - Make some small changes to A.png and save it again using a new name such as D.png. By now, maybe you expect that saving D.png would use the same settings as C.png, the last image that was saved? But no, this time you see that D.png keeps the settigns from A.png because it was still open. - Now if you make some changes to B.png and give it a new name E.png, then that file will use the settings from B.png. But if you had closed and re-opened B.png, then you would see that E.png is saved with the parameters from D.png, not B.png. Are you confused yet? If you work on two files in parallel (A.png and B.png) and save them alternatively as your work progresses, then any new file that you open and save will inherit the settings from A.png or B.png, depending on which one was saved last. And if you are still convinced that all of this makes sense, try to play with some settings that are enabled or disabled depending on the contents of the original image. For example, if the original PNG image has transparency (alpha channel), then you will be able to check or uncheck the box Save color values from transparent pixels. This setting may be propagated to other PNG images that also have an alpha channel. But if you load a PNG image without alpha channel, then this option will not be available. After saving that last file, can you correctly guess if that box will be automatically checked or not when you load another PNG image with transparency and then try to save it? I consider the current situation to be broken for all file plug-ins. Instead of re-using the settings from whatever image was saved recently, each image should keep its own settings and should not be influenced by what you do with the other images. The save settings should come from the original image or from the user defaults if the image has never been saved yet. It should of course be possible for the user to customize these defaults (currently, this can only be done for JPEG and PNG, but the old bug #63610 is about extending this to other plug-ins). I hope that you are convinced that something is wrong with the behavior of the file plug-ins. Now, regarding the
Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins
On Thu, 30 Aug 2007 15:56:16 -0600, Scott [EMAIL PROTECTED] wrote: On Thu, Aug 30, 2007 at 08:56:33AM +0200, Jakub Friedl wrote: I think that use image file quality unless defaults are 'better' is not thee problem. Problem is inheriting image quality between different images in one GIMP session. I have a default quality of 85. Then I open DSLR image with quality 95. Save it with that quality. Then I open and save low quality cameraphone image. But I am not offered my default nor the original cameraphone quality (which would be both understandable) but the DSLR quality of 95. Huh? These images have nothing in common except they have been opened in the same editor session. Do not mix them up. There are times I definitely *want* to save the settings from a previous save. [...] If you want to save several images with the same settings, you can use the buttons Save defaults and Load defaults. We also have an enhancement request (bug #120829) about providing multiple presets that could be saved and re-loaded when necessary. I think that it is much better to require an explicit action if you want to re-use some settings from one image to the next, instead of always doing this automatically. Each image should have its own settings and should not be influenced by how you saved unrelated images in the same session. As in the example given by Jakub, it is annoying that the parameters used for saving a high-quality DSLR image are automatically re-used for saving a low-quality cameraphone image. This should definitely change for 2.6. But my question was about what kind of workaround can be implemented quickly for 2.4. It looks like it might be better to have all plug-ins broken in the same way instead of just fixing the most used ones, so that would be the second option that I described in my previous message: ignore the settings from the original JPEG images and always re-use the parameters from the last saved image. This is bad, but at least this is consistent with other file plug-ins (until they can all be fixed). -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins
Rather strange conclusion from my POV - if something very convenient cannot be provided for each and every case, it shouldn't be provided at all. I can prove my opinion with a case with healing brush. It saves me a lot of time and efforts during photo retouching despite the fact it doesn't support healing along a path. Raphaël Quinet wrote: This should definitely change for 2.6. But my question was about what kind of workaround can be implemented quickly for 2.4. It looks like it might be better to have all plug-ins broken in the same way instead of just fixing the most used ones, so that would be the second option that I described in my previous message: ignore the settings from the original JPEG images and always re-use the parameters from the last saved image. This is bad, but at least this is consistent with other file plug-ins (until they can all be fixed). -Raphaël -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins
Date: Fri, 31 Aug 2007 17:39:45 +0200 From: =?UTF-8?B?UmFwaGHDq2w=?= Quinet [EMAIL PROTECTED] If you want to save several images with the same settings, you can use the buttons Save defaults and Load defaults. We also have an enhancement request (bug #120829) about providing multiple presets that could be saved and re-loaded when necessary. I think that it is much better to require an explicit action if you want to re-use some settings from one image to the next, instead of always doing this automatically. Each image should have its own settings and should not be influenced by how you saved unrelated images in the same session. As in the example given by Jakub, it is annoying that the parameters used for saving a high-quality DSLR image are automatically re-used for saving a low-quality cameraphone image. This should definitely change for 2.6. But my question was about what kind of workaround can be implemented quickly for 2.4. It looks like it might be better to have all plug-ins broken in the same way instead of just fixing the most used ones, so that would be the second option that I described in my previous message: ignore the settings from the original JPEG images and always re-use the parameters from the last saved image. This is bad, but at least this is consistent with other file plug-ins (until they can all be fixed). It sounds like what's happening is something like this: 1) Current JPEG quality setting is 85 2) User selects Use quality settings from original image if original image is better 3) Original image has quality setting of 98 4) User saves image 5) Now the current JPEG quality setting is changed to 98 Is that correct? If so, then (5) seems wrong to me. The JPEG plugin should remember that the current JPEG quality setting is 85, and that the user has selected Use quality settings from original image. If the user then saves another image that has a quality setting of 60, it shouldn't be saved at 98, but at 85. My own preference is to err on the side of caution; I'd rather make a mistake of saving at too high of a quality (which loses less information) than too low. If I accidentally save a thumbnail at quality 98 or 100, all I've done is wasted a little disk space; if I save a good image at 85, I've lost a lot of data. Yes, I know that I shouldn't save a master copy of an image as a JPEG, and I don't intentionally. But I'm human and occasionally make mistakes... -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins
On Fri, 31 Aug 2007 12:24:47 -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: It sounds like what's happening is something like this: 1) Current JPEG quality setting is 85 2) User selects Use quality settings from original image if original image is better 3) Original image has quality setting of 98 4) User saves image 5) Now the current JPEG quality setting is changed to 98 Is that correct? Almost. Step 2 currently happens automatically if the quality of the original image is better than the defaults (because of the complaints that gimp was destroying the quality of some images without warning). But this may change, so step 2 could again require an explicit action from the user. If so, then (5) seems wrong to me. [...] Yes, this is exactly what I tried to explain in my previous messages. The problem is that the JPEG plug-in and most other file plug-ins will automatically re-use all settings from the last file that was saved. My own preference is to err on the side of caution; I'd rather make a mistake of saving at too high of a quality (which loses less information) than too low. If I accidentally save a thumbnail at quality 98 or 100, all I've done is wasted a little disk space; if I save a good image at 85, I've lost a lot of data. And this is what is currently implemented: if the quality level of the original image is higher than the current default value, then the quality from the original image will be selected automatically. But since the JPEG plug-in shares the same behavior as the other file plug-ins, this new value is automatically remembered for the next time you save an image. The combination of these two things (using the original quality if it is higher, and the automatic re-use of the last values instead of using the defaults) causes the problem reported by Jakub: if you load and then re-save many images that were saved at different quality levels, you end up with the last image saved at the highest quality level (maximum value from all images), which may be much higher than the default value or than the original quality of that image. This is a bug that should be fixed. But after discussing this briefly with Simon in #gimp, I think that it would be better to postpone the real fix to GIMP 2.6 because it would not be possible to fix all (or even most) file plug-ins for 2.4. And if only the JPEG plug-in (and maybe PNG) behaves differently than other plug-ins, then some users will probably complain or at least be confused. It may be better to postpone the real fix until all plug-ins support a way to load and save defaults, and maybe support multiple presets. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where all developers are?
Hi, i'm not a developer but i'm using gimp since ten years (nearly the early days). It is true that there are now many applications. Just think of : - those photo organizer such as F-Spot or digikam+ShowFoto, which are made for we, good fathers - more cool apps (you mention panos like Hugin), but not only - More specific application does much job too : think of Ufraw : if you are just a photographer and want clean photos : that's enough for you. Ok not many photo retouching program, but krita is here. An also, i've to apologize, i'm beginning myself using ... Blender... even for photo-retouching and compositing, even if it is not its main purpose (if some want to work on this, i think it is only huge what possibilities you get with their node editor) I think that now the image processing is maturen mroe specific applications are sucking some good contributor, and user too. But also, i have already made some changes to Scribus or Inkscape code, never understood anything to Gimp's. Gimp is not to blame, but i can guess some developer are also lost this way. And it is sometimes hard to find explanation. You when you begin, it's hard to enter so many code lines, especially for a beginner. I hope it is a beginning of answer. pygmee Last I mailed it was said that there are not that many GIMP developers. Where are all image processing application developers have gone? Is there some other open source image manipulation software which sucks all the developers? In recent years Siggraph conference proceedings have had more image processing papers. For example: They are now making giga size photos with panoramic techniques. They are using hundreds of tourist photos for making 3D walkthroughs through city. Google earth and competitors are making 3D models from photos. And much more. It looks like today's image processing software needs to be redefined because there are many new applications for photos. You may suggest some other application for specific task as an easy solution but please don't. Juhana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where all developers are?
Nope Radar, Gimp is under important internally changes - most of the actual limits are not from developers minds but from actual toolkit limitations. They work hard to introduce for next GIMP versions a new engine which will make possible a lot of new posibilities. This mean they have to rewrite almost all code in benefit of us. They can't work on 5 directions on the same time. When this work will be done Editing, Photo Manipulation, CMYK and PDF printing and exporting, ... all of these will be some of the last problems about we will complain. They also command some UI researches for the optimal GUI redesign. They are pour et simple too busy right now to introduce new features - that you may see on LightZone or RawTherapee - on the actual (older) codebase. Well, I hope you understand now - the future is not gray. Sorin [EMAIL PROTECTED] wrote: Hi, i'm not a developer but i'm using gimp since ten years (nearly the early days). It is true that there are now many applications. Just think of : - those photo organizer such as F-Spot or digikam+ShowFoto, which are made for we, good fathers - more cool apps (you mention panos like Hugin), but not only - More specific application does much job too : think of Ufraw : if you are just a photographer and want clean photos : that's enough for you. Ok not many photo retouching program, but krita is here. An also, i've to apologize, i'm beginning myself using ... Blender... even for photo-retouching and compositing, even if it is not its main purpose (if some want to work on this, i think it is only huge what possibilities you get with their node editor) I think that now the image processing is maturen mroe specific applications are sucking some good contributor, and user too. But also, i have already made some changes to Scribus or Inkscape code, never understood anything to Gimp's. Gimp is not to blame, but i can guess some developer are also lost this way. And it is sometimes hard to find explanation. You when you begin, it's hard to enter so many code lines, especially for a beginner. I hope it is a beginning of answer. pygmee Last I mailed it was said that there are not that many GIMP developers. Where are all image processing application developers have gone? Is there some other open source image manipulation software which sucks all the developers? In recent years Siggraph conference proceedings have had more image processing papers. For example: They are now making giga size photos with panoramic techniques. They are using hundreds of tourist photos for making 3D walkthroughs through city. Google earth and competitors are making 3D models from photos. And much more. It looks like today's image processing software needs to be redefined because there are many new applications for photos. You may suggest some other application for specific task as an easy solution but please don't. Juhana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where all developers are?
[EMAIL PROTECTED] wrote: Ok not many photo retouching program, but krita is here. An also, i've to apologize, i'm beginning myself using ... Blender... even for photo-retouching and compositing, even if it is not its main purpose I don't know why you would have thought of even trying to use Blender for photo-retouching. It isn't designed for it and its steep learning curve tends to put some people off it. If you are using it more as a compositing tool (due to its node editor), you will probably like GEGL. You will probably like GIMP even more when GEGL is integrated in to it. -- Cheers! Kevin. http://www.ve3syb.ca/ |What are we going to do today, Borg? Owner of Elecraft K2 #2172 |Same thing we always do, Pinkutus: | Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
