Trying to be more specific: If I open an image from my digital camera with gimp, adjusts its levels or curves, and re-save it, the saved image is very deteriorated. If I do the same with Photoshop that doesn't happen. I think it's problem, but let me know if I'm wrong. At least I know that I must re-save images from other sources using a higher quality factor.

Interesting, what platform are you using?

Here if I can do say 10 re-saves at 85% quality, it produces no discernible changes in picture quality.

In fact I have tried to prove that recompressing jpg pictures reduces the picture quality and got bored doing it at 85% (which btw is the Gimp default)

However I could degrade quality by repeatedly saving at some lower quality, like 50%

Opinion.
Y
You should never work on a jpeg, take it in off your camera, save it as an xcf and when finished, recreate it as a jpeg if you want.

Owen

On Sat, 07 Jul 2007 07:19:57 +0200, Guillermo Espertino 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 quality was good.
Then she saved with CTRL+S, without changing the "quality" factor, and the picture turned out like that. Heavily compressed.

Maybe you should try adjusting the compression level on the camera, it maybe a simple A,B or C choice and is probably not presented as "jpeg quality".

Jpeg is a sensible choice for a memory limited device like a camera but you have to make a chioce in using it. Once the information is lost it is gone for ever. If you wish to readjust you colours and downscale you are completely altering the form of the image. This is probalby about the worst thing to do between two jpeg compressions. It's really not a case of "she only did..." . I dont think there is anything anomolous about what you describe.

Now getting back main point of the thread, gimp vs. PS "quality" parameter.

Thanks for the detail of the comparison. The jpeg quaility parameter is defined in the jpeg standard and its meaning is clear. It is possible that since the useful range of values tends to be 60 - 85 (and note this is not a percentage ) PS may be mapping this in someway in presenting it to the user to give a more intuitive idea of quality which is in any case rather subjective and difficult caracterise in a simple two digit number.

I dont use PS but my guess is that there is no real difference in the implementation , simply in the way this parameter is presented to the user.

Other programs give a "compression" parameter which in effect adjusts the jpeg compression.

Does that tie in with your experience?

Thx.

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 states that differences between different programs have always been there, some even going as far as reversing the quality to a compression. See http://www.faqs.org/faqs/jpeg-faq/part1/

Also, 95% is the highest practically usable quality setting, anything higher does not have an influence on the pixels anymore (although it might be useful for researchers who are working on the algorithms).

The patch currently attached to bug http://bugzilla.gnome.org/show_bug.cgi?id=63610 might help to end the problem about which setting should be the default - if quality is persistent, you set it once.

HTH, Michael

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 nonlinear scale between 1 and 100. (With the usable range being between 70 and 95, say.)

(What would it be linear to? File size? Perceived quality, as if that could even be quantized?)

It is not necessarily related to corresponding scales in other software at all. The only thing one can know is that the higher the number is, the less compression artefacts one should see (and the bigger the file will be).

> Both programs calculate the compression ratio differently.

That is no surprise, as they use different JPEG software. You shoukd not think of the JPEG quality value as some "compression ratio" or any other "ratio". It is just a number whose exact meaning you will have to check from the libjpeg sources in GIMP's case. It is just a coincidence that both programs in this case happen to use a scale from 1 to 100.

--tml

rcook@pcug.org.au 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

On Sat, 07 Jul 2007 11:23:55 +0200, Tor Lillqvist wrote:

rcook@pcug.org.au 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

If you save the same data it will compress identically and the will be no more loss than the original compression. It's not the fact of pressing the save button that causes the loss of data it is the discrete cosine transform that appoximates the image as a large number of cosine functions.

If you make some changes you will lose a bit of quality on every save. How much depends on the nature of those changes.

gg

On Sat, 07 Jul 2007 18:58:28 +0200, Guillermo Espertino wrote:

We, the users, tend to assume things based on the information we get on screen.

.. or not on the screen, like percentages. ;)

It's very clear that Photoshop doesn't use the IJG scale, but it should. Users who came from PS are used to that incorrect scale, and find this difference.
I think it should be documented in the Gimp Manual and FAQs. It's not a minor issue.

The key point to realise is that gimp<>ps ; linux<>windows. It's well documented that gimp does not aim to be free PhotoShop. You pay your money (or not) and you make you choice.

Just because some software has established a dominant position in a particular market does not mean everyone has to clone it. Especially when no even competing in that market.

Somethings are better , some worse, it's DIFFERENT. Those that cant handle that had better pay for PS.

I repeat: I just open them from the camera and they look great (Nikon Coolpix 800), adjust levels, curves and >color (they still look great), scale them down, and save them using CTRL+S. When I re-open them they are >distorted. I'm not talking about repetitive openings and saves.

Until you reopen the image you dont see the changes made by the jpeg compression. That's normal but I dont get your point here.

Are you saying gimp is badly implementing the save and you can get better results doing the same thing with PS? Try doing you colour operations , saving as non lossy png then resave the same image with gimp and ps as jpeg and compare.

Are you saying gimp default quality/compression setting is not well chosen?

You dont seem to have grasped one fundemental point. It's not "I just open them from my camera and they look great" it's "my camera destroys some of the essential data by saving them internally as jpeg before I even get it". When you do further (and please note _major_ ) changes to that data and resave as jpeg you are getting hit by the fundemental weakness of DCT encoding, you lose quality. If you dont like this use gimp's xcf and/or png to maintain all the data your camera gives you.

If you are able to adjust your camera to a better jpeg ratio you will lose less quality after processing and may still get good results with jpeg.

HTH

Thanks everybody for your explainations!

you're welcome!

On 7/7/07, Guillermo Espertino wrote:

The images I get from the camera are fine. My problem is that if adjust them, scale them and re-save them without explicitly change the quality setting they turn out really distorted. Even though I understand (now) the difference between that scales, I'm still concerned about that quality loss in my images. I repeat: I just open them from the camera and they look great (Nikon Coolpix 800), adjust levels, curves and color (they still look great), scale them down, and save them using CTRL+S. When I re-open them they are distorted.
I'm not talking about repetitive openings and saves.

JPEG is a lossy format, to be able to describe what happens when you do this is outlined in steps below:

1.1) The camera sensor provides the original image signal (pixel raster) 1.2) The camera performs white balance adjustment according to setting/automatically determined white point 1.3) The camera does jpeg compression on the signal, discarding pieces of the actual content
of the image in a perceptually little degrading manner. (removing color resolution and keeping luminance information and giving preferential room for certain spatial frequencies (DCT quantization.). 2.0) GIMP decodes JPEG trying to reconstruct the signal from 1.2 based on the bits actually provided by 1.3. 2.1) Levels adjustment
2.2) Curves
2.3) Colors
2.4) The image is scaled actually improving the amount of data since we're now approximating the original signal at this scale better (more compressed bits per pixel).
2.5) The image is saved as JPEG throwing away information in the same manner as 1.3 but
with different thresholds for how much precision should be maintained. 3.0) The image is loaded in GIMP or an other application in the same manner as 2.0, trying
to reconstruct as signal based on not quite precise knowledge.

GIMP could perhaps even warn a user the first time he presses Ctrl+S on a an opened JPEG image warning him that even with minimal or no real changes to the image the signal will be degraded. This should be a warning of such a level of non-expertise that it perhaps could be turned on in the configuration/one of the initial tips of the day. And for each of them of course have the ability to say do not show this warning again.

Ideally JPEG compression involves a human operator that decides what acceptable loss is through visual inspection. A power user GUI for doing this would probably allow you to switch between the full signal and a reconstructed one in the viewport, perhaps with a zoomed in view with enlarged pixels in the dialog itself that can be panned, but uses the center of the image by default. The inputs needed in such a dialog would probably be a target file size
entry (I often aim to make JPEG images ~100kb at web publishing resolutions.) I would then
consider whether I've actually lost too much information and increase the quality until I find it acceptable. For my use of this slider I do not even need values of 0 and 100, I would actually expect 0.0 to yield a completely grey image if it should make intuitive sense, keep 0% of the signal vs keep 100%. A scale going from low to high quality makes more sense than any numerical values, like many other sliders it makes sense to be able to tweak a transfer function to make the results of interaction perceived as more uniform (another examples is gaussian blur where you do not want a linear scale of the radius, since that would give you a poor selection of smaller radiuses where small differences matter more than in the large part of the sliders range.)

A more immediate simpler enhancement is probably to use a higher quality/produce larger files by default. I haven't taken the time to do comparisons of how much is information is thrown away at each generation of save, but it seems to be quite a bit, 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 the image intact across multiple encode/decode cycles:

http://pippin.gimp.org/image_processing/chap_dir.html#id2526295

/Øyvind K.

On Sat, 07 Jul 2007 21:38:57 +0200, Øyvind Kolås wrote:

GIMP could perhaps even warn a user the first time he presses Ctrl+S on a an opened JPEG image warning him that even with minimal or no real changes to the image the signal will be degraded. This should be a warning of such a level of non-expertise that it perhaps could be turned on in the configuration/one of the initial tips of the day.

This may not be a bad idea. It is an important issue and most people have to discover this by trial and error or searching on internet when they notice the artifacts and don't understand why.

Like you say a good tip of the day and worth the interuption on first use on saving a jpeg.

/gg

Hi,
gespertino@gmail.com (2007-07-06 at 2246.00 -0300):

I'm noticing big differences between jpeg files from gimp and photoshop.

Quality as artifacts, smoothing, false colours? Size?

The same image exported as jpeg with the same quality factor (let's take 75% as an example) gives very different results in both programs. In my tests, Photoshop image has better image quality, but its size is 75 KB.
Gimp image shows lots of artifacts and its quality is lower, but its size is 35 KB.
Doing more tests I found that the factor 75% of Photoshop is equivalent to the 93% in gimp. Conclusion: Both programs calculate the compression ratio differently.

Tried playing with the subsampling and dct settings? Those can change final look and size.

Anyway, it seems every app has different meaning for the "JPEG Quality".

GSR

On Sat, 07 Jul 2007 21:38:57 +0200, Øyvind Kolås 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 the image intact across multiple encode/decode cycles: http://pippin.gimp.org/image_processing/chap_dir.html#id2526295 /Øyvind K.
--

yes there does seem to be an issue here. I snipped the "generation 0" part of that image did File | Save As...
then reopened the new version and repeated the save several times.

There is continual degradation. This should not happen with an identical image. This seems to suggest that either there is a bug in the compression or that the decompression is not producing an identical image from the stored data.

/gg

On Sun, 08 Jul 2007 07:22:24 +0200, Guillermo Espertino 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 the first time you hit CTRL+S.

I think we're finally getting closer to the truth. There is something non standard in the file the camera is producing. It seems that PS knows there's a problem and thus prompts for the quality parameter, gimp it would seem is either reading this value as the IJG quality when it isn't or is applying a not too good default when it fails to read it.

If it's an incorrect value put in by the camera that gimp is correctly reading it's not a gimp issue. If it is a missing value gimp should probably use it's jpeg default of 85 (or prompt as you suggest) which it does not seem to be doing.

If you have imagemagick installed, use the following to see what information is in one of your camera images before you affect it with either gimp or ps and then again after gimp (and/or PS) does a save on it:

identify -verbose unadulterated_image.jpeg

That should give some info on what is in the jpeg header.

thx.

On 7/8/07, gg@catking.net wrote:

On Sat, 07 Jul 2007 21:38:57 +0200, Øyvind Kolås 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 the image intact across multiple encode/decode cycles: http://pippin.gimp.org/image_processing/chap_dir.html#id2526295 /Øyvind K.
--

yes there does seem to be an issue here. I snipped the "generation 0" part of that image did File | Save As...
then reopened the new version and repeated the save several times.

There is continual degradation. This should not happen with an identical image. This seems to suggest that either there is a bug in the compression or that the decompression is not producing an identical image from the stored data.

This is not a bug but a consequence of how the lossy compression of JPEG works, hence you should NEVER should use JPEG as an intermediate format in your workflow, but only for publishing the end result. It is theoretically possible, to keep the compressed version of unchanged parts of an image around, and only recompressing in the neighbourhood of regions that have actually changed by comparing with JPEG that one is saving over. 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.

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 adjust the quality when I press CTRL+S for the first time.
After that it saves normally.

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". Then you will always be prompted with the dialog asking you for the save parameters.

Sven

On Sun, 08 Jul 2007 12:10:30 +0200, Øyvind Kolås 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 what Guillermo is doing is fine as an exercise but his first save should be to a non lossy format or if his first save is his final save at least use Save As to get the full dlg and save it to the same name if that's what he wants.

Personally I would always keep any original image so even a 'first save = last save' would get a new name and hence go through the dlg with the quality option.

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?

Any deviation from that must be errors in the decoding, so is what you posted a symptom of continual rounding errors in the decoding altering the image each time?

Then the growing artifacts are a result of the limited colour resolution of 8 bits per channel used by gimp.

Thx

/gg

On 7/8/07, gg@catking.net 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 continual rounding errors in the decoding altering the image each time?

Then the growing artifacts are a result of the limited colour resolution of 8 bits per channel used by gimp.

Also by the fact that in JPEG greyscale and color information is decoupled and the color information is stored with lower spatial resolution than the greyscale data. Thus there is additional rounding that has to be done to get back to a RGB raster. The bottom line is that JPEG, DV (for video) and other similar lossy compressions do introduce generational loss, like mp3 and similar codecs do for audio.

/Øyvind K.

Date: Sun, 08 Jul 2007 11:44:17 +0200 From: gg@catking.net

On Sun, 08 Jul 2007 07:22:24 +0200, Guillermo Espertino 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 the first time you hit > CTRL+S.

I think we're finally getting closer to the truth. There is something non standard in the file the camera is producing. It seems that PS knows there's a problem and thus prompts for the quality parameter, gimp it would seem is either reading this value as the IJG quality when it isn't or is applying a not too good default when it fails to read it.

If it's an incorrect value put in by the camera that gimp is correctly reading it's not a gimp issue. If it is a missing value gimp should probably use it's jpeg default of 85 (or prompt as you suggest) which it does not seem to be doing.

If you have imagemagick installed, use the following to see what information is in one of your camera images before you affect it with either gimp or ps and then again after gimp (and/or PS) does a save on it:

identify -verbose unadulterated_image.jpeg

That should give some info on what is in the jpeg header.

This appears to be the case. The original image gives me this:

$ identify -verbose /images/dcim/193canon/img_9309.jpg Image: /images/dcim/193canon/img_9309.jpg ...
Filesize: 2.96358mb
...
Compression: JPEG
Quality: 98
Orientation: LeftBottom
JPEG-Colorspace: 2
JPEG-Sampling-factors: 2x1,1x1,1x1

However, when I save it out, it's clearly not using the original quality setting:

$ identify -verbose /tmp/img_9309.jpg Image: /tmp/img_9309.jpg
...
Filesize: 901.654kb
...
Compression: JPEG
Quality: 85
Orientation: TopLeft
JPEG-Colorspace: 2
JPEG-Sampling-factors: 2x2,1x1,1x1

If I explicitly save it out using the same settings as what came from the file, I wind up with a slightly shrunk file:

$ identify -verbose /tmp/img_9309.jpg Image: /tmp/img_9309.jpg
...
Filesize: 2.65972mb
...
Compression: JPEG
Quality: 98
Orientation: TopLeft
JPEG-Colorspace: 2
JPEG-Sampling-factors: 2x1,1x1,1x1

Note that GIMP is not the only application that does this; KPhotoAlbum also changes the quality setting (to 75!). In this case, I suspect that it simply doesn't tell the appropriate library what the actual quality setting is from the original file.

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 a lossy operation, there is no way to save the file with the same quality again.

Sven

On Sun, 08 Jul 2007 14:35:30 +0200, Sven Neumann 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 JPEG, then the original quality factor is completely irrelevant. You are doing a lossy operation, there is no way to save the file with the same quality again.

Sven

It would seem reasonable to assume that if the user has selected a size/quality trade-off given by a specific value, say, quality=98 he does not want to have to explicitly remake that decision every time he touches it.

Also this info I part of the header and part of specification of that file so arbitarily changing it would seem to me to be a spec violation.

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?

Thx.

Hi,

On Sun, 2007-07-08 at 14:53 +0200, gg@catking.net 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 were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. Thus it is better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this.

Sven

On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann wrote:

Hi,

On Sun, 2007-07-08 at 14:53 +0200, gg@catking.net 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 were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway.

I'm sorry I find that a rather forced logic. As we have seen the image will not be _identical_ due rounding errors and such , that does not make the existing choice of jpeg_quality "irrelevant". It represents the users choice of size/quality trade-off.

I see no justification to discard that choice as irrelevant.

File | Save should save the image as it is. Save_As is there as a means to change things.

Gillermo's real world example where the file size shrank by a factor of two and the quality took a serious hit can hardly be described a straight-forward save. It's doing a major change to the image and changing the compression parameters (quality and sampling_factor!), this should only happen through the Save_As with a full dlg.

Thus it is
better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this.

Sven

Allowing the user for redefine the default is fine but I see no bearing on this issue. This is not a lifestyle choice it's a per image choice. It's irrelevant to this discussion.

I'd always assumed that the default 85 only applied to untitled images on the first save not that it was silently forced on an unwary public as some sort of hidden "gimp knows best" feature.

Abritarily throwing away half the image data without so much as a 'by your leave' , incredible.

I'm really surprised that you dont see this as a bug.

I would ask you to seriously consider if this is appropriate. Please take time to reflect on this before replying and preferable sound out a few other opinions.

Thanks for the reply. /gg

From: Sven Neumann
Date: Sun, 08 Jul 2007 15:12:03 +0200

On Sun, 2007-07-08 at 14:53 +0200, gg@catking.net 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 were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. Thus it is better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this.

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" the result), but the quality setting could be treated as the user's expectation for the result.

It's certainly true that a couple of iterations of saving at a quality setting of 85 (say) will yield a substantial degradation, and a couple of iterations at 65 will yield even more degradation, but a couple of iterations at a setting of 98 won't yield very much degradation at all.

By this reasoning, if a user opens a file with a quality setting of 98, her expectation when saving the file is that the quality will still be very high, while if the quality setting of the incoming file is only 85, her expectations will be lower. A single default setting won't cover all cases.

If the choice really is that arbitrary (and you make a good argument to that effect), why not simply use the quality setting of the incoming file as the implied default? I think it would at least align better with user expectations, particularly for files shot at high quality settings on digital cameras.

BTW, on the Canon S3, the Superfine, Fine, and Normal settings correspond to 96, 90, and 68 respectively. So anyone who shoots in one of those two settings and then decides to do a quick edit will get a rude surprise.

On 7/8/07, gg@catking.net wrote:

On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann wrote:

Hi,

On Sun, 2007-07-08 at 14:53 +0200, gg@catking.net 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 were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway.

I'm sorry I find that a rather forced logic. As we have seen the image will not be _identical_ due rounding errors and such , that does not make

The image may well be quite unlike the input due to lossy compression -- see below.

the existing choice of jpeg_quality "irrelevant". It represents the users choice of size/quality trade-off.

I see no justification to discard that choice as irrelevant.

AFAICS, Sven is saying that it is irrelevant, because it is *impossible* to numerically represent the overall quality of the image to be saved. The quality setting of the input file, assuming that it is correctly calibrated to the IJG scale, would be multiplicative: when you save a jpeg file with quality 75, you are saying 'throw away a certain amount of the image data' -- and saving it again with quality 75, you are saying 'discard that much again'. You can't save with the same quality, because you've already thrown away much of the data that was used to create the first JPEG.

Actually getting a quality that is notionally '75% of full detail' when saving a jpeg output from a jpeg input, is trial and error -- so really, presenting a preview would improve the situation.

As for the practice of saving jpg outputs from jpg inputs, my personal experience has been that it's a BAAAAD thing; basically the only two possibilities are
a) Image mutilation
b) filesize inflation (ie. you can preserve quality.. by choosing something that effectively renders JPEG's compression ineffective (quality = 96 or above, IME)
-- this often inflates the filesize beyond that of lossless image formats like PNG.)
About the only thing GIMP could do to help here, is to warn the user if they are saving a jpeg file and the image was originally loaded from a jpeg file.

Sven Neumann schreef:

Hi,

On Sun, 2007-07-08 at 14:53 +0200, gg@catking.net 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 were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. Thus it is better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this.

Perhaps not a bug, but IMHO gimp's JPEG handling violates the principle of least surprise. I had a quick look at the source code and found out that the quality setting (and other parameters) are saved in a global variable jsvals, which is initialized with the default values (85 for the quality), but gets overwritten after "save as":

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
-> b.jpg is saved with quality 55 instead of 85!!

Wouldn't it be better if gimp acted in one of those two ways: 1. always save with the default quality, except when "save as" is used. 2. read the quality when loading a jpeg, and used that to save the image (if "save as" is not used).

Date: Mon, 9 Jul 2007 00:26:21 +0930 From: "David Gowers"

On 7/8/07, gg@catking.net wrote: > On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann wrote: >
> > Hi,
> >
> > On Sun, 2007-07-08 at 14:53 +0200, gg@catking.net 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 were used to encode it are irrelevant since encoding it > > again as a JPEG file would not yield the same image anyway. >
> I'm sorry I find that a rather forced logic. As we have seen the image > will not be _identical_ due rounding errors and such , that does not make

The image may well be quite unlike the input due to lossy compression -- see below.

The question to my mind is what's going to be closest to the user's expectations in terms of quality and size, not what's going to be pixel for pixel identical. When saving (or, I'd argue, exporting) an image from a lossless format (png, or even more so xcf) to a lossy format, we can really only guess, and in that case having a settable default is good. However, when we're working with JPEG files, we have a bit more information about what the user likely wants, based on the quality setting and perhaps the file size.

> the existing choice of jpeg_quality "irrelevant". It represents > the users choice of size/quality trade-off. >
> I see no justification to discard that choice as irrelevant.

AFAICS, Sven is saying that it is irrelevant, because it is *impossible* to numerically represent the overall quality of the image to be saved. The quality setting of the input file, assuming that it is correctly calibrated to the IJG scale, would be multiplicative: when you save a jpeg file with quality 75, you are saying 'throw away a certain amount of the image data' -- and saving it again with quality 75, you are saying 'discard that much again'. You can't save with the same quality, because you've already thrown away much of the data that was used to create the first JPEG.

Sure, but if the image was originally saved at quality 98, and then you resave it at 75, you're going to wind up with a lot more artifacts, which would be a surprising result if you don't understand how JPEG works. If the original image was saved at 60, and you resave it at 98, you might wind up with a much bigger image (I'm less certain of that), which is also not what I think would be expected.

The issue at hand is a special, but IMHO important, case -- a very high quality JPEG gets minor edits (perhaps to remove redeye or the like) and resaved; the result is *markedly* lower quality because the default of 85 is much less than the original.

Actually getting a quality that is notionally '75% of full detail' when saving a jpeg output from a jpeg input, is trial and error -- so really, presenting a preview would improve the situation.

As for the practice of saving jpg outputs from jpg inputs, my personal experience has been that it's a BAAAAD thing; basically the only two possibilities are
a) Image mutilation
b) filesize inflation (ie. you can preserve quality.. by choosing something that effectively renders JPEG's compression ineffective (quality = 96 or above, IME)
-- this often inflates the filesize beyond that of lossless image formats like PNG.)

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 degradation.

About the only thing GIMP could do to help here, is to warn the user if they are saving a jpeg file and the image was originally loaded from a jpeg file.

That would be a good idea, but I believe that there are at least some common cases where it's possible to do a bit better.

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 the image. I don't know if that has changed, but I assume that it hasn't.

Sven

On Sun, 08 Jul 2007 19:55:30 +0200, Sven Neumann 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), libjpeg didn't allow us to read the JPEG quality factor that was used to save the image. I don't know if that has changed, but I assume that it hasn't.

Sven

thanks , that explains why it was done this way. Probably ought to be checked, hopefully they've made a bit of progress in the intervening time.

imagemagick seems to have no trouble getting this info and it does depend on jpeg pkg.

Of course if there is an inadequacy in jpeglib they may have worked around it by reading the file header anyway, I'm pretty sure it's readily available.

/gg

On Sun, 08 Jul 2007 17:53:59 +0200, Robert L Krawitz 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 degradation.

Thanks,

I suspect that could be the result of some of the less important parameters getting a similar default, the encoding method (int/fp) or simply the algorithm efficiencies.

eg An earlier post indicated Jpeg:sampling-factor also changed from 2x1,1x1,1x1 to 2x2,1x1,1x1.

/gg

On Sun, 08 Jul 2007 17:37:28 +0200, Roel Schroeven 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
-> b.jpg is saved with quality 55 instead of 85!! Wouldn't it be better if gimp acted in one of those two ways: 1. always save with the default quality, except when "save as" is used. 2. read the quality when loading a jpeg, and used that to save the image (if "save as" is not used).

thanks for digging that out.

is that from todays svn, Sven committed a patch earlier today that may affect that.

the default setting now settable by the user (thanks Etienne). see bug #63610

gg@catking.net schreef:

On Sun, 08 Jul 2007 17:37:28 +0200, Roel Schroeven 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
-> b.jpg is saved with quality 55 instead of 85!! Wouldn't it be better if gimp acted in one of those two ways: 1. always save with the default quality, except when "save as" is used. 2. read the quality when loading a jpeg, and used that to save the image (if "save as" is not used).

thanks for digging that out.

is that from todays svn, Sven committed a patch earlier today that may affect that.

I first tried with gimp/trunk from svn revision 22893 (from 2007-07-06 22:47:44 +0200); I now tried it again with svn revision 22902 (from 2007-07-08 17:34:25 +0200), which presumable includes the patch you mention; the behavior I described is still the same.

the default setting now settable by the user (thanks Etienne). see bug #63610

I haven't tried changing the defaults to see if that changes anything.

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?

Because you are using JPEG despite better knowledge that it will do exactly that. Sorry for the harsh tone, but I am only replying the way you are putting it.

I already explained that the JPEG plug-in cannot access the settings that were used to save the file. We can also not easily change the code to always show the settings dialog because then we would have to do show the dialog for all file plug-ins. There might be a way out of this, but there is certainly not an easy one. So please calm down and let the developers deal with this. After all this is a developer list. Your harsh comments are not helpful.

Sven

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 user-configurable, default values. Of course if the "jpeg-save-options" parasite is set on the image that is being saved, then those values should be used. As far as I can see now, this means removing a single line in jpeg.c. I will have a closer look tomorrow morning.

Sven

On Sun, 08 Jul 2007 23:48:28 +0200, Sven Neumann 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 taken at 95, open it and save it, and it ends up at 85. Why is that?

Because you are using JPEG despite better knowledge that it will do exactly that.

He knew it was potencially a lossy format but he was using a very high quality setting, he did not know gimp would arbitarily change down the quality and wreck his image. jpeg at 98 looses hardly loses any quality visually.

To be fair you should be accurate, what he did was sensible and should not have produced the results it did.

You almost seem to be saying that anyone who uses jpeg is a fool so it doesn't matter if gimp destroys their work.

Sorry for the harsh tone, but I am only replying the way you are putting it.

Well he has been very patient and has had to repeatedly post to get us to see what he was reporting was not PEBKAC. I would hardly criticise a bit of polite annoyance on his part.

It was hard to believe at first that gimp would wreck an image like this. Let alone that it should be considered a feature.

I already explained that the JPEG plug-in cannot access the settings that were used to save the file.

That is not accurate. Imagemagick does it , gimp can. If libjpeg still cant do this ( to be verified ) then another way to read the file header needs to be found. It's not complicated.

We can also not easily change the code to always show the settings dialog because then we would have to do show the dialog for all file plug-ins.

Agreed , that's probably not the correct solution.

Sven

Thanks for bringing this up Guillermo , and thanks for having the perseverance to keep posting until we got what was really happening. Hopefully we will work out a better way to deal with this.

Once we're all agreed this is not very satisfactory we will certainly come up with a solution.

Oof, it's been a busy one. Goodnight!

From: Sven Neumann
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 a picture taken at 95, open it and save it, and it > ends up at 85. Why is that?

Because you are using JPEG despite better knowledge that it will do exactly that. Sorry for the harsh tone, but I am only replying the way you are putting it.

Sven, I do think you're being unreasonably hard on Guillermo. Never mind that using JPEG per se won't "do exactly that" -- what's really degrading the quality so badly is GIMP's choice of a quality factor compared to that of the original JPEG. Not to mention that I think Guillermo is being quite reasonable.

A lot of people (particularly folks who just casually want to lighten a shot or remove redeye) don't know it. All they know is that they have a picture that their camera took, they've corrected it, and all of a sudden the image quality fell apart. They don't know anything about JPEG's, or compression (lossy or otherwise), all they know is that GIMP ruined their photo. That's not going to be very helpful to anyone.

I already explained that the JPEG plug-in cannot access the settings that were used to save the file. We can also not easily change the code to always show the settings dialog because then we would have to do show the dialog for all file plug-ins. There might be a way out of this, but there is certainly not an easy one. So please calm down and let the developers deal with this. After all this is a developer list. Your harsh comments are not helpful.

Well, as was noted ImageMagick is able to access this information, so it's apparently there. Maybe this isn't going to be an easy problem to solve, and that's OK, but I think that this is a real problem, not simply a user error (and even if it is a user error, wouldn't it be best to help users not make this kind of error?).

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 "quantization tables". A quantization table is a table of 64 8- or 16-bit integers. (Typically 8-bit values are used.)

Typically, one such table is used for the "Y" channel (luminance, i.e. "B&W" information) and another for the Cb and Cr channels (colour information). These tables are actually stored inside each JPEG image.

(There are not some standard one(s) that would implicitly be referenced to by some single index that would say "use standard table 1" or something like that. In retrospect, that might have been a good idea I think.)

I.e. what actually determines the lossiness and "loss style" of the compression, what information is thrown away, are 128 (or just 64, or even 192) numbers (!). Not a single quality value.

(It is in fact even possible to use different quantization tables for different parts of an image, I think. I have no idea how common such JPEG images are, and if any software in common use produces such.)

The single quality value 1..100 that GIMP uses is passed to libjpeg's jpeg_set_quality() function. This function is used to scale two sample quantization tables given in the JPEG specification. But nothing forces some application to use linear scalings of these sample quantization tables. I don't know if the sample tables are even normative in the standard, or just informative.

One might imagine some application even doing a clever analysis of an individual image to come up with image-specific quantization tables.

The website
http://www.impulseadventure.com/photo/jpeg-quantization.html seems to have a good collection and comparison of quantization tables used by different firmware and software implementations of JPEG compression.

http://markcox.googlecode.com/svn/trunk/jpegdump/jpegdump/ has sources to a nice program one can dump the contents of a JPEG file, if one wants to have a look at the quantization tables used.

There is another program with the same name at http://www.programmersheaven.com/download/17054/download.aspx that is less useful in general, but has one nice feature: it attempts a guess at the libjpeg-style quality factor used for the quantization tables.

--tml

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 some setting of jpeg_set_quality(), it would be nice if GIMP remembered that as the default quality to use for the file. Or something like that... 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.

--tml

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-opt-an-efficient.pdf

--tml

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 surprise when they casually open/modify/save a JPEG file.

Graeme Gill.

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 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. Then later, he saved another image, which didn't have the parasite set. And for that image, the low quality parameters from the last invocation of the JPEG plug-in have been used. This is the expected behavior for all plug-ins. But we might want to make an exception for JPEG because of its potentially destructive nature.

Sven

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 that is being saved, then those values should be used. As far as I can see now, this means removing a single line in jpeg.c. I will have a closer look tomorrow morning.

I found a better solution. The JPEG plug-in will now prompt the user with a dialog, even if called from the "Save" action, iff the image does not have the "jpeg-save-options" parasite set. This is basically what Guillermo suggested earlier. I said it would be difficult to implement but it turned out that it was quite easy and doesn't require changes to the file plug-in infrastructure.

The change is in SVN and I think we can settle this issue now. If someone wants to try to recover some of the JPEG save settings when loading the JPEG file, feel free.

Sven

On Mon, 09 Jul 2007 08:14:29 +0200, Sven Neumann wrote:

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 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. Then later, he saved another image, which didn't have the parasite set. And for that image, the low quality parameters from the last invocation of the JPEG plug-in have been used.

That certainly would happen and is part of the issue. Hwvr, in his case (confirmed by two other posters) it was a high setting being replaced by the default of 85, so it was not even a little bit his fault it was gimp.

This is the expected behavior for all plug-ins.

Yes in general its good, if I chose png compression of 9 I dont want to have to reset that value on very invocation of the dlg.

But two cases need to be destinguished: Save and SaveAs. I would suggest that Save should _always_ retain the current settings of the image be it jpeg , png or whatever. Save should do just that, not start redefining things.

In the case of png this is a minor annoying defect that can be remedied later but the same principal applies.

But we might want to make an exception for JPEG because of its potentially destructive nature.

Sven

OK, so everyone agrees this is unacceptable for jpeg. I would suggest that all formats preserve all parameters when in non-interactive , ie Save. This means less exceptions and predictable results and common code path.

Where there is a need for special treatment is SaveAs. Because of the destructive effects the dlg should come up with the image's existing quality param for jpeg o/w the user will never know what it needs to be even if he is fully aware and wants it to remain the same.

Other formats it would be nice (usabiliy) to take last used , user's default being used when no value is available (that's what default means in fact) ie on a new image or on format change.

I think we need to let jpeg lead the dance here since it can be destructive and irreversible.

A good way to present all this in a common format with no potentially confusing ifs and buts would be to add a radio button choice to all plugin dlgs [ Default | Current | Last-used ] defaulting to last used as dictated by jpeg but the user is never more than one click away from a clear choice between the three cases.

I know you dont like more controls but this seems the only to be consistant and clear. Making choices that do different things behind the users back depending on image format can only be confusing.

Anyway, that is something of side issue. The main defect that need fixing directly is the non-interactive case.

I think Save should do nothing fancy and should be the same for all. Simple, predictable and non destructive. It should preserve existing setting for all formats.

We should probably focus on that before discussing SaveAs.

Also minor coding effort , we just need to dig out jpeg_quality from somewhere.

/gg

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. (Which happens when the loaded image's quantization tables exactly match the JPEG standard's sample tables scaled in libjpeg's manner with said factor).

I mean cases where the entire image contents has been replaced with a fresh (original quality) one. Or if the image has been scaled down. Or if some filter(s) that modifies all of the image substantially has been applied to the whole image. In cases like these it perhaps doesn't make sense to blindly re-use the original jpeg file's quality factor, but one should let the user decide.

Maybe a good heuristic would be only use the original quality factor if available to increase the user's default setting, never decrease it. Show the settings dialog, as in current SVN, and if there is a guesstimated scale factor from the original image and it is better than the one in the user's default jpeg settings, use that initially in the dialog instead of the default.

Anyway, I think that to really be able to to advanced tricks, the jpeg saving needs to re-decompress the original image while saving the new version. When it makes sense it should reuse the exact same quantization tables and subsamplig parameters. Then it could do tricks like avoid recompression artefacts for blocks that haven't changed. That would be really cool. One could load and save a JPEG image as much as one likes, just touching up small parts here and there (like correcting red-eye), with no quality degradation for the rest of the image.

BTW, is there any reason to keep the "DCT method" choice? Why not just use floating-point always? Is there any significant speed difference on modern machines?

--tml

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.

Index: plug-ins/jpeg/jpeg-load.c =================================================================== --- plug-ins/jpeg/jpeg-load.c (revision 22905) +++ plug-ins/jpeg/jpeg-load.c (working copy) @@ -50,6 +50,61 @@
gint32 layer_ID_global;


+static gboolean
+check_table (const JQUANT_TBL *file_table, + gint quant_tbl_no, + gint *quality) +{
+ int i;
+ gboolean all_ones = TRUE;
+ gint q;
+ struct jpeg_compress_struct cinfo; +
+ /* First do the simple check for quality 100, a table with all ones */ + for (i = 0; i < 64; i++)
+ {
+ if (file_table->quantval[i] != 1) + all_ones = 0;
+ }
+
+ if (all_ones)
+ {
+ *quality = 100;
+ return TRUE;
+ }
+
+ /* Then produce tables for all qualities 1..99 and compare. It's + * better to do it this way than to calculate the quality factor + * backwards from the table in the file because of rounding errors: + * We would never match all quality factors exactly. + */
+ for (q = 1; q < 100; q++)
+ {
+ jpeg_create_compress (&cinfo); +
+ jpeg_set_quality (&cinfo, q, TRUE); +
+ for (i = 0; i < 64; i++)
+ {
+ if (cinfo.quant_tbl_ptrs[quant_tbl_no]->quantval[i] != file_table->quantval[i]) + break;
+ }
+
+ jpeg_destroy_compress (&cinfo); +
+ if (i == 64)
+ break;
+ }
+
+ if (q < 100)
+ {
+ *quality = q;
+ return TRUE;
+ }
+
+ return FALSE;
+}
+
gint32
load_image (const gchar *filename,
GimpRunMode runmode,
@@ -57,6 +112,7 @@
{
GimpPixelRgn pixel_rgn;
GimpDrawable *drawable;
+ GimpParasite *parasite;
gint32 volatile image_ID;
gint32 layer_ID;
struct jpeg_decompress_struct cinfo; @@ -76,6 +132,8 @@
GimpParasite * volatile comment_parasite = NULL; jpeg_saved_marker_ptr marker;
gboolean found_exif = FALSE;
+ gint q0, q1, q2;
+ gint quality = -1;

/* We set up the normal JPEG error routines. */ cinfo.err = jpeg_std_error (&jerr.pub); @@ -153,6 +211,32 @@

(void) jpeg_read_header (&cinfo, TRUE);
+ /* Check if the quantization tables used are produced by libjpeg's + * jpeg_set_quality().
+ */
+
+ if ((cinfo.jpeg_color_space == JCS_GRAYSCALE && + check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[0].quant_tbl_no], + cinfo.comp_info[0].quant_tbl_no, + &q0)) ||
+ (cinfo.jpeg_color_space == JCS_YCbCr && + check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[0].quant_tbl_no], + cinfo.comp_info[0].quant_tbl_no, + &q0) &&
+ check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[1].quant_tbl_no], + cinfo.comp_info[1].quant_tbl_no, + &q1) &&
+ q0 == q1 &&
+ (cinfo.comp_info[1].quant_tbl_no == cinfo.comp_info[2].quant_tbl_no || + (check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[2].quant_tbl_no], + cinfo.comp_info[2].quant_tbl_no, + &q2) &&
+ q1 == q2))))
+ {
+ /* Yes. Store the quality in a parasite below. */ + quality = q0;
+ }
+
/* We can ignore the return value from jpeg_read_header since * (a) suspension is not possible with the stdio data source, and * (b) we passed TRUE to reject a tables-only JPEG file as an error. @@ -257,6 +341,14 @@
layer_type, 100, GIMP_NORMAL_MODE); }

+ if (quality > 0)
+ {
+ parasite = gimp_parasite_new ("jpeg-original-quality", + 0, sizeof (gint), &quality); + gimp_image_parasite_attach (image_ID, parasite); + gimp_parasite_free (parasite); + }
+
drawable_global = drawable = gimp_drawable_get (layer_ID); gimp_pixel_rgn_init (&pixel_rgn, drawable, 0, 0, drawable->width, drawable->height, TRUE, FALSE); Index: plug-ins/jpeg/jpeg.c
=================================================================== --- plug-ins/jpeg/jpeg.c (revision 22905) +++ plug-ins/jpeg/jpeg.c (working copy) @@ -428,6 +428,23 @@
* over the JPEG encoding parameters. */
run_mode = GIMP_RUN_INTERACTIVE; +
+ /* If we have stored an estimate of the libjpeg quality + * factor used when creating the original image, and + * that is larger than the default quality, use it as + * default for the dialog. + */
+ parasite = gimp_image_parasite_find (orig_image_ID, + "jpeg-original-quality"); + if (parasite)
+ {
+ gint quality;
+ memmove (&quality, gimp_parasite_data (parasite), sizeof (gint)); + gimp_parasite_free (parasite); +
+ if (quality > jsvals.quality) + jsvals.quality = quality; + }
}
break;
}

On Mon, 9 Jul 2007 17:32:29 +0300, Tor Lillqvist 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 chroma subsampling method (easy) and for images that do not use the standard IJG tables (a bit harder, but it can be guesstimated).

This would provide a better default value in the JPEG Save dialog than the hardcoded value that we currently have (even if that value can be customized to some extent). I also like the fact that it will only use the estimated value from the file if it is larger than the default. It is nice to be able to adjust the parameters in the Save dialog starting from a value that is reasonably close to the original settings when the file was created, instead of always starting from a fixed value.

-Raphaël

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 of files, and that it is OK to save intermediate files in these formats.

The import part means that when you open a jpeg, you get a GIMP file. original_filename.xcf, it says in the title bar. Press save the first time after import and you get a 'save as' dialog with the location of the original jpeg and that original_filename.xcf as defaults.

now you have a workflow in full fidelity.

The export part means that jpeg and other lossy formats are not available for Save (as), but only under an explicit Export command.

After an export to jpeg, you are still working on the GIMP format file.

I have hard time believing that the reason a file is jpeg on your camera memory card is the same as being jpeg at the end of your workflow in GIMP. Afterwards it is about saving space on your disk or saving bandwidth on the internet. Different requirements == different quality factor, I say.

--ps

principal user interaction architect man + machine interface works

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

On Mon, 9 Jul 2007 17:54:29 +0200, peter sikking 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 significantly break the flow for what must be the most common image format for photography. I prefer the current behavior in SVN, in which you get the dialog for the first time you select Save, but subsequent saves of the same image (while you are still working on it) will not force you to pick a new file name and validate the parameters again.

I have hard time believing that the reason a file is jpeg on your camera memory card is the same as being jpeg at the end of your workflow in GIMP. Afterwards it is about saving space on your disk or saving bandwidth on the internet. Different requirements == different quality factor, I say.

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. I kept them all as they came out of the camera. But some of them required editing, such as removing red eyes or correcting obvious color casts. In these cases, I stored the edited images next to the originals (with a slightly different file name like "dsc0042_edited.jpg") and I was interested in getting files that were about the same quality and size as the unedited ones so that they somehow fit in my collection. Making them "fit" (having similar size/quality tradeoff) is not really a major concern, but I still took the time to experiment a bit with the sliders until I found out that for most of my photos, using a setting around 92-94 was reasonably close to what the camera produced. This value did not work for all photos because some of them were shot with different camera settings, but at least that was a good estimate for most of them.

If the patch provided by Tor was extended to support quantization tables produced by other software than libjpeg (by finding the closest match), then it would reduce the amount of guesswork.

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 ImageMagick-6.3.5/coders/jpeg.c, around line 830. It is based on a comparison of the difference produced by the quantization tables in the file with the 100 possible tables produced by libjpeg. If no exact match is found, then the closest one is selected. They use pre-computed hashes and sums for the libjpeg tables in order to speed up the comparisons. The license of ImageMagick is compatible with the GPL so we could even consider re-using their code. We would only have to include their license with the jpeg plug-in.

-Raphaël

Von: "Raphaël Quinet"

On Mon, 9 Jul 2007 17:54:29 +0200, peter sikking 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 significantly break the flow for what must be the most common image format for photography. I prefer the current behavior in SVN, in which you get the dialog for the first time you select Save, but subsequent saves of the same image (while you are still working on it) will not force you to pick a new file name and validate the parameters again.

This doesn't contradict what peter is suggesting. AFAIK we intend to "break the flow" for anything but XCF(.*). A "save" should always do what the term "save" claims to do, it should not damage the file.

Why do you assume that export will ask for all of the parameter settings again?

HTH, Michael

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 ImageMagick-6.3.5/coders/jpeg.c, around line 830. It is based on a comparison of the difference produced by the quantization tables in the file with the 100 possible tables produced by libjpeg. If no exact match is found, then the closest one is selected. They use pre-computed hashes and sums for the libjpeg tables in order to speed up the comparisons. The license of ImageMagick is compatible with the GPL so we could even consider re-using their code. We would only have to include their license with the jpeg plug-in.

If it can improve a common workflow, it's probably worth it. Please use the code from ImageMagick then as it should be well tested already. And please place this code into a separate file in the plug-ins/jpeg folder.

Sven

Hi,

On Mon, 2007-07-09 at 09:42 +0200, solar@piments.com 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 name is somewhat impolite. If you have good reasons to do this, then feel free to continue doing it though.

well that's at least taken the heat off the issue . Less than ideal from interface point of view since it's a dlg every time but at least it's a resolution until we find where to get the quality param.

The dialog should stay even if we can access the quality settings used when saving the file. Tor outlined the reasons in a different mail in this thread.

Sven

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" the result), but the quality setting could be treated as the user's expectation for the result.

Just a stupid user here, but interested in this thread since it is something I do all the time. I have Shift-S configured to change the image size, and of course Ctrl-S is by default configured to save file. I can't remember how many times I have hit the Ctrl by mistake, and now am quite distressed to understand that the image which I uploaded from my camera and then deleted from the memory card has now been degraded to a different quality than it was.... Definitely a bug, not a feature, IMHO.

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....

I am so glad that Guillermo stuck by his guns and apparently *finally* got the developers to realise the illogic of this "feature". If more of us users would be as persistent instead of just going away after the initial knee-jerk "you don't know enough to even be talking to us" response which seems too prevalent here, maybe the Gimp would become all that it can be.

Scott Swanson

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 plug-in library should have. The file plug-in library we would like to port all our file plug-ins to. If you are so much interested in this, perhaps want to offer your help with this task?

I am so glad that Guillermo stuck by his guns and apparently *finally* got the developers to realise the illogic of this "feature". If more of us users would be as persistent instead of just going away after the initial knee-jerk "you don't know enough to even be talking to us" response which seems too prevalent here, maybe the Gimp would become all that it can be.

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.

I don't see the point in your mail. We listened to Guillermo and his issue was addressed in almost no time. It was absolutely not needed to stick to any guns.

We are working very hard to finally get 2.4 out and because we are taking this very seriously, we are in this pre-release mode for a long time already. It would help a lot if we could concentrate on the important things now which is to bring out GIMP 2.4. The users could finally benefit from the hard work the developers have put into GIMP over the last years. Perhaps than the users would finally realise that a lot is happening to make GIMP better and easier to use.

Can we settle this now and get back to work? Thanks.

Sven

On Mon, 09 Jul 2007 19:32:14 +0200, Sven Neumann 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 that it's not posting from my account. These errors dont make it to the mailing but do go to any cc . Sorry for any inconvenience that may or may not cause.

Having to create three different gg g2 g4 accounts and all the fuss to get that rectified was also inconvinient when "someone" decided I was persona non grata without the politeness to even notify me of the decission. Neither did I get any explaination or appology it just got unblocked.

Now my gimp messages are spread over three accounts. Some things we have to live with.

Thanks for the reminder, it annoys me when I mess it up but it was late lastnight and one of the ten or so messages I sent yesterday got the wrong account. Will try harder ;)

/gg

On Mon, 09 Jul 2007 17:54:29 +0200, peter sikking 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 dont think this is a good idea , despite it shortcoming in certain respects this is probably the most commonly used format for photo images. Not being able to save a jpeg will cause great confusion.

IMHO this is not one of your better suggestions.

This would prevent the misunderstanding that there is a continuous lossless workflow for these type of files, and that it is OK to save intermediate files in these formats.

As has been suggested already, a first time warning with a "dont show again" option would be good in making users aware of the issue. After that I really object this "we know best , you should do it this way so we will force you to if you're too dumb". This is the classic Microsoft approach and why I changed to OSS over 5 yrs ago. Please dont try to do this to Gimp.

Considering Gimp was screwing up jpegs until last nights svn change , ie millions of installation on all platforms still does that even on the fresh 2.3.16 , we'd better go easy on the arrogant "we know better, you will do it like this" approach.

Some ppl may wish to do one or two saves knowing the limitations and choosing suitable quality. Gimp is a tool not a tutorial. We should not get in the way.

The only step I see as acceptable here is the warning, this would be a great help to less seasoned users who are not aware of this limitation. It's simple to add and would be a worthwhile improvement.

/gg

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 nothing wrong with that. It's even on the list of things that the file plug-in library should have. The file plug-in library we would like to port all our file plug-ins to. If you are so much interested in this, perhaps want to offer your help with this task?

Well, if I had any development skills, I'd be more than happy to do so. I used to enjoy writing code for totally text-based programs under cpm and msdos, and still write some for linux, but graphics-based programming is a bit beyond me. I tried once to compile the Gimp from SVN and failed miserably, so I doubt I'd be a good candidate, though certainly would be willing to help.

I am so glad that Guillermo stuck by his guns and apparently *finally* got the developers to realise the illogic of this "feature". If more of us users would be as persistent instead of just going away after the initial knee-jerk "you don't know enough to even be talking to us" response which seems too prevalent here, maybe the Gimp would become all that it can be.

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.

As I perceived the thread, Guillermo's approach would not take the fun out of anything. He merely was pointing out a serious problem with the way Gimp implements the 'save' as regards jpeg files; something a developer probably never thought of, but something with serious adverse consequences to a normal user.

I don't see the point in your mail. We listened to Guillermo and his issue was addressed in almost no time. It was absolutely not needed to stick to any guns.

And it did eventually get addressed, but only after an attempted brush-off or two. Read the thread.

We are working very hard to finally get 2.4 out and because we are taking this very seriously, we are in this pre-release mode for a long time already. It would help a lot if we could concentrate on the important things now which is to bring out GIMP 2.4. The users could finally benefit from the hard work the developers have put into GIMP over the last years. Perhaps than the users would finally realise that a lot is happening to make GIMP better and easier to use.

Don't get me wrong, we users *do* obviously appreciate all of the work you guys do, or we wouldn't be using the program on a daily basis. It's just that we often get the perception that when any suggestion is made on this list that something isn't quite working as it should, there is a "we know better than you do" attitude. I'm sure it isn't intentional?

Can we settle this now and get back to work? Thanks.

Fine by me.

Scott Swanson

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.

As I perceived the thread, Guillermo's approach would not take the fun out of anything. He merely was pointing out a serious problem with the way Gimp implements the 'save' as regards jpeg files; something a developer probably never thought of, but something with serious adverse consequences to a normal user.

I was refering to your reply which was discouraging and completely needless. And so was your second reply. The developers think of a lot more than you can imagine. And we keep listening to our users. A lot of us are actively monitoring user forums and user mailing-lists. The main reason that things are the way they are is that no one does the necessary changes. Asking the users to be more persistent with their requests is not going to help with that.

And no, Guillermos request wasn't brushed off. It is important to ask precisely and we have to be careful with changes. 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 double check if a request is valid and whether a change is really making things better for all users (or at least the target audience).

Sven

I was refering to your reply which was discouraging and completely needless. And so was your second reply.

sorry to bother.

The happy user is silent.

Is that from the Book of Tao, or what? I like it. I shall remain silent. The silent user is happy (or unhappy - who knows?).

Scott Swanson

On Mon, 09 Jul 2007 11:33:34 +0200, Tor Lillqvist 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 tables exactly match the JPEG standard's sample tables scaled in libjpeg's manner with said factor). I mean cases where the entire image contents has been replaced with a fresh (original quality) one. Or if the image has been scaled down. Or if some filter(s) that modifies all of the image substantially has been applied to the whole image. In cases like these it perhaps doesn't make sense to blindly re-use the original jpeg file's quality factor, but one should let the user decide.

OK let's ignore the repeated "blindly reusing" which presuposes this is a stupid thing to do.

If "the entire image contents has been replaced with a fresh (original quality) one" the user would presumably use saveAs. This seems rather an artificial case.

Or if the image has been scaled down. Or if some filter(s) that modifies all of the image substantially has been applied to the whole image.

The current choice of jpeg_quality is still a more appropriate choice unless the user selects SaveAs.

Seriously guys , let's stop trying to secoond guess what the user "should" be doing and let him get on with it.

Again Gimp is a tool not a tutorial.

Let's concentrate on getting the tool to work propery rather than telling the user which hand he's supposed to wipe his backside with.

Tor, since you are looking at this, checkout this code. It's a shareware Delphi component for jpeg with sourse. Now it's years since I was in there but I bought it and used it for several years. I am pretty sure that it picks out jpeg_quality as one of the object properties when it decodes an image.

The delphi component is copyright shareware but it clearly states that the original IJG C code used is not a payable item. In any case seeing where the jpeg_quality comes from may well be useful.

http://www.mwasoftware.co.uk/index.php?option=com_content&task=view&id=4&Itemid=7

HTH. /gg

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, and quickly stop using ^S. That way when you install a new gimp and accidentally lose your settings, you will already have stopped using ^S :)

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.

I wonder if it'd be possible, for gimp 2.6, to consider unifying the output plugins a bit, so that you can have a pull-down of file formats and see the parameters for each format before you hit save, and maybe even have printf-like stuff in the filename, e.g. to name the file mypicture-%Wx%H-%{quality}.%T or whatever.

But I think we can live without it for 2.4, for my part at least :-)

Liam

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

Quoting Sven Neumann :

... 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 double check if a request is valid and whether a change is really making things better for all users (or at least the target audience).

I am quite happy that the GIMP uses its own JPEG quality default (especially now that it can be modified). I would expect a File->Save to use the default I chose, not that attached to the image. 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.

IMO, the "File->Save" command should use the GIMP's default setting; but the ideal would be to have that default be one of the following options:

a. A specific quality value. b. The quality value of the original JPEG file, if applicable c. The greater of 'a' and 'b'
d. The original DCT coefficients, if available

I would not consider any of 'b', 'c', and 'd' to be improvements if 'a' were not available as an option.

On Mon, 09 Jul 2007 11:33:34 +0200, Tor Lillqvist 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 tables exactly match the JPEG standard's sample tables scaled in libjpeg's manner with said factor).

Why try and merely match the tables ? Use them by default. Only replace them if the user changes quality settings.

Graeme Gill.

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" command to retain *all* data: not just some. Just because most image editors throw away parts of your file, there's no reason for GIMP to follow suit (anyone ever play Lemmings?).

save != lose

I see recent activity on the 'Save for Web' dialog. Once completed, it should offer the user enough ways to publish a lossy image for end-use while retaining a lossless original image. Exporting is preferable to a "lossy save".

The solution of presenting the dialog on first save is a Good Thing (thanks Sven!). Having a lossless workflow is a Better Thing, and hopefully the direction of the future.

Chris

On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking 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 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.

Please dont distort this by taking one word out of context.

Gimp's aim to be a high-end image manipulation program does not mean everyone has to become a professional graphics artist.

I see no indication in Sven's vision for Gimp that it becomes an exclusively professional tool at the expense of all else.

Neither does starting every phrase with "high-end" make your arguements carry any more weight.

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.

That's one way of working for one type of result. I don't see why you think you can be so dogmatic, say this is the ONLY way to work and therefore wish to force everyone down that road.

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.

Again that's preferable in one way when absolute quality is the dominant criterium. Disk space and clutter may be another. Again you rather arrogantly presume to know what the user wants/needs and are going to shut down his options and make gimp do what YOU think is best for the user.

"High-end users" require powerful, flexible tools not one hand tied behind their backs by someone who think he know more about graphics than they do.

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 clearly you can work with jpeg doing intermediate saves (different filenames if wished) and maintaining a lossless copy in gimp until the final step.

You could also dupe the image and remain working in jpeg.

You can also save with high quality setting and sustain minimal lost where appropriate. Your legendry "high-end" user will know all this of course so he does not need you to limit the flexibility of his "high-end" tools.

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.

OK, so that's your basic attitude, anyone who does not agree with your limited view of the one and only "correct" way to work should stop using Gimp.

Tell 98% of the user base to go away because they're too mid-fi to use your super "high-end" software

I think you should stop this dictatorial approach, you are losing credibility as an interface architect.

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

On Tue, 10 Jul 2007 01:24:40 +0200, 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 because it already was that quality. Saving it a 95 would increase filesize by about a factor of 8 without any gain in quality! You would not have less loss.

If you want to change the nature of the image format user SaveAs.

Save should keep things the way they are as near as possible.

Some here seem to miss the meaning of the word default. It is a value to use by default, not all the time, ie when there is no way to get an actual value. ie a new unsaved image or jpeg save of another format.

Hopefully Tor's patch from Imagemagick should now provide a good jpeg_quality value from the image file.

/gg

On Tue, 10 Jul 2007 01:58:50 +0200, Graeme Gill wrote:

On Mon, 09 Jul 2007 11:33:34 +0200, Tor Lillqvist 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 tables exactly match the JPEG standard's sample tables scaled in libjpeg's manner with said factor).

Why try and merely match the tables ? Use them by default. Only replace them if the user changes quality settings.

Graeme Gill.

Yes, I agree. I think that would be an additional improvement to gimp's jpeg quality. It may be somewhat more work that just deciding what jpeg_quality we should be using. Although futher improvement of the way gimp handles jpeg may calm some of the "let's stop the user working with jpeg" crowd.

Certainly it would be prefeable to improve the jpeg quality rather than crippling gimp and restricting the user. (no pun intended)

/gg

On Tue, 10 Jul 2007 02:08:45 +0200, Chris Mohler 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 graphics you will know saving a jpeg does not save *all* your data and will make a choice as to whether the loss is acceptable or whether creating a much larger duplicate file is preferable.

Exporting is preferable to a "lossy save".

Says you. This is not always the case. It depends what is required.

Just because most image editors throw away parts of your file, there's no reason for GIMP to follow suit (anyone ever play Lemmings?).

I dont recall anyone having advanced that as an arguement. I really think we should stop exagerating this issue.

/gg

On 7/10/07, gg@catking.net wrote:

On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking 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.

Gimp's aim to be a high-end image manipulation program does not mean everyone has to become a professional graphics artist.

Nor has Peter suggested this. Take your own advice about not taking things out of context.
What was suggested is essentially to make the 'Save' action more truthful - in order to
a) Reduce confusion -- 'wait, every time I edit and resave this jpeg it gets worse. Why is that?'* -- by providing a standard editing format.
Throwing away data is a pathological case, which is why GIMP should only allow this by a plugin, rather than explicitly supporting it; it should, probably, be considered 'deprecated'.

b) Reduce corner cases (ie improve interface consistency) -- 'Save' shouldn't mean 'Lose.' in any case.
c) Adhere better to the basic Unix tenet of 'Don't throw data away unless explicitly commanded to.'

What is being proposed is both more effective for the general editing case, and more flexible.

I appreciate the compression benefits of JPEG for photos, but IMO on todays multi-gigabyte hard drives, saving a single uncompressed working image per image you work on is unlikely to be any significant resource drain.. even for huge images.

I want to mention the necessity of recording the original input image filename -- and maybe an action to 'Save over original'; I believe it hasn't been addressed yet, and I expect that someone like yourself would be satisfied by that. (I still think you should RTFM on the vision of gimp as high end graphics editor -- it was made by discussion with the GIMP team in-person.

http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project-overview.html http://gui.gimp.org/index.php/GIMP_UI_Redesign )

*as someone else already noted, any manipulation of large areas of the image is liable to cause further compression error, whether the compression parameters have been altered or not.

On 7/9/07, gg@catking.net wrote:

On Tue, 10 Jul 2007 02:08:45 +0200, Chris Mohler 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.

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".

Exporting is preferable to a "lossy save".

Says you. This is not always the case. It depends what is required.

It's just my opinion: save != lose

Just because most image editors throw away parts of your file, there's no reason for GIMP to follow suit (anyone ever play Lemmings?).

I dont recall anyone having advanced that as an arguement. I really think we should stop exagerating this issue.

It's a non-issue - we have enough experience to dodge the pitfalls of lossy formats. It's the status quo, and we live with it. My source files stay XCF, TIFF, or PNG and my web files end up JPEG or PNG. Such is life. I just wonder if it could be easier.

Chris

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 by the choice of JPEG as a file format, the user has already stated that their goal for this image is moderate file size over lossless storage. An application could therefore be considered to be behaving reasonably in processing such a file, if it introduced no noticeable additional degradation in quality. Since by the choice of the JPEG format image information has already been thrown away, a small additional loss of information is unlikely to be noticeable (ie. retaining similar or better quantization tables) and is consistent with the users implicit goals.

Defaulting to a lossless format when the original file is a JPEG could be seen as poor application behaviour, since it is contradicting the users implicit preferences.

Graeme Gill.

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 be) some options".

Maybe GIMP could do it the way CoolEdit (audio editor for windows) does it - when you save to a lossy format, it pops up a warning telling you that you shouldn't use that file for intermediate storage, but only for the final product.

Quoting gg@catking.net:

On Tue, 10 Jul 2007 01:24:40 +0200, 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 because it already was that quality. Saving it a 95 would increase filesize by about a factor of 8 without any gain in quality! You would not have less loss.

You presume that I have done nothing to improve the content of image. The file saved IS degraded relative to the image I am editing.

If you want to change the nature of the image format user SaveAs.

Save should keep things the way they are as near as possible.

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. If file size is your main concern, use Save For Web. If honoring the user's expectations with regard to image quality is your focus, Save should recognize user-specified default settings.

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 choices about which features to include and which not. Which workflows to actively support and streamline, and which go on the back seat. About beginners vs. Experts.

Sven did not set the product vision, the GIMP team did by consensus. I only moderated that session. But I am here to implement that vision on an user interaction level.

That means I make hard choices, based on the vision, the way thing work technically and our workplace observations.

--ps

principal user interaction architect man + machine interface works

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

On Tue, 10 Jul 2007 12:29:23 +0200, peter sikking 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 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 irrelevant after a while. On the other hand, having no vision at all or ignoring it and running like headless chicken is usually worse.

You make hard choices about which features to include and which not. Which workflows to actively support and streamline, and which go on the back seat. About beginners vs. Experts.

But one should always balance the interest of the few who are targeted by our product vision with the interest of the majority of the users who are not necessarily part of that vision. In other words, a decision that provides a small improvement for the target users but implies a significant regression for all other users should be considered very carefully.

Our current vision is rather elitist. This is not a bad thing because this is often the only way to make real progress. But we should also be aware of its consequences.

Sven did not set the product vision, the GIMP team did by consensus. I only moderated that session. But I am here to implement that vision on an user interaction level.

Again, to temper things a bit: this was only a subset of the developers present at LGM last year (GIMPCon 2006, see the minutes at http://developer.gimp.org/gimpcon/2006/ and read the section "GIMP Vision"). I hope that this was a representative subset of the GIMP contributors (of course it was, I was there!) but we should also keep in mind that nobody has absolute authority over the GIMP project. It is always possible for someone to propose someting that goes against the current consensus and hopefully convince others that this is the right thing to do.

This may be good or bad depending on the context (it should also be possible to stop useless arguments by saying that something is out of scope for GIMP). I am not judging the merits of the way we work, but just stating that this is something to keep in mind.

-Raphaël

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 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 irrelevant after a while. On the other hand, having no vision at all or ignoring it and running like headless chicken is usually worse.

I agree that a product vision, like a national policy, should be reviewed every, say, 5 years. Do realise that when you chance the the vision, that you restart, from zero, a process that takes about 5 years. And thanks for saying that ignoring the vision is worse.

You make hard choices about which features to include and which not. Which workflows to actively support and streamline, and which go on the back seat. About beginners vs. Experts.

But one should always balance the interest of the few who are targeted by our product vision with the interest of the majority of the users who are not necessarily part of that vision.

Few? there are millions of users within our vision out there. And if we work to make GIMP represent this vision coherently in the UI, then GIMP will become a viable, natural choice for the people we want to use it.

And I thought that we all understand that there is a choice of several free software programs out there for users who want to do simple red-eye removal from their holiday jpegs. We cannot make GIMP for them if we want to make it for the high-end market. One of them has the priority, and the other can use GIMP at their own risk.

It took me 5 second to agree with the maintainer of Krita to agree that GIMP and Krita are not competitors, they serve two different markets, and can happily live side by side.

In other words, a decision that provides a small improvement for the target users but implies a significant regression for all other users should be considered very carefully.

Actually in this case it the other way around. There is a significant improvement for target users, with clarification of image degradation of everyone, and little or no regression for the lossy-jpeg users.

Our current vision is rather elitist. This is not a bad thing because this is often the only way to make real progress. But we should also be aware of its consequences.

Well, you have chosen that GIMP is a fast driving machine, able to compete with the best. Do you mind that I try to focus us on that when the question is "what about going shopping?" or "what about taking driving lessons in our machine?"

Sven did not set the product vision, the GIMP team did by consensus. I only moderated that session. But I am here to implement that vision on an user interaction level.

Again, to temper things a bit: this was only a subset of the developers present at LGM last year (GIMPCon 2006, see the minutes at http://developer.gimp.org/gimpcon/2006/ and read the section "GIMP Vision").

This is a slippery slope. If anybody can excuse themselves from the vision when they personally do not like the logical outcome of applying it to a hairy UI design question, and bang in their "yeah, but what about me" feature into svn, then we are back at the headless chickens state.

Please, do not get cold feet when the law of nature that we cannot make everybody happy becomes apparent.

--ps

principal user interaction architect man + machine interface works

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

On Tue, 10 Jul 2007 16:32:11 +0200, peter sikking 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 irrelevant after a while. On the other hand, having no vision at all or ignoring it and running like headless chicken is usually worse.

I agree that a product vision, like a national policy, should be reviewed every, say, 5 years. Do realise that when you chance the the vision, that you restart, from zero, a process that takes about 5 years. And thanks for saying that ignoring the vision is worse.

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). Again, I am playing the devil's advocate here, just trying to counter-balance your argument: I agree with the vision and I think that we should all follow it; however, I also want to be realistic and not see it as a sacred thing that is cast in stone.

But one should always balance the interest of the few who are targeted by our product vision with the interest of the majority of the users who are not necessarily part of that vision.

Few? there are millions of users within our vision out there. And if we work to make GIMP represent this vision coherently in the UI, then GIMP will become a viable, natural choice for the people we want to use it.

Sorry, but I have to disagree here. If you just look at the part of the product vision that says "GIMP is ...", then it could apply to a large number of GIMP users. But if you look at the context of the vision (which is not explicitely written in that section, but is part of the "Targeted user base" in the meeting minutes and the "user scenarios" + "expert evaluation" on gui.gimp.org), then it is clear that the vision is targeted at experienced, professional users. This is at best a small percentage of the current GIMP users. As I wrote elsewhere, our current vision is rather elitist (the vision itself or how it is usually referred to). Again, there is nothing wrong with that because this is usually the only way to have real progress. But we have to acknowledge that the vision (or the way we use it) is targeted mainly at a minority of users. This minority is almost certainly the most interesting subset of our users, but it is a minority nonetheless.

And I thought that we all understand that there is a choice of several free software programs out there for users who want to do simple red-eye removal from their holiday jpegs.

Unfortunately, until that choice really exists this is a moot point. Basically, there is currently no good free software alternative to Photoshop Elements or even to the simple program (proprietary, Windows-only) that was delivered with my camera and allows one to quickly browse images, correct red eyes, exposure or color casts, crop/resize images and view/edit metadata. F-Spot comes very close to doing all that, but still has some weak spots that require you to use GIMP, Krita, mtPaint or Paint.NET for adjustments. Many of the quick actions provided in Photoshop Elements (which comes bundled with some cameras) are not available in any free program yet.

Again, I am not saying that we should do all that and try to solve all problems in GIMP. I prefer to stick to the current vision. I am just continuing my devil's advocate role and stating that you should not claim that there is a choice when the choice does not really exist.

In other words, a decision that provides a small improvement for the target users but implies a significant regression for all other users should be considered very carefully.

Actually in this case it the other way around. There is a significant improvement for target users, with clarification of image degradation of everyone, and little or no regression for the lossy-jpeg users.

We seem to disagree on that, but maybe it is better if I address this point in a reply to your previous message.

Again, to temper things a bit: this was only a subset of the developers present at LGM last year (GIMPCon 2006, see the minutes at http://developer.gimp.org/gimpcon/2006/ and read the section "GIMP Vision").

This is a slippery slope. If anybody can excuse themselves from the vision when they personally do not like the logical outcome of applying it to a hairy UI design question, and bang in their "yeah, but what about me" feature into svn, then we are back at the headless chickens state.

Unfortunately, you skipped the part of my message in which I wrote: "It is always possible for someone to propose someting that goes against the current consensus and hopefully convince others that this is the right thing to do." The last part (convincing others) is important. Making controversial changes to the code without discussing them is stupid and counter-productive. Convincing others that these changes are beneficial and useful for GIMP is progress. If others are not convinced that these changes are good, then they should not be commited or they should be reverted.

I am far from advocating anarchy, as you seem to think. But on the other hand, we should not be too rigid and have a blind faith in sacred rules. If someone comes up with good reasons to do or not do something, then more power to them!

-Raphael

Von: "Raphaël Quinet"

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 two days during the GIMP usability weekend in Essen. And this does still not take Kanila's and Peter's effort into account.

HTH, Michael

Von: "Michael Schumacher"

Kanila's

Kamila, sorry for misspelling your name.

Michael

On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking 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 overwriting an original is a loss. Working on a full-fidelity copy version is preferred.

Note that in the workflow that I described, I never mentioned overwriting the original. On the contrary, I said that the final JPEG file would be saved under another name.

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.

I am not sure about what others had in mind in this thread, but I I was mostly focusing on corrections to the source photos such as correcting the exposure or color balance and making other minor edits with the clone tool, etc.. These steps can be performed in a single session without having to save any full-fidelity internal representation. When I mentioned saving intermediate results, I meant saving copies of the image that you are currently working on, if you want to check how the final output will look like (including losses due to compression).

If you intend to work further on the image or to re-use some parts of it in a collage or in a more complex work, then it certainly makes sense to save the XCF version (or any other lossless format). The same applies if you work more than a few minutes on the image and it would cost too much to re-do these changes from the original in case you decide some weeks later that you need to apply more changes to the image.

But for the simple workflow that I described (which is or was rather common for me), in which simple corrections have to be applied to a large number of images without intending to work on them further, then it makes sense to have JPEG as input and as output without wasting time or space with intermediate formats.

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.

I am not disputing that. We should encourage users to use the lossless XCF format for all things that may need to be edited later or re-used in other images. As long as this can be done without breaking common workflows, then it's fine.

I don't mind if the simple load-edit-save cycle for JPEG images produces a warning the first time I do that, telling me that saving in JPEG will result in a quality loss and recommending XCF for saving any work-in-progress.

But would mind getting this warning every time or being forced to use a different menu option than the normal Save for the second and subsequent attempts at saving the image. This is how I interpreted your initial reaction. If I misunderstood what you meant and you did not intend to break the flow, then I am sorry for the misunderstanding and we can forget about it because there is really no issue.

-Raphaël

P.S.: If this issue is cleared and we ignore the arguments for the sake of argumenting (my previous message), then I think that I have a solution for the original issue mentioned in this thread: this is very close to the patch proposed by Tor and it also supports JPEG files that were not created by libjpeg. More about that later, when my code is ready.

On Tue, 10 Jul 2007 18:26:38 +0200, "Michael Schumacher" wrote:

Von: "Raphaël Quinet"

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 two days during the GIMP usability weekend in Essen. And this does still not take Kanila's and Peter's effort into account.

I was referring to the vision, not to the use cases.

But you are right that a lot of work was also invested in the usability aspects derived from the vision, and Peter and Kamila should of course be credited for that.

-Raphaël

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 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.

In my experience, it's much more common to read a jpeg in once and do a lot of operations on it in one session, saving periodically. There's no cumulative loss of quality: the intermediate saves are in case of disaster like a power failure, not a way to quit gimp and continue the editing process later.

But I think I remember Sven saying recently that Export would be able to save without prompting each time, after the first time. (I guess that means there will also be an Export As, in case you need to change the filename?) So those of us who often work in JPEG could use it just like we use Save now, and even bind ^S to it.

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.

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 to be telling us that the issue is lossiness, and the point of Export is to make it more hassle to save to lossy formats, to discourage use of those formats. Does that imply that Save will include PNG, TIFF and other non-lossy formats?

On Tue, 10 Jul 2007 09:51:24 -0700, Akkana Peck 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 to be telling us that the issue is lossiness, and the point of Export is to make it more hassle to save to lossy formats, to discourage use of those formats. Does that imply that Save will include PNG, TIFF and other non-lossy formats?

If you consider the whole image (including layers, metadata, etc.), then the only lossless image format is XCF. All other formats drop some information: PNG cannot save layers, TIFF cannot save all 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.

So I think that the statement from Peter that singled out indexed image formats and JPEG was slightly misleading (and this triggered my initial reaction). Basically, only XCF would be "saved" and all other image formats would be "exported".

-Raphaël

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 gg@catking.net:

On Tue, 10 Jul 2007 01:24:40 +0200, 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 because it already was that quality. Saving it a 95 would increase filesize by about a factor of 8 without any gain in quality! You would not have less loss.

You presume that I have done nothing to improve the content of image. The file saved IS degraded relative to the image I am editing.

If you want to change the nature of the image format user SaveAs.

Save should keep things the way they are as near as possible.

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. If file size is your main concern, use Save For Web. If honoring the user's expectations with regard to image quality is your focus, Save should recognize user-specified default settings.

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 2.6, to consider unifying the output plugins a bit, so that you can have a pull-down of file formats and see the parameters for each format before you hit save,

Something along those lines has been suggested before. It's rather difficult to implement but if someone would come up with a decent plan it would be worth trying.

Sven

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 quite a while already.

Oops, so I missed it but Gimp didn't -- thanks for replying!!

I wonder if it'd be possible, for gimp 2.6, to consider unifying the output plugins a bit, so that you can have a pull-down of file formats and see the parameters for each format before you hit save,

Something along those lines has been suggested before. It's rather difficult to implement but if someone would come up with a decent plan it would be worth trying.

I'll take some time to think about it, in case it is of use, and will write something up for 2.6.

Liam

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. 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.

That is was externalised (written down) in such a short time is the added value _I_ deliver to my customers.

And let me repeat: if the we had not reached this result in these few hours, I would have interpreted that as the GIMP team having no clue about what they are trying to achieve, and I would have not gotten involved.

No vision (or a constantly disputed vision) == no clue == no chance in hell for anybody (including pros like me) to achieve decent interaction == a project I do not need to ruin my professional reputation on.

Few? there are millions of users within our vision out there.

Sorry, but I have to disagree here. If you just look at the part of the product vision that says "GIMP is ...", then it could apply to a large number of GIMP users. But if you look at the context of the vision (which is not explicitely written in that section, but is part of the "Targeted user base" in the meeting minutes and the "user scenarios" + "expert evaluation" on gui.gimp.org), then it is clear that the vision is targeted at experienced, professional users.

I take the vision as broad as it can be explained (it was phrased not so specific for a reason), but not broader. I actually do not like the word professional, it just means earning money. To sum it up I like to think of 'intense use', you either put in a lot of hours with GIMP, or you have paid your dues and know what you are doing.

This
is at best a small percentage of the current GIMP users. [...] But we have to acknowledge that the vision (or the way we use it) is targeted mainly at a minority of users. This minority is almost certainly the most interesting subset o

I do not believe that.

And I thought that we all understand that there is a choice of several free software programs out there for users who want to do simple red-eye removal from their holiday jpegs.

Unfortunately, until that choice really exists this is a moot point.

we agreed at the vision meeting that the choice is there.

And I would let Krita, F-Spot, digikam et al. worry about serving their market optimally, and actually give them a chance by keeping GIMP out of their markets. Since we are not in it of the money, we can actually improve our own situation by letting some room for other software developers.

This is a slippery slope. If anybody can excuse themselves from the vision when they personally do not like the logical outcome of applying it to a hairy UI design question, and bang in their "yeah, but what about me" feature into svn, then we are back at the headless chickens state.

Unfortunately, you skipped the part of my message in which I wrote: "It is always possible for someone to propose someting that goes against the current consensus and hopefully convince others that this is the right thing to do."

Your wish is my command >^}

Luckily, GIMP has a core and plugins. The core has to be redesigned according to the product vision. This includes the standard distribution of plugins.

I will measure anything that has to do with interaction against the product vision to see if it interferes with it. If it does not bloat the interface and stays out of the way of achieving the vision then it is fine with me. See the following frivolous extra:

I did not chop its head off.

Any other counter-vision stuff (example: GIMPressionist) must stay out of the core (distribution) and live happily as a one-click installation on a web server (even on gimp.org).

--ps

principal user interaction architect man + machine interface works

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

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 the workflow that Raphael described (touching up photos), then perhaps we need to refine the vision.

And I would let Krita, F-Spot, digikam et al. worry about serving their market optimally, and actually give them a chance by keeping GIMP out of their markets. Since we are not in it of the money, we can actually improve our own situation by letting some room for other software developers.

That is not an argument simply because market shares and such simply don't matter here. And secondly I think that there is a lot of overlap at least with Krita. Our product visions are quite similar with Krita having the focus slightly more on painting. But that's only a marginal difference.

Sven

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 point of "it is never finished." Either as an artist you grow and want to revise your work, or people you work for ask you for another revision.

'and you just thought that first jpeg was the final result'

So giving priority to saving files in full-fidelity is the way to go for me.

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.

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.

Writing that a few days ago I realised that that is where you end up when you systematically apply the argument: only xcf is full-fidelity.

So you Save (as) in that format, and the rest is exported.

But I thought that would be to hard to swallow at this point in the current discussion. But the Raphael writes:

So I think that the statement from Peter that singled out indexed image formats and JPEG was slightly misleading (and this triggered my initial reaction). Basically, only XCF would be "saved" and all other image formats would be "exported".

Sorry for the confusion then, we all seem to be moving in the same direction.

--ps

principal user interaction architect man + machine interface works

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

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 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 if you only check the comments that you have made in the last two days in this thread, you will see that you have emphasized several times the term "high-end". Specifically: 'High-end' is the word I want us to focus on. This means focusing only on a minority of GIMP users. And as I wrote earlier, I am convinced that it's the best thing to do as this is the best way to have real progress. However, we should still be careful about what these improvements (or changes, in general) mean to the majority of our users (those who do not fit in the "high-end" definition).

This
is at best a small percentage of the current GIMP users. [...] But we have to acknowledge that the vision (or the way we use it) is targeted mainly at a minority of users. This minority is almost certainly the most interesting subset o

I do not believe that.

You do not believe that "this minority is the most interesting subset" or that it is a minority? Assuming the latter, I am sorry but I believe that the vast majority of GIMP users are not high-end users. Most users do not use GIMP every day, probably not even every week.

But the cumulative time that all those users spend using GIMP is probably much larger than the time that the few experienced users who need and use the high-end features spend with GIMP. So I would like GIMP to focus on high-end features as much as possible according to our vision. But if some of the required changes imply a significant regression for the majority of the users, then we should think twice about them. The changes can still be applied even if they add a cost for some users because it is impossible to please everybody, but we should keep some balance and not always focus exclusively on the experienced users.

And I thought that we all understand that there is a choice of several free software programs out there for users who want to do simple red-eye removal from their holiday jpegs.

Unfortunately, until that choice really exists this is a moot point.

we agreed at the vision meeting that the choice is there.

This was mentioned, but there was some disagreement (well, at least during the part of the meeting that I attended - I missed the discussions on the second day). There was certainly an agreement on the fact that GIMP cannot do everything for everybody and that some other programs should fill the niches that we do not cover. But I don't think that there was ever an agreement on the fact that the choice is there (last year during the meeting, or even today). I could not agree with that because there is no real choice among free software for browsing and doing simple adjustments on holiday pictures. There is currently nothing that comes close to Photoshop Elements or even to the various simpler programs that come bundled with most cameras.

As I wrote, F-Spot is coming close for some features (and some of the important ones have only been added in the recent months), but it is still necessary to complement it with GIMP or Krita for some operations such as correcting some errors with the clone tool, doing finer color adjustments or just rotating the image a bit. Nothing very fancy nor high-end, but this is still something that people use GIMP for.

This may change in the future if F-Spot or others get better, but I doubt that it is part of F-Spot's vision to include things such as our paint tools or transform tools. Yet this is something that some users expect to find in Free Software because they can do that with the "free" but proprietary stuff that they got with their cheap point-and-shoot digital cameras. I just don't want to forget about these users too early, even if they are not the ones we try to please first.

-Raphaël

On Thu, 12 Jul 2007 14:31:16 +0200, Raphaël Quinet 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 high-end features). And that's a good thing because it helps us to have a clear direction. But we must still balance that with the interests of the majority whenever possible.

2) There are still many simple usage scenarios that are not covered by any other program (free software), so there is no real choice besides GIMP for many users.

Wow, I can write something in less than ten lines. :-)

-Raphaël

On Tue, 10 Jul 2007 19:21:33 +0200, 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 but this is the mistake I have already pointed out , you dont know the meaning of the word default.

If there is an image specific value you do not need a default. "overriding" a default with an image-specified value is a contradiction.

@Peter

The key issue, it seems, is that a would-be "high-end" tool should not be telling me it knows better than I (the high-end user) how to do what I need to do.

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 takes a couple of screws he has in his pocket and hammers them in to tack the guide into place.

Well we all know you should NEVER hammer in a screw but it gets the job done. As a high-end builder he uses the tools and materials to hand to get the job done with the minimum of wasted time.

Now imagine he'd just bought the new "high-end" Gimp Hammer, the high-end solution for high-end users.

When he comes to hit his nail he realises the his new high-end hammer has a specially crafted end that slips off screw heads because the guy who designed it thinks you should NEVER work this way and wants to force his work flow to the one and only _correct_ way to do this job.

Well I hope the glazier has not been to the site yet because that high-end hammer is going out of the nearest high-end window.

Now can we please stop all this "I know best" dicatorial design non-sense? Especially since the current state of all gimp installations on the planet (except for a handful of us who have build snv in that last few days) clearly shows that we dont know best.

Let's credit our hyperthetical high-end user with a grain of sense and suspect he may actually know what he is doing. Give him a powerful, flexible tool that does not try to tell him how to do his job.

Don't get in his way if he decides, for reasons that may be prefectly valid in the context of what he is doing, that he wants to save a jpeg.

/gg

Sorry - I always forget to Reply-All to this list...

On 7/12/07, gg@catking.net 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 takes a couple of screws he has in his pocket and hammers them in to tack the guide into place.

Well we all know you should NEVER hammer in a screw but it gets the job done. As a high-end builder he uses the tools and materials to hand to get the job done with the minimum of wasted time.

Now imagine he'd just bought the new "high-end" Gimp Hammer, the high-end solution for high-end users.

When he comes to hit his nail he realises the his new high-end hammer has a specially crafted end that slips off screw heads because the guy who designed it thinks you should NEVER work this way and wants to force his work flow to the one and only _correct_ way to do this job.

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 use the other end to drive in the screw. Since carpenters are pretty dextrous - high-end ones anyway :) - I think the carpenter would enjoy the versatility of the GIMP Hammer.

No one in this discussion has ever said anything about removing GIMP's ability to produce JPEGs. What (I think) is going on is a discussion about whether or not "Save" is an appropriate command for an action that discards data. IMO opinion this pertains more to the newbies than anyone else. Those who've used graphics for some time now (should) know what we're doing.

Chris

On Thu, 12 Jul 2007 23:29:01 +0200, gg@catking.net wrote:

If there is an image specific value you do not need a default. "overriding" a default with an image-specified value is a contradiction.

This reminds me about something that should be clarified... For all these parameters that affect how an image is saved, where do these various values and defaults come from, and how to name them?

I propose the following terms (feel free to propose something else if you have better ideas): "default", "original" and "current" values. This is a slightly expanded version of the comment #14 that I added to bug #63610 in 2003; in that comment I forgot the "original" setting.

1) The "default" setting is the one that is hardcoded or configurable in GIMP or in one of its plug-ins. Sometimes the "default" value can be empty or not set. Some examples: a default image comment can be configured in the Preferences, the JPEG plug-in uses a default quality setting of 85, GIF does not interlace the file by default, etc. The "default" setting applies to all images.

2) The "original" setting is the one that is found (or not) when an image is loaded from disk. For example, an image file may include a user comment and this comment will be preserved when the file is saved later. The "original" setting only applies to that specific image.

3) The "current" setting is whatever is currently associated with one specific image. Once it is set (coming from the "default" or "original" setting), it will always be used whenever this image is saved. It can usually be changed by the user in the dialog window of the file plug-in.

In theory, these parameters should work like this: all new images or images loaded from disk get the "default" setting except if some files have an "original" setting, which is then used instead of the default one. This then becomes the "current" setting, which is associated with that image every time it is saved.

In practice, there are several exceptions due to implementation details or leftovers from the past. For example, the "current" setting may not actually exist until the file is saved (it only exists once the save plug-in creates it).

But there is a bigger problem that I mentioned in bug #63610. There is a confusing historical feature that introduces another source of settings for some parameters:

4) The "session" setting is a side-effect of the fact that file plug-ins currently behave like other plug-ins (filters). This is a value that is set the first time you save a file in a specific format and that will affect all other images that you save during that session (until you quit GIMP). This behavior is appropriate for filters but is confusing and dangerous for file plug-ins.

The problem with "session" settings is that something that is changed when saving one image can trigger unexpected changes in all other images. For example, you use Save As to save an image using lower quality settings for testing, but you do not see that from then on, all other images that you save (normal Save) in the same format will also use that lower quality instead of using the default value.

IMNSHO, the right way to fix bug #63610 is to provide an easy way for all file plug-ins to save and reload one or more sets of "default" values and then forbid all file plug-ins from using "session" settings (save_args or save_vals or whatever the array of saved GimpParamDef is called in each plug-in). In fact, removing the usage of session settings could already be done right now in all file plug-ins, even before having a nice library for file plug-ins that would provide a unified way to save and load default values.

This would solve one of the problems that has started this long thread about the JPEG quality factor: saving one image in low quality will not cause other unrelated images to be also saved in low quality. The other improvement that can be implemented without waiting is to read or compute the "original" quality from JPEG files and to use it if and only if it is better than the "default" quality. I am working on a simple extension of the nice patch that Tor provided a few days ago.

-Raphael

Quoting gg@catking.net:

On Tue, 10 Jul 2007 19:21:33 +0200, 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 but this is the mistake I have already pointed out , you dont know the meaning of the word default.

If there is an image specific value you do not need a default. "overriding" a default with an image-specified value is a contradiction.

There are, at times, valid reasons to ignore the quality value associated with a particular JPEG file. Ignoring that value (and using some other methodology) should be available as an option. The user should be able to able to specify such an option as the "default" behavior for a non-interactive save operation.

There are sometimes valid reasons to honor the quality value associated with a particular JPEG file. Honoring that value (and ignoring some other methodology) should be available as an option. The user should be able to able to specify such an option as the "default" behavior for a non-interactive save operation.

I fail to see how I have misused the term "default" in any of this explanation.

On Fri, 13 Jul 2007 20:49:49 +0200, 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 point is that default means a value to be used when no defined value is available. A value to be used by default.

When an image already has a value for jpeg_quality , or any other paramter, replacing this is not providing a default it is a forcing.

Hope that make it clearer.

On Fri, 13 Jul 2007 22:42:29 +0200, gg@catking.net wrote:

On Fri, 13 Jul 2007 20:49:49 +0200, 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, replacing this is not providing a default it is a forcing.

I hope that you both read the message in which I was suggesting to use the terms "default", "original" or "current" depending on where some values come from. As I explained in that message, the "original" value (read from the file) will usually override any "default" value (coming from GIMP or from the plug-in).

However, some plug-ins do not even attempt to read the "original" value for some parameters because for some file formats it does not make sense to re-use the same values as in the original file.

For JPEG quality, I think that it is best to do as in Tor's patch: if the "original" value is higher than the "default", then use that. Otherwise, use the "default" so that the user is not surprised to have a file saved with a lower quality than expected.

-Raphaël

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 following compression value: - Original
- User-specified (insert number, so users would know what that value is)

I chose to replace "default" by "user-specified" to avoid confusion.

I'm sorry if I'm repeating what someone else is saying, but all this cross-talk is leaving me a bit lost. :S

_____________________________________

On Fri, 13 Jul 2007 00:03:18 +0200, Chris Mohler 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 use the other end to drive in the screw.

I think a more correct representation would be the hammer turns it self around and refuses all attempts to come back.

Since carpenters are pretty dextrous - high-end ones anyway - I think the
carpenter would enjoy the versatility of the GIMP Hammer.

more likely a sprained wrist.

No one in this discussion has ever said anything about removing GIMP's ability to produce JPEGs. What (I think) is going on is a discussion about whether or not "Save" is an appropriate command for an action that discards data.

We're all agreed we are not targetting mickey mouse users , so why should we to treat graphics professionals as idiots?

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.

I dont give a damn for lectured by the interface, let me drive !!

IMO opinion this pertains more to the newbies than anyone else. Those who've used graphics for some time now (should) know what we're doing.
Chris

I'm in perfect agreement there. This more of an attempt to lecture less familiar users that they should not be using jpeg as an intermediate storage format than to provide a better tool for high-end users as claimed.

In fact this logic is at complete odds with "the vision". So much for the input of a professional interface architect.

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.

The minor disruption of a one time "go away" option for competant users and a clear warning to those who are not aware of the issue.

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.

It is nonsense to talk of exporting a jpeg to gimp's internal format.

This is surely convert to xcf.

BTW Chris, looks like you got caught out by the mailing list's FROM header, your message only had my address and did not go to the list. I presume this was not intended to be off list.

/gg

On Fri, 13 Jul 2007 01:23:39 +0200, Raphaël Quinet wrote:

On Thu, 12 Jul 2007 23:29:01 +0200, gg@catking.net wrote:

If there is an image specific value you do not need a default. "overriding" a default with an image-specified value is a contradiction.

This reminds me about something that should be clarified... For all these parameters that affect how an image is saved, where do these various values and defaults come from, and how to name them?

I propose the following terms (feel free to propose something else if you have better ideas): "default", "original" and "current" values. This is a slightly expanded version of the comment #14 that I added to bug #63610 in 2003; in that comment I forgot the "original" setting.

1) The "default" setting is the one that is hardcoded or configurable in GIMP or in one of its plug-ins. Sometimes the "default" value can be empty or not set. Some examples: a default image comment can be configured in the Preferences, the JPEG plug-in uses a default quality setting of 85, GIF does not interlace the file by default, etc. The "default" setting applies to all images.

2) The "original" setting is the one that is found (or not) when an image is loaded from disk. For example, an image file may include a user comment and this comment will be preserved when the file is saved later. The "original" setting only applies to that specific image.

3) The "current" setting is whatever is currently associated with one specific image. Once it is set (coming from the "default" or "original" setting), it will always be used whenever this image is saved. It can usually be changed by the user in the dialog window of the file plug-in.

Thanks for formalising all this. I had though about how this issue affects other paramaters but did not dare further confuse that enormous thread with side issues.

Does "current" need to be saved as a third option? It is either equal to default or original unless it is set during a save in which case it become the new value of original. Are you suggesting the truely original settings are retained after a save with different values? If so how long? End of session perhaps.

Ah yes , I've just realised there are many of these extended settings that are not set in the save dlg so there is a real need for your third option.

In theory, these parameters should work like this: all new images or images loaded from disk get the "default" setting except if some files have an "original" setting, which is then used instead of the default one. This then becomes the "current" setting, which is associated with that image every time it is saved.

In practice, there are several exceptions due to implementation details or leftovers from the past. For example, the "current" setting may not actually exist until the file is saved (it only exists once the save plug-in creates it).

But there is a bigger problem that I mentioned in bug #63610. There is a confusing historical feature that introduces another source of settings for some parameters:

4) The "session" setting is a side-effect of the fact that file plug-ins currently behave like other plug-ins (filters). This is a value that is set the first time you save a file in a specific format and that will affect all other images that you save during that session (until you quit GIMP). This behavior is appropriate for filters but is confusing and dangerous for file plug-ins.

The problem with "session" settings is that something that is changed when saving one image can trigger unexpected changes in all other images. For example, you use Save As to save an image using lower quality settings for testing, but you do not see that from then on, all other images that you save (normal Save) in the same format will also use that lower quality instead of using the default value.

Yes , as already noted in the other thread, this is an aboration leading to unexpected and irrational results. Session settings should probably now be dropped as you say for Save plugins.

The function of these plugins is fundamentally different from filters and thier role is so essential that they merit a different interface if that is necessary.

IMNSHO, the right way to fix bug #63610 is to provide an easy way for all file plug-ins to save and reload one or more sets of "default" values and then forbid all file plug-ins from using "session" settings (save_args or save_vals or whatever the array of saved GimpParamDef is called in each plug-in). In fact, removing the usage of session settings could already be done right now in all file plug-ins, even before having a nice library for file plug-ins that would provide a unified way to save and load default values.

This would solve one of the problems that has started this long thread about the JPEG quality factor: saving one image in low quality will not cause other unrelated images to be also saved in low quality. The other improvement that can be implemented without waiting is to read or compute the "original" quality from JPEG files and to use it if and only if it is better than the "default" quality.

I'm not sure about the ifing and butting. I think the program should work in one predictable and consistant way. There is also in problem artificially altering this value if it is "better". That is subjective. A numerically higher jpeg_quality value is not better if you dont want you file to suddenly get huge next time you save it (obstencively without changing anything.)

I think default values should be used only _by default_ , ie when no other value is available as you outlined at the top. If there is a perceived need to force these values (and that seems to be the main difference of option here) then perhaps the dlg for setting the user defined defaults should have an option "force these settings for all jpeg images". This defaults to false, so the user who sets default parameters has to actively select the forcing and takes legal repsonsabilty for the resulting bloat/degradation trade-off.

That satisfies those who want to define across the board behavoir at the same time as providing a gimp jpeg save that does nothing more than is asked of it: save the image as it was loaded unless the user intervenes.

To me this seems to be the only proper way to handle it. A Save should not be trying to do a furtive SaveAs.

I am working on a
simple extension of the nice patch that Tor provided a few days ago.

-Raphael

Thx, gg/

On 7/14/07, gg@catking.net wrote:

On Fri, 13 Jul 2007 00:03:18 +0200, Chris Mohler 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.

On 7/14/07, gg@catking.net wrote:

On Fri, 13 Jul 2007 01:23:39 +0200, Raphaël Quinet wrote:

Does "current" need to be saved as a third option? It is either equal to default or original unless it is set during a save in which case it become the new value of original. Are you suggesting the truely original settings are retained after a save with different values? If so how long? End of session perhaps.

I thought this could be simpler -- if the original settings for an image are attached to the image as a non-persistent parasite, that parasite will expire when the image is closed. IMO this is more logical than keeping till end of session (keeping til end of session is what would happen if you attached a non-persistent parasite to GIMP itself.)

Ah yes , I've just realised there are many of these extended settings that are not set in the save dlg so there is a real need for your third option.

In theory, these parameters should work like this: all new images or images loaded from disk get the "default" setting except if some files have an "original" setting, which is then used instead of the default one. This then becomes the "current" setting, which is associated with that image every time it is saved.

I think that works well with the above, since the original setting becomes the current in a suitable way.

This would solve one of the problems that has started this long thread about the JPEG quality factor: saving one image in low quality will not cause other unrelated images to be also saved in low quality. The other improvement that can be implemented without waiting is to read or compute the "original" quality from JPEG files and to use it if and only if it is better than the "default" quality.

I'm not sure about the ifing and butting. I think the program should work in one predictable and consistant way. There is also in problem artificially altering this value if it is "better". That is subjective. A numerically higher jpeg_quality value is not better if you dont want you file to suddenly get huge next time you save it (obstencively without changing anything.)

I think default values should be used only _by default_ , ie when no other value is available as you outlined at the top. If there is a perceived need to force these values (and that seems to be the main difference of option here) then perhaps the dlg for setting the user defined defaults should have an option "force these settings for all jpeg images". This

Yes, cool -- in what scope? (ie -- this session, or all sessions including and after this one? in the latter case we should provide a way to clear those.)

defaults to false, so the user who sets default parameters has to actively select the forcing and takes legal repsonsabilty for the resulting bloat/degradation trade-off.

We need a way to flag this to the user -- maybe in "Image Properties" dialog, something that is both unambiguous and not Jpeg-specific (eg. it could also apply when you are exporting to an indexed format). Honestly, this 'force' option seems necessary though hackish. I've made a few tries at writing such a message, but came up with nothing yet.

That satisfies those who want to define across the board behavoir at the same time as providing a gimp jpeg save that does nothing more than is asked of it: save the image as it was loaded unless the user intervenes.

To me this seems to be the only proper way to handle it. A Save should not be trying to do a furtive SaveAs.

This is true. Perhaps Save could insist on prompting you for an xcf filename if the image filename is not xcf. I believe that resolves both inconsistencies - silent upgrading and saving-that-is-losing, as well as defining a more clear workflow for the individual cases of 'quick edit' and 'significant work over time' - in one case you edit and QuickExport*, in the other you edit, save, edit, save... and eventually export (maybe repeating that cycle if you need to revise things)

* yeah, this name could be improved. Perhaps you could have Export and Export As instead (where Export performs the function I called QuickExport earlier, and Export As could probably replace 'Save a copy..')