From: Sven Neumann <sven@xxxxxxxx> Date: Sun, 08 Jul 2007 15:12:03 +0200 On Sun, 2007-07-08 at 14:53 +0200, gg@xxxxxxxxxxx wrote: > Does your reply indicate you take a "this feature not a bug" > approach here and you think is the best way gimp should deal with > this situation? Indeed. When you open a JPEG file, then you have a decoded image. The settings that were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. Thus it is better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this. Think of the quality setting as an indication of expectations rather than a specific outcome. It may not be possible to get the exact same outcome (and obviously -- at least to us -- there's no way to retroactively "improve" the result), but the quality setting could be treated as the user's expectation for the result. It's certainly true that a couple of iterations of saving at a quality setting of 85 (say) will yield a substantial degradation, and a couple of iterations at 65 will yield even more degradation, but a couple of iterations at a setting of 98 won't yield very much degradation at all. By this reasoning, if a user opens a file with a quality setting of 98, her expectation when saving the file is that the quality will still be very high, while if the quality setting of the incoming file is only 85, her expectations will be lower. A single default setting won't cover all cases. If the choice really is that arbitrary (and you make a good argument to that effect), why not simply use the quality setting of the incoming file as the implied default? I think it would at least align better with user expectations, particularly for files shot at high quality settings on digital cameras. BTW, on the Canon S3, the Superfine, Fine, and Normal settings correspond to 96, 90, and 68 respectively. So anyone who shoots in one of those two settings and then decides to do a quick edit will get a rude surprise. -- Robert Krawitz <rlk@xxxxxxxxxxxx> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
