> On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking <[EMAIL PROTECTED]>
> wrote:
> >
> > Really? Let's have a look at the product vision. 'High-end'
> > is the word I want us to focus on.
> Please dont distort this by taking one word out of context.
> Gimp's aim to be a high-end image manipulation program does not mean
> everyone has to become a professional graphics artist.

Nor has Peter suggested this. Take your own advice about not taking
things out of context.
What was suggested is essentially to make the 'Save' action more
truthful - in order to
  a) Reduce confusion -- 'wait, every time I edit and resave this jpeg
it gets worse. Why is that?'* -- by providing a standard editing
Throwing away data is a pathological case, which is why GIMP should
only allow this by a plugin, rather than explicitly supporting it; it
should, probably, be considered 'deprecated'.

  b) Reduce corner cases (ie improve interface consistency) -- 'Save'
shouldn't mean 'Lose.' in any case.
  c) Adhere better to the basic Unix tenet of 'Don't throw data away
unless explicitly commanded to.'

What is being proposed is both more effective for the general editing
case, and more flexible.

I appreciate the compression benefits of JPEG for photos, but IMO on
todays multi-gigabyte hard drives, saving a single uncompressed
working image per image you work on is unlikely to be any significant
resource drain.. even for huge images.

I want to mention the necessity of recording the original input image
filename -- and maybe an action to 'Save over original'; I believe it
hasn't been addressed yet, and I expect that someone like yourself
would be satisfied by that. (I still think you should RTFM on the
vision of gimp as high end graphics editor -- it was made by
discussion with the GIMP team in-person.


*as someone else already noted, any manipulation of large areas of the
image is liable to cause further compression error, whether the
compression parameters have been altered or not.
Gimp-developer mailing list

Reply via email to