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
Hi,
a new GIMP 2.2 release has been uploaded to
ftp://ftp.gimp.org/pub/gimp/v2.2/
GIMP 2.2.16 is a bug-fix release in the stable GIMP 2.2 series. It fixes
security problems in some file load plug-ins and improves robustness and
forward compatibility of the XCF loader. In particular the following
Hi,
I would like to say special thanks to Mukund and Raphaël who both helped
during the last week to fix the reported and some unreported security
problems in our file load plug-ins. Without your help we wouldn't have
been able to respond to the vulnerability report so quickly.
Sven
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
31 matches
Mail list logo
