On 01/19/10 22:51, Liam R E Quin wrote:
On Tue, 2010-01-19 at 22:38 +0100, yahvuu wrote:
[...]
II. Range of actually useful values for IJG quality value
For GIMP's target users less than half of all possible settings
are useful:
possibly - I've often used values as low as 35% or
Once a user starts to use jpeg they have to decide what to do with
quality setting. Bigger number = better quality is not too hard to get
your head around. A bit of experimenting quickly reveals what works best
for a particular task.
You quickly realise what ranges don't fit your needs and
Liam R E Quin wrote:
On Tue, 2010-01-19 at 22:38 +0100, yahvuu wrote:
[...]
II. Range of actually useful values for IJG quality value
For GIMP's target users less than half of all possible settings
are useful:
possibly - I've often used values as low as 35% or sometimes lower.
The
On Tue, 2010-01-19 at 22:38 +0100, yahvuu wrote:
[...]
II. Range of actually useful values for IJG quality value
For GIMP's target users less than half of all possible settings
are useful:
possibly - I've often used values as low as 35% or sometimes lower.
The sweet spot depends hugely
On Tue, 19 Jan 2010 22:38:40 +0100
yahvuu yah...@gmail.com wrote:
II. Range of actually useful values for IJG quality value
For GIMP's target users less than half of all possible settings are
useful:
http://yahvuu.files.wordpress.com/2009/08/ijgqualityrange.png
or, in ASCII:
On Tue, Jan 19, 2010 at 10:38:40PM +0100, yahvuu wrote:
Hi all,
recent discussion on gimp-user brought up some usuability issues
of the JPEG export dialog [1]. Actually, there's nothing new to say
about it... the big JPEG quality thread did cover it all [2].
However, due to the sheer size
On Fri, 13 Jul 2007 00:03:18 +0200, Chris Mohler [EMAIL PROTECTED] wrote:
I'll try to follow the analogy without this becoming rediculous:
In this analogy, the new GIMP Hammer would auto-provide a nail
(since the nail is clearly better). The carpenter would flip the GIMP
hammer around and
On 7/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Fri, 13 Jul 2007 00:03:18 +0200, Chris Mohler [EMAIL PROTECTED] 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
Quoting [EMAIL PROTECTED]:
On Tue, 10 Jul 2007 19:21:33 +0200,
[EMAIL PROTECTED] wrote:
No. If you want to specify something other than a user-specified
default for an acceptable level of quality while editing in the GIMP
(for example, overriding it with an image-specific value), that is
On Fri, 13 Jul 2007 20:49:49 +0200,
[EMAIL PROTECTED] wrote:
I fail to see how I have misused the term default in any of this
explanation.
Sorry , apparently you missed the other post where I explained this more
fully, I assumed everyone who was following this was reading the posts.
The
On Fri, 13 Jul 2007 22:42:29 +0200, [EMAIL PROTECTED] wrote:
On Fri, 13 Jul 2007 20:49:49 +0200,
[EMAIL PROTECTED] wrote:
I fail to see how I have misused the term default in any of this
explanation.
[...]
When an image already has a value for jpeg_quality , or any other
paramter,
How about creating the following buttons on the jpeg save console?
- Save at original image compression value
- Save at user-specified compression value (insert current value of
used-specified quality)
- Change user-specified compression value
It can be abbreviated as the following:
Save at the
Raphaël wrote:
let's see how short I can keep this.
We also have to be humble and remember that writing down the current
vision only took us a couple of hours, not 5 years (basically one hour
of discussion at LGM plus some e-mail exchanges while we were
polishing the minutes).
Two hours.
Hi,
On Thu, 2007-07-12 at 13:29 +0200, peter sikking wrote:
Two hours. The vision has been simmering in the back of the minds of
everybody involved for all the years that they have been working on
GIMP.
If you are now interpreting this vision that way that GIMP is not meant
to be used for
Akkana wrote:
I'm seeing an unspoken assumption in this thread that most photos
are edited in multiple sessions: read into gimp, do a few
operations, write to disk, read back in (perhaps hours or days
later), do a few more operations, write back out, repeat.
I was more thinking from the
Let me also try to keep this (relatively) short. I'm not good at this. :-)
On Thu, 12 Jul 2007 13:29:49 +0200, peter sikking [EMAIL PROTECTED] wrote:
I take the vision as broad as it can be explained (it was phrased not so
specific for a reason), but not broader.
That's certainly fine. But
On Thu, 12 Jul 2007 14:31:16 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote:
Let me also try to keep this (relatively) short. I'm not good at this. :-)
I could have made it much shorter. Summary:
1) Our vision focuses on a minority of GIMP users (experienced users, or
those who need
On Tue, 10 Jul 2007 19:21:33 +0200,
[EMAIL PROTECTED] wrote:
No. If you want to specify something other than a user-specified
default for an acceptable level of quality while editing in the GIMP
(for example, overriding it with an image-specific value), that is
when you should use Save As.
Sorry - I always forget to Reply-All to this list...
On 7/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
[...]
GIMP IS A TOOL, NOT A TUTORIAL.
Take an analogy:
A builder needs to nail a piece of wood as a guide but all the nails he
has to hand are too big. To get round the problem he
On 7/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
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.
On 7/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Tue, 10 Jul 2007 02:08:45 +0200, Chris Mohler [EMAIL PROTECTED] wrote:
I expect the Save command to retain
*all* data: not just some.
If you expect that when using jpeg you are wrong and need to see the first
use warning that has
Chris Mohler wrote:
I understand that JPEG drops data. My point: in most applications,
'save' means save your data. In the image editing world, 'save' has
come to mean save as much data as you want given the limitations of
the format - here are (or might be) some options.
One view is that
On Tuesday, July 10, 2007, 8:09:04, Chris Mohler wrote:
I understand that JPEG drops data. My point: in most applications,
'save' means save your data. In the image editing world, 'save' has
come to mean save as much data as you want given the limitations of
the format - here are (or might
Quoting [EMAIL PROTECTED]:
On Tue, 10 Jul 2007 01:24:40 +0200,
[EMAIL PROTECTED] wrote:
If I have
a Quality setting of 95 and I load an image that was saved with a
Q=50, I should be very disappointed if the GIMP degraded to that level
when I have specified that I expect less loss when
gg, my dear agent provocateur,
creating interaction requires making hard choices, because you
cannot make an application for everybody. For that you use the
product vision that you set as a team at the beginning of the
project. And then you don't fudge when the moment is there.
You make hard
On Tue, 10 Jul 2007 12:29:23 +0200, peter sikking [EMAIL PROTECTED] wrote:
creating interaction requires making hard choices, because you
cannot make an application for everybody. For that you use the
product vision that you set as a team at the beginning of the
project. And then you don't
Raphaël wrote:
creating interaction requires making hard choices, because you
cannot make an application for everybody. For that you use the
product vision that you set as a team at the beginning of the
project. And then you don't fudge when the moment is there.
I would like to temper this
Von: Raphaël Quinet [EMAIL PROTECTED]
We also have to be humble and remember that writing down the current
vision only took us a couple of hours, not 5 years (basically one hour
of discussion at LGM plus some e-mail exchanges while we were
polishing the minutes).
... plus the better part of
Von: Michael Schumacher [EMAIL PROTECTED]
Kanila's
Kamila, sorry for misspelling your name.
Michael
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
___
On Tue, 10 Jul 2007 16:32:11 +0200, peter sikking [EMAIL PROTECTED] wrote:
Raphaël wrote:
I would like to temper this a bit (not agent provocateur as gg,
but maybe devil's advocate): a team that is too rigid about its
vision and never adapts it over time runs a real risk of
becoming
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
On Tue, 10 Jul 2007 18:26:38 +0200, Michael Schumacher [EMAIL PROTECTED]
wrote:
Von: Raphaël Quinet [EMAIL PROTECTED]
We also have to be humble and remember that writing down the current
vision only took us a couple of hours, not 5 years (basically one hour
of discussion at LGM plus some
peter sikking writes:
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.
I'm seeing an unspoken assumption in this thread that most photos
are edited in
On Tue, 10 Jul 2007 09:51:24 -0700, Akkana Peck [EMAIL PROTECTED] wrote:
Another thing I'm unclear on in this thread: when I first heard the
idea of forcing Export instead of Save, the plan seemed to be that
Save would always save XCF, and anything else would require Export.
But now you seem
On 7/10/07, Raphaël Quinet wrote:
GIMP parasites, etc. In fact, even the current XCF loses some
information if you consider that it does not record the full undo
history and the current tool contexts, but this is something that
most users accept.
They really do?
Alexandre
Quoting [EMAIL PROTECTED]:
On Tue, 10 Jul 2007 01:24:40 +0200,
[EMAIL PROTECTED] wrote:
If I have
a Quality setting of 95 and I load an image that was saved with a
Q=50, I should be very disappointed if the GIMP degraded to that level
when I have specified that I expect less loss when
On Mon, 2007-07-09 at 18:37 -0400, Liam R E Quin wrote:
For my part I miss save a copy as... which in some programs
saves the file like Save As but doesn't change the filename of
what's being edited.
GIMP 2.3 has this feature for quite a while already.
I wonder if it'd be possible, for gimp
So I broke my promess.
creating interaction requires making hard choices, because you
cannot make an application for everybody.
I have to agree. A good UI doesn't do what users ask. It does what is better
for the users. ;-)
This approach of taking the lossy format to an import/export section
On Tue, 2007-07-10 at 19:41 +0200, Sven Neumann wrote:
On Mon, 2007-07-09 at 18:37 -0400, Liam R E Quin wrote:
For my part I miss save a copy as... which in some programs
saves the file like Save As but doesn't change the filename of
what's being edited.
GIMP 2.3 has this feature for
Hi,
On Sun, 2007-07-08 at 19:15 -0400, guepe wrote:
In fact, my patch... does exactly that : if defaults settings are
already saved, jpeg is saved with the parasites one (erasing the
hardcoded ones). If no settings have been saved, then hardcoded are
used.
There is another player in the
Moin,
On Mon, 2007-07-09 at 00:03 +0200, Sven Neumann wrote:
The JPEG plug-in should not use the last-used values when being run
non-interactively from the Save action. It should use the, now
user-configurable, default values. Of course if the jpeg-save-options
parasite is set on the image
Sven Neumann writes:
If someone wants to try to recover some of the JPEG save settings when
loading the JPEG file, feel free.
There are some scenarios in which blindly reusing the quality factor
guesstimated from loading an image is not a good idea, even if the
guesstimate is very accurate.
On Mon, 9 Jul 2007 17:32:29 +0300, Tor Lillqvist [EMAIL PROTECTED] wrote:
Sven Neumann writes:
If someone wants to try to recover some of the JPEG save settings
when loading the JPEG file, feel free.
I did.
Thanks for this very nice patch! It would be even better to do the same
for the
guys, what a thread.
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.
This would prevent the misunderstanding that there is a continuous
lossless workflow for these type
On Mon, 9 Jul 2007 17:54:29 +0200, peter sikking [EMAIL PROTECTED] wrote:
guys, what a thread.
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
Von: Raphaël Quinet [EMAIL PROTECTED]
On Mon, 9 Jul 2007 17:54:29 +0200, peter sikking [EMAIL PROTECTED]
wrote:
guys, what a thread.
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
Hi,
On Mon, 2007-07-09 at 18:42 +0200, Raphaël Quinet wrote:
Side note: as suggested by Sven in #gimp, I just had a look at
ImageMagick to try and find out how they retreive or guess the quality
settings from JPEG files. The code is about 100 lines long and can be
found in
There is another player in the game and that's the last-used values
stored with gimp_[gs]et_data(). And that's what has bitten Guillermo.
He has saved an image as JPEG with low quality settings.
No, I haven't.
Since I know the problem I'm using always save as with quality=95 but it's
still
Hi,
On Mon, 2007-07-09 at 09:42 +0200, [EMAIL PROTECTED] wrote:
Ha, cross post .
Cross post? Huh?
Btw, is it intentional that you are mailing from two (or three)
different accounts and never put your real name in the From field? I
find the use of two accounts annoying and the lack of a real
On Sun, Jul 08, 2007 at 09:59:18AM -0400, Robert L Krawitz wrote:
Think of the quality setting as an indication of expectations rather
than a specific outcome. It may not be possible to get the exact same
outcome (and obviously -- at least to us -- there's no way to
retroactively improve
Hi,
On Mon, 2007-07-09 at 11:36 -0600, Scott wrote:
Just curious, what would be so wrong with saving the original file as
a backup before doing a destructive save? Emacs only bites me when I'm
*really* stupid
There's nothing wrong with that. It's even on the list of things that
the file
On Mon, 09 Jul 2007 19:32:14 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
Btw, is it intentional that you are mailing from two (or three)
different accounts
No it's not intentional. I share this email client which has several
accounts configured. Occassionally I hit reply and fail to notice
Scott wrote:
I am so glad that Guillermo stuck by his guns and apparently *finally*
got the developers to realise the illogic of this feature.
Scott: Please keep in mind that I was trying to collaborate, not to fight.
In these cases is very common to see differences of criteria and some
rough
On Mon, 09 Jul 2007 17:54:29 +0200, peter sikking [EMAIL PROTECTED]
wrote:
guys, what a thread.
das stimmt!
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.
I
On Mon, Jul 09, 2007 at 08:18:44PM +0200, Sven Neumann wrote:
Hi,
On Mon, 2007-07-09 at 11:36 -0600, Scott wrote:
Just curious, what would be so wrong with saving the original file as
a backup before doing a destructive save? Emacs only bites me when I'm
*really* stupid
There's
Hi,
On Mon, 2007-07-09 at 14:07 -0600, Scott wrote:
If more users would be so persistent, as you call it, then there would
probably not a single developer left who would feel that developing GIMP
is fun. There would probably be noone who would be willing to spend
his/her free time on it.
On Mon, 09 Jul 2007 11:33:34 +0200, Tor Lillqvist [EMAIL PROTECTED] wrote:
There are some scenarios in which blindly reusing the quality factor
guesstimated from loading an image is not a good idea, even if the
guesstimate is very accurate. (Which happens when the loaded image's
quantization
On Sun, 2007-07-08 at 12:19 +0200, Sven Neumann wrote:
[...]
Due to the way file plug-ins are implemented in GIMP, it is not trivial
to do this. But you can easily work around it by assigning Ctrl-S to
Save As.
I'd advise making ^S to be Quit. Then you'll be prompted, realise
your mistake,
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
Quoting Sven Neumann [EMAIL PROTECTED]:
... The happy user is
silent. If we would do a change every time a user asks for a change,
then GIMP would be a lot more inconsistent and probably also more buggy.
For that reason it is important to
On Mon, 09 Jul 2007 11:33:34 +0200, Tor Lillqvist [EMAIL PROTECTED] wrote:
There are some scenarios in which blindly reusing the quality factor
guesstimated from loading an image is not a good idea, even if the
guesstimate is very accurate. (Which happens when the loaded image's
quantization
At the risk of lengthening this thread... :)
I agree with Peter - saving in a lossy format is a last-step operation
in a good workflow. I respect the case of simple tweak and saving,
but in the long run, all users should never being able to choose
save and then lose data. I expect the Save
On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking [EMAIL PROTECTED]
wrote:
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
On Tue, 10 Jul 2007 01:24:40 +0200,
[EMAIL PROTECTED] wrote:
If I have
a Quality setting of 95 and I load an image that was saved with a
Q=50, I should be very disappointed if the GIMP degraded to that level
when I have specified that I expect less loss when saving.
It would NOT degrade it
On Tue, 10 Jul 2007 01:58:50 +0200, Graeme Gill [EMAIL PROTECTED]
wrote:
On Mon, 09 Jul 2007 11:33:34 +0200, Tor Lillqvist [EMAIL PROTECTED] wrote:
There are some scenarios in which blindly reusing the quality factor
guesstimated from loading an image is not a good idea, even if the
On Tue, 10 Jul 2007 02:08:45 +0200, Chris Mohler [EMAIL PROTECTED] wrote:
I expect the Save command to retain
*all* data: not just some.
If you expect that when using jpeg you are wrong and need to see the first
use warning that has been suggested.
Assuming you do have some knowlege of
On Sun, 08 Jul 2007 07:22:24 +0200, Guillermo Espertino
[EMAIL PROTECTED] wrote:
In Gimp, it saves the file directly, without asking for the compression
setting. Result: an image over-compressed with artifacts. Smaller size
than the original.
In Photoshop, it shows the quality settings
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Sat, 07 Jul 2007 21:38:57 +0200, Øyvind Kolås [EMAIL PROTECTED] wrote:
the image used in
the JPEG Generation Loss figure in the example in the following text
uses an image that
shows how JPEG compression keeps different aspects of
Hi,
On Sat, 2007-07-07 at 22:13 -0300, Guillermo Espertino wrote:
Back to the topic: I propose to display the quality settings when an
image is resaved as jpeg for the first time, if it's possible.
I don't know how it's done, but when I take my image to PS from my
camera, it asks me to
On Sun, 08 Jul 2007 12:10:30 +0200, Øyvind Kolås [EMAIL PROTECTED] wrote:
But a full decode/encode/decode cycle of JPEG / DV /
MJPEG etc will accumulate more and more errors/artifacts. This
accumulated error would be smaller with a higher default quality
though.
/Øyvind K.
--
Obviously
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
You clearly know more about the detail of this than I do but isn't there a
direct one-to-one mapping once the original compression is done?
Nope.
Any deviation from that must be errors in the decoding, so is what you
posted a symptom of
Date: Sun, 08 Jul 2007 11:44:17 +0200
From: [EMAIL PROTECTED]
On Sun, 08 Jul 2007 07:22:24 +0200, Guillermo Espertino
[EMAIL PROTECTED] wrote:
In Gimp, it saves the file directly, without asking for the compression
setting. Result: an image over-compressed with
Hi,
On Sun, 2007-07-08 at 08:17 -0400, Robert L Krawitz wrote:
Note that GIMP is not the only application that does this;
Why should any application do what you suggest? If you open a JPEG file
and save it again as JPEG, then the original quality factor is
completely irrelevant. You are doing
On Sun, 08 Jul 2007 14:35:30 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,
On Sun, 2007-07-08 at 08:17 -0400, Robert L Krawitz wrote:
Note that GIMP is not the only application that does this;
Why should any application do what you suggest? If you open a JPEG file
and save it again as
Hi,
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 here
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
On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,
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
here
and you think is the best way gimp should deal with this situation?
Indeed.
From: Sven Neumann [EMAIL PROTECTED]
Date: Sun, 08 Jul 2007 15:12:03 +0200
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 here and you think is the best way gimp should deal with
this situation?
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,
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
here
and you think is
Date: Mon, 9 Jul 2007 00:26:21 +0930
From: David Gowers [EMAIL PROTECTED]
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,
On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote:
Sven Neumann schreef:
Hi,
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 here
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
On Sun, 08 Jul 2007 19:55:30 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,
On Sun, 2007-07-08 at 17:37 +0200, Roel Schroeven wrote:
2. read the quality when loading a jpeg, and used that to save the image
(if save as is not used).
Last time we discussed this (a couple of years ago),
Hi,
On Sun, 2007-07-08 at 17:37 +0200, Roel Schroeven wrote:
2. read the quality when loading a jpeg, and used that to save the image
(if save as is not used).
Last time we discussed this (a couple of years ago), libjpeg didn't
allow us to read the JPEG quality factor that was used to save
On Sun, 08 Jul 2007 17:37:28 +0200, Roel Schroeven
[EMAIL PROTECTED] wrote:
1. open a.jpg
2. save a.jpg
- a.jpg is saved with the default quality, 85. Fine by me.
3. save a.jpg with save as, with quality say 55
- as expected it is saved with quality 55.
4. open b.jpg
5. save b.jpg
-
On Sun, 08 Jul 2007 17:53:59 +0200, Robert L Krawitz [EMAIL PROTECTED]
wrote:
What about the case where the original quality was 96 or 98, and it's
resaved at the same quality level? My quick test showed a slight
decrease in file size, but probably very little in the way of image
[EMAIL PROTECTED] schreef:
On Sun, 08 Jul 2007 17:37:28 +0200, Roel Schroeven
[EMAIL PROTECTED] wrote:
1. open a.jpg
2. save a.jpg
- a.jpg is saved with the default quality, 85. Fine by me.
3. save a.jpg with save as, with quality say 55
- as expected it is saved with quality 55.
4.
OMG, at last!
That's what I was trying to say since the beginning.
I know jpeg is a lossy format (I knew that for at least ten years). I
know, and always knew, that it has generational degradation.
I didn't know that PS compression scale doesn't follow the jpeg
specification. Thanks for the
Hi,
On Sun, 2007-07-08 at 18:31 -0300, Guillermo Espertino wrote:
What I didn't know (and wouldn't expect) is that Gimp will destroy my
pictures without warning me.
And that's exactly what I get.
I have a picture taken at 95, open it and save it, and it ends up at 85.
Why is that?
Hi,
here's what I suggest that we do (short-term). It should be a simple
change and it will avoid that what happened to Guillermo happens to
others in the future.
The JPEG plug-in should not use the last-used values when being run
non-interactively from the Save action. It should use the, now
On Sun, 08 Jul 2007 23:48:28 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,
On Sun, 2007-07-08 at 18:31 -0300, Guillermo Espertino wrote:
What I didn't know (and wouldn't expect) is that Gimp will destroy my
pictures without warning me.
And that's exactly what I get.
I have a picture
So please calm down and let the developers deal with this.
After all this is a developer list. Your
harsh comments are not helpful.
I'm not being harsh. At least it wasn't my intention.
In fact, this list is commonly considered to be harsh by many people,
but now I learn that there's
From: Sven Neumann [EMAIL PROTECTED]
Date: Sun, 08 Jul 2007 23:48:28 +0200
On Sun, 2007-07-08 at 18:31 -0300, Guillermo Espertino wrote:
What I didn't know (and wouldn't expect) is that Gimp will
destroy my pictures without warning me. And that's exactly what
I get. I have
Guillermo Espertino writes:
I didn't know that PS compression scale doesn't follow the jpeg
specification.
There is no such specification for a compression scale or quality
factor.
Inside an JPEG image, what actually defines the lossiness of the
compression are a set of so-called
Sven Neumann writes:
I already explained that the JPEG plug-in cannot access the settings
that were used to save the file.
Actually, it shouldn't be that hard to at least try. If the
quantization tables used in an image correspond exactly (or closely
enough) to those produced by libjpeg with
Tor Lillqvist writes:
One might imagine some application even doing a clever analysis of an
individual image to come up with image-specific quantization
tables.
Tor Lillqvist wrote:One
might even consider keeping and re-using the original quantization
tables instead of using jpeg_set_quality() in case the quantization
tables don't seem to be produced by libjpeg.
Which is what I understand Photoshop does, thereby giving
users the least level of
On Sat, 07 Jul 2007 07:19:57 +0200, Guillermo Espertino
[EMAIL PROTECTED] wrote:
Se only opened the image from the camera, adjusted the curves, and
scaled it down (BTW, the downscale code should do oversamplig by
default. It always breaks a little the edges). Until she saved, the
image
Guillermo Espertino wrote:
In Gimp the compression factor is expressed as quality factor. So 100%
is the best and 0% is the worst.
GIMP does use the IJG quality scale.
Well, 70% isn't the same in Gimp and in Photoshop. And it doesn't sound
very logical.
Blame Adobe for this. The JPEG FAQ
Guillermo Espertino writes:
The same image exported as jpeg with the same quality factor (let's take
75% as an example)
Where did you get that percent sign from? GIMP doesn't show any
percent sign. The quality value is not a percentage of anything. You
should just treat it as a number on a
[EMAIL PROTECTED] writes:
Here if I can do say 10 re-saves at 85% quality, it produces no
discernible changes in picture quality.
Presumably you also re-load the image you just saved each time?
--tml
___
Gimp-developer mailing list
Thanks everybody for your replies. It's more clear for me now.
- Compression factor isn't linear and in IJG, and that factor doesn't
represent a percentage.
- Photoshop converted its scale for making it more intuitive, but it
has nothing to do with the right IJG scale.
Thanks Michael for the
1 - 100 of 110 matches
Mail list logo