On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking <[EMAIL PROTECTED]> wrote:
> There is also a real benefit in opening a jpeg and then saving
> the result in another (GIMP) file. We see from the explanations in this
> thread that opening a jpeg and then saving it again means a loss of
> information. So overwriting an original is a loss. Working on a
> full-fidelity copy version is preferred.

Note that in the workflow that I described, I never mentioned
overwriting the original.  On the contrary, I said that the final
JPEG file would be saved under another name.


> The early part of this thread is full of misunderstanding at which
> point working with jpeg incurs quality loss. I say it is because of
> the "you can work in jpeg" myth. I am still confused that you talk
> about saving intermediate results while working on a jpeg. Either
> each save reduces quality (implicit save and reload, ouch) or there
> is a penalty for closing the file and reopening it, because you
> lost the full-fidelity internal (GIMP) representation, ouch.

I am not sure about what others had in mind in this thread, but I
I was mostly focusing on corrections to the source photos such as
correcting the exposure or color balance and making other minor
edits with the clone tool, etc..  These steps can be performed in
a single session without having to save any full-fidelity internal
representation.  When I mentioned saving intermediate results, I
meant saving copies of the image that you are currently working on,
if you want to check how the final output will look like (including
losses due to compression).

If you intend to work further on the image or to re-use some parts
of it in a collage or in a more complex work, then it certainly
makes sense to save the XCF version (or any other lossless format).
The same applies if you work more than a few minutes on the image
and it would cost too much to re-do these changes from the original
in case you decide some weeks later that you need to apply more
changes to the image.

But for the simple workflow that I described (which is or was
rather common for me), in which simple corrections have to be
applied to a large number of images without intending to work on
them further, then it makes sense to have JPEG as input and as
output without wasting time or space with intermediate formats.

> So I see real benefits for a high-end image manipulation program
> that lossy formats are pushed out to the very beginning and very
> end of the workflow. That the working copy of the file is GIMP format,
> in full fidelity, any GIMP operation naturally possible, and with
> no penalty for opening and closing the file.

I am not disputing that.  We should encourage users to use the
lossless XCF format for all things that may need to be edited
later or re-used in other images.  As long as this can be done
without breaking common workflows, then it's fine.

I don't mind if the simple load-edit-save cycle for JPEG images
produces a warning the first time I do that, telling me that
saving in JPEG will result in a quality loss and recommending
XCF for saving any work-in-progress.

But would mind getting this warning every time or being forced
to use a different menu option than the normal Save for the
second and subsequent attempts at saving the image.  This is
how I interpreted your initial reaction.  If I misunderstood
what you meant and you did not intend to break the flow, then
I am sorry for the misunderstanding and we can forget about it
because there is really no issue.

-Raphaël

P.S.: If this issue is cleared and we ignore the arguments for
      the sake of argumenting (my previous message), then I
      think that I have a solution for the original issue
      mentioned in this thread: this is very close to the
      patch proposed by Tor and it also supports JPEG files
      that were not created by libjpeg.  More about that
      later, when my code is ready.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to