Re: jpeg quality factor.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Raphaël wrote:

>> I say that the solution for all this lies in treating these lossy
>> (my spell-checker proposes lousy) formats the same we are (gonna)
>> handle indexed mode:
>>
>> import + export only.
>
> Eek!  That would significantly break the flow for what must be the
> most common image format for photography.

Really? Let's have a look at the product vision. 'High-end'
is the word I want us to focus on.

I can understand that a high-end workflow can start with a
jpeg because due to a mishap nothing better is available.
I can also understand that a jpeg version can be part of
the final result.

But in between, as long as it is not finished, there is no role for  
jpeg. Only one decompression at the beginning and a compression of the
end result is defendable in high-end graphics.

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.

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.

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.

We need to actively support the high-end workflows, with minimal effort.

Consumer mid-fi workflows (open jpeg, edit the image, save (overwrite)
the jpeg) are still possible, (open, edit, export) and it does not look
like any more effort than the current situation. If users get the hint
that opening and saving the same jpeg again and again is a pain (also  
for
the quality) and that either adopting a high-end GIMP file workflow or
moving to another (mid-fi) app to work in their lossy jpeg way.

> Before I started shooting only in raw format (so before I bought
> larger memory cards for my camera), I shot a lot of JPEG pictures.

Can you relate why you moved up to raw to the requirements of high-end
image manipulation? I can.

     --ps

         principal user interaction architect
         man + machine interface works

         http://mmiworks.net/blog : on interaction architecture



_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux