On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote:
>> Does your reply indicate you take a "this feature not a bug" approach
>> 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.
I'm sorry I find that a rather forced logic. As we have seen the image
will not be _identical_ due rounding errors and such , that does not make
the existing choice of jpeg_quality "irrelevant". It represents the users
choice of size/quality trade-off.
I see no justification to discard that choice as irrelevant.
File | Save should save the image as it is. Save_As is there as a means to
Gillermo's real world example where the file size shrank by a factor of
two and the quality took a serious hit can hardly be described a
straight-forward save. It's doing a major change to the image and changing
the compression parameters (quality and sampling_factor!), this should
only happen through the Save_As with a full dlg.
> 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
Allowing the user for redefine the default is fine but I see no bearing on
this issue. This is not a lifestyle choice it's a per image choice. It's
irrelevant to this discussion.
I'd always assumed that the default 85 only applied to untitled images on
the first save not that it was silently forced on an unwary public as some
sort of hidden "gimp knows best" feature.
Abritarily throwing away half the image data without so much as a 'by your
leave' , incredible.
I'm really surprised that you dont see this as a bug.
I would ask you to seriously consider if this is appropriate. Please take
time to reflect on this before replying and preferable sound out a few
Thanks for the reply.
Gimp-developer mailing list