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 set
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 diffe
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.
> --
Obvio
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
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 artifa
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
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 situati
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 situ
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
> >> her
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 PR
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 hav
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 y
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 sav
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. sav
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
> degr
[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
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 info
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?
Be
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
u
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
> 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 sensit
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
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 "quantiza
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 wi
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.
http://citeseer.ist.psu.edu/cache/papers/cs/1634/ftp:zSzzSzftp.cs.wisc.eduzSzpubzSztech-reportszSzreportszSz94zSztr1257.pdf/rd-o
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 surpr
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
33 matches
Mail list logo