[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-developer
Subject:    Re: [Gimp-developer] jpeg quality factor
From:       "David Gowers" <00ai99 () gmail ! com>
Date:       2007-07-14 7:51:02
Message-ID: 23f4e3390707140050v698db490o260d15a482be60ea () mail ! gmail ! com
[Download RAW message or body]

On 7/14/07, gg@catking.net <gg@catking.net> wrote:
> On Fri, 13 Jul 2007 00:03:18 +0200, Chris Mohler <cr33dog@gmail.com> wrote:
>
> I'll try to follow the analogy without this becoming rediculous:
>
[misrepresentation and reactiveness cut]

>
> We all know that jpeg is lossy. You use it with suitable settings in
> relation to the result required otherwise you use a different format.
>
> There seems to be some underlying assumption here that jpeg loss is
> catasrophic. It is not. Sure, if I am going to post about the difference
> between lanczos and catmull-romm filters jpeg will not get a look in.
> However if I am messing with a photo of my solar panel at jpeg-84 I dont
> want some arse telling me I have to first save if in a format that takes
> up 10x more space because I may later want to reopen it and I may lose a
> bearly perceiptible bit of quality.

The proposed scheme does not dictate that. The only thing needed to
facilitate your described work flow, with no additional overhead is a
'Quick Export' command that just saves to the last 'non-native'
filename (if I may introduce the idea of assigning both a native
filename and a (possibly empty) render filename to each image; this
would help with a number of things, eg. drawing with oversampling,
quick photo editing, images for web..)

> As Raphael says we should try to cater for all users if possible. The
> suggested first time use message with "dont show again" option would seem
> best all round.
Yes; just not only that. The full scheme described by Peter plus that.

> I should also point out the misuse of the "import/export" paradigm. This
> is used in other software of various sorts to indicate loading/saving data
> in a format which is not handled natively by the program.

Gimp only handles XCF; the rest *are* implemented outside of Gimp;
even gzip/bzip2 compression for XCFs is implemented as a plugin.

If you remove all plugins, it's plain to see that Gimp only handles
XCF natively, just like Photoshop only handles PSD natively; It's
generally a Bad Thing for an editor to need to cope with multiple
'native' formats. GIMP's 'parasite' concept allows it to store
arbitrary chunks of data, that may be acquired from importing (eg EXIF
data from a jpeg) without needing to understand the meaning of that
data; I understand how this may give the illusion that GIMP can handle
something not XCF, but it is only an illusion.

I think, highlighting this fact might be quite wise. We should not
annoy the user in telling them this - something as outwardly simple as
a parasite viewer/editor dockable could improve awareness.


> It is nonsense to talk of exporting a jpeg to gimp's internal format.
I agree fully. Nobody has mentioned that*, only the opposite.
1. You load the jpeg. (foo.jpeg)
2. You work on it. Each time you save, it's in XCF format (foo.xcf)
3. You export a jpeg when finished (foo.jpeg, or maybe foo-final.jpeg)

If anything, that says 'automatically import from jpeg' (which is the
current behaviour, minus actually changing the on-disk image format.)
and later 'export to jpeg'.
The addition I suggested earlier in this email would be trivially easy
to implement and use, logically consistent, and would not require the
GUI's concept of Save to remain in its current, broken, state.

I think, in short, this thread is mainly comprised of
miscommunication; People seem to think it implies things that it just
doesn't.

* Maybe Valerie did. I found her post very confusing, so I'm not sure
what she was suggesting.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[prev in list] [next in list] [prev in thread] [next in thread]