On Fri, 13 Jul 2007 01:23:39 +0200, Raphaël Quinet <raphael@xxxxxxxx> wrote: > On Thu, 12 Jul 2007 23:29:01 +0200, gg@xxxxxxxxxxx wrote: >> If there is an image specific value you do not need a default. >> "overriding" a default with an image-specified value is a contradiction. > > This reminds me about something that should be clarified... For all > these parameters that affect how an image is saved, where do these > various values and defaults come from, and how to name them? > > I propose the following terms (feel free to propose something else if > you have better ideas): "default", "original" and "current" values. > This is a slightly expanded version of the comment #14 that I added to > bug #63610 in 2003; in that comment I forgot the "original" setting. > > 1) The "default" setting is the one that is hardcoded or configurable > in GIMP or in one of its plug-ins. Sometimes the "default" value > can be empty or not set. Some examples: a default image comment > can be configured in the Preferences, the JPEG plug-in uses a > default quality setting of 85, GIF does not interlace the file by > default, etc. The "default" setting applies to all images. > > 2) The "original" setting is the one that is found (or not) when an > image is loaded from disk. For example, an image file may include > a user comment and this comment will be preserved when the file is > saved later. The "original" setting only applies to that specific > image. > > 3) The "current" setting is whatever is currently associated with one > specific image. Once it is set (coming from the "default" or > "original" setting), it will always be used whenever this image is > saved. It can usually be changed by the user in the dialog window > of the file plug-in. > Thanks for formalising all this. I had though about how this issue affects other paramaters but did not dare further confuse that enormous thread with side issues. Does "current" need to be saved as a third option? It is either equal to default or original unless it is set during a save in which case it become the new value of original. Are you suggesting the truely original settings are retained after a save with different values? If so how long? End of session perhaps. Ah yes , I've just realised there are many of these extended settings that are not set in the save dlg so there is a real need for your third option. > In theory, these parameters should work like this: all new images or > images loaded from disk get the "default" setting except if some files > have an "original" setting, which is then used instead of the default > one. This then becomes the "current" setting, which is associated with > that image every time it is saved. > > In practice, there are several exceptions due to implementation > details or leftovers from the past. For example, the "current" setting > may not actually exist until the file is saved (it only exists once > the save plug-in creates it). > > But there is a bigger problem that I mentioned in bug #63610. There > is a confusing historical feature that introduces another source of > settings for some parameters: > > 4) The "session" setting is a side-effect of the fact that file > plug-ins currently behave like other plug-ins (filters). This is a > value that is set the first time you save a file in a specific > format and that will affect all other images that you save during > that session (until you quit GIMP). This behavior is appropriate > for filters but is confusing and dangerous for file plug-ins. > > The problem with "session" settings is that something that is changed > when saving one image can trigger unexpected changes in all other > images. For example, you use Save As to save an image using lower > quality settings for testing, but you do not see that from then on, > all other images that you save (normal Save) in the same format will > also use that lower quality instead of using the default value. > Yes , as already noted in the other thread, this is an aboration leading to unexpected and irrational results. Session settings should probably now be dropped as you say for Save plugins. The function of these plugins is fundamentally different from filters and thier role is so essential that they merit a different interface if that is necessary. > IMNSHO, the right way to fix bug #63610 is to provide an easy way for > all file plug-ins to save and reload one or more sets of "default" > values and then forbid all file plug-ins from using "session" settings > (save_args or save_vals or whatever the array of saved GimpParamDef is > called in each plug-in). In fact, removing the usage of session > settings could already be done right now in all file plug-ins, even > before having a nice library for file plug-ins that would provide a > unified way to save and load default values. > > This would solve one of the problems that has started this long thread > about the JPEG quality factor: saving one image in low quality will > not cause other unrelated images to be also saved in low quality. The > other improvement that can be implemented without waiting is to read > or compute the "original" quality from JPEG files and to use it if and > only if it is better than the "default" quality. I'm not sure about the ifing and butting. I think the program should work in one predictable and consistant way. There is also in problem artificially altering this value if it is "better". That is subjective. A numerically higher jpeg_quality value is not better if you dont want you file to suddenly get huge next time you save it (obstencively without changing anything.) I think default values should be used only _by default_ , ie when no other value is available as you outlined at the top. If there is a perceived need to force these values (and that seems to be the main difference of option here) then perhaps the dlg for setting the user defined defaults should have an option "force these settings for all jpeg images". This defaults to false, so the user who sets default parameters has to actively select the forcing and takes legal repsonsabilty for the resulting bloat/degradation trade-off. That satisfies those who want to define across the board behavoir at the same time as providing a gimp jpeg save that does nothing more than is asked of it: save the image as it was loaded unless the user intervenes. To me this seems to be the only proper way to handle it. A Save should not be trying to do a furtive SaveAs. > I am working on a > simple extension of the nice patch that Tor provided a few days ago. > > -Raphael > Thx, gg/ _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
