On Thu, 30 Aug 2007 11:07:40 +0200, Raphaël Quinet <raphael@xxxxxxxx> wrote: > On Thu, 30 Aug 2007 00:57:44 +0200, gg@xxxxxxxxxxx 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 JPEG plug-in, I see two ways forward: > > 1) Do not re-use the values from previous (unrelated) invocations of > the plug-in. This ensures that each file keeps its own settings, > as described above. The same fix can also be applied to the PNG > plug-in because it uses similar parasites for saving image settings > and it also has the "Load/Save defaults" buttons. But other > plug-ins will still have the wrong behavior because it is too late > to fix all of them before 2.4. > > 2) Instead of trying to fix the plug-ins for 2.4, make sure that they > are all broken in the same way. This would mean that the JPEG > plug-in in 2.4 will not try to use the quality settings from the > original image even if they are better than the defaults. We would > go back to the previous behavior and postpone the real fix > explained above until the next development cycle. Those who > complained that GIMP was "destroying" their images by saving them > at a lower quality than expected will just have to wait for 2.6. > > I don't care about which way we go. Both of them have good and bad > sides and both of them will leave some users frustrated or confused. > > -Raphaël > _________________ Well I dont think I was completely missing the target but I had not realised the broader issue. The jacking up of "jpeg quality" factor is a result of both the carry over policy and the "use if better" policy. 1) would seem to be by far the better of your two options since the destructive effects in current release are pretty unacceptable. If jpeg and png can work coherently that would be 80% of the problem solved with other plugin formats being brought into line soon after. It would be a great shame if this long awaited 2.4 release went out with the old destructive behaviour and missed all the fixes you have done recently. regards, gg. _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
