Re: [gimp-devel] Re: JPEG correction (was Re: Gimp Wishes)
On Sat, Apr 08, 2000 at 01:24:53AM +0300, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > I have no idea what would be a good way to implement this, or how the > user interface could look. Probably one would need to keep a bitmap of > dirty pixel blocks (or whetever they are called), and when saving, if I'd say for such a really jpeg-only thing, the best way would be to enhance the jpeg save mechanism to first parse the existing file. Seems doable as well. > the more important a pixel block is. Hmm, is this doable in the JPEG > format at all? Yes. But I doubt it would be "legal" (that is, even if legal I doubt decoders would survive reading it ;) > Of course, one could achieve something similar by > simply blurring the unimportant parts before saving. Probably with some kind of "jpeg-blur" that aims at reducing frequency components suited for jpeg... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: [gimp-devel] Re: JPEG correction (was Re: Gimp Wishes)
I think it would be a very useful feature to be able to open a JPEG in the GIMP, do some editing that touches just a small minority of the pixels like correcting red-eyes, and save just the edited parts, keeping the rest of the JPEG unchanged. (Not talking about individual pixels, of course, but those 8x8 (?) pixel blocks.) I have no idea what would be a good way to implement this, or how the user interface could look. Probably one would need to keep a bitmap of dirty pixel blocks (or whetever they are called), and when saving, if only a reasonably small minority of the pixel blocks are dirty, the plug-in could offer the user to keep the untouched pixel blocks intact and save just the changed ones. There is a patch to jpegtran that enables it do to lossless cropping. The same patch also enable you to "insert" a smaller jpeg in a larger one without loss. See http://www.reporter.de/digifoto/jpegcrop/ . Another possibly useful JPEG feature would be to be able to use variable quality when saving an image as a JPEG. For instance the selection mask could be used to indicate the relative importance of various parts of an image, and the plug-in would use higher quality the more important a pixel block is. Hmm, is this doable in the JPEG format at all? Of course, one could achieve something similar by simply blurring the unimportant parts before saving. --tml
Re: [gimp-devel] Re: JPEG correction (was Re: Gimp Wishes)
Jon Winters ([EMAIL PROTECTED]) wrote: > The only manipulation I can think of that would benefit from "lossless" > jpeg would be rotating the image. (if I were shooting low-rez) I > remember seeing some tools at the JPEG F.A.Q. site that would rotate a > JPEG without damage. http://www.faqs.org/faqs/jpeg-faq/ This lossless operations depend heavily on knowledge about JPEG internals. They operate without de- and recompressing the image data. You can use them with tools like jpegtran . However, this is nothing to embed into Gimp. Gimp has a totally different approach on storing image data and it is virtually impossible to preserve the JPEG-internal data (parasites for all JPEG-Coefficients - Urgh... ;-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: JPEG correction (was Re: Gimp Wishes)
If I start with an image out of my digicam and it is already in JPEG format I'll save it as an .xcf or .xcf.gz. When I'm finished makin changes then it gets prepped for the web. (crop, scale, and jpeg compression) The only manipulation I can think of that would benefit from "lossless" jpeg would be rotating the image. (if I were shooting low-rez) I remember seeing some tools at the JPEG F.A.Q. site that would rotate a JPEG without damage. http://www.faqs.org/faqs/jpeg-faq/ Tom Lane! Are you still subscribed? :-) -- Jon Winters http://www.obscurasite.com/ "Everybody loves the GIMP!" http://www.gimp.org/
Re: JPEG correction (was Re: Gimp Wishes)
On Thu, Apr 06, 2000 at 07:37:14PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > On Thu, Apr 06, 2000 at 01:20:50AM +0200, Marc Lehmann wrote: > > As such, why save an image if you didn't change it? > > There is no good reason why a PROFESSIONAL graphic designer should be > doing it, but lots of us are mere amateurs :) gimp makes it very difficult to save an image you haven't changed. > JPEG works one tile at a time. The same behaviour I observe in one image > will be true on average for individual tiles, so if I alter only one > half of an image (or only touch up one word) and save with the same > quality as the original, the untouched tiles will be mostly unharmed. Most people use things like the Curves tool, the Levels tool, the Crop tool etc.. to retouch images. Not popping up a save dialog will hurt the amateur users that you care for most, since it creates a totally wrong sense of safety. > By fiddling carefully with JPEG settings we can get the "right" setting Something that will work "by chance" (without an easy way to undo the action, since the user will not notice the problem early enough) mustn't go into the gimp. I mean, quality detection is a good thing, but it must NEVER be automatic, second guessing the user on something that will go wrong in a vast number of common situations is "unfriendly". > I don't want that, people shouldn't be using JPEG for works in progress > or as a common format moving between packages or ANYTHING like that, and > I agree that we don't want to give them false expectations. > > I think Marc and I agree on the realities of this situation, I just > wanted to make clear that "lossy" re-saving doesn't necessarily cause > any damage to the image. But that's NO REASON to be doing it, and > no reason for Gimp to encourage it either. 100% correct ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: JPEG correction (was Re: Gimp Wishes)
On Thu, Apr 06, 2000 at 01:20:50AM +0200, Marc Lehmann wrote: > As such, why save an image if you didn't change it? There is no good reason why a PROFESSIONAL graphic designer should be doing it, but lots of us are mere amateurs :) JPEG works one tile at a time. The same behaviour I observe in one image will be true on average for individual tiles, so if I alter only one half of an image (or only touch up one word) and save with the same quality as the original, the untouched tiles will be mostly unharmed. A classic example (which I won't distribute because it's obviously illegal) is a re-touched Matrix JPEG from the movie site, altered to replace Keanu with Windy Miller from the old UK television shows. By fiddling carefully with JPEG settings we can get the "right" setting to make the hacked version look like the original, without additional artifacts in the unaltered portions of the image. Looks great! > Given that the problem is unsolvable in theory and almost impossible even > to approximate in practise, I believt hat such a automatic detection > scheme will fool people into thinking that saving at the same quality > wouldn't destroy their image. I don't want that, people shouldn't be using JPEG for works in progress or as a common format moving between packages or ANYTHING like that, and I agree that we don't want to give them false expectations. > The problem here is that different encoders have different notions of > "quality settings", and in most cases you can only approximate the > quality setting of another encoder (quality settings are just a quick > way to describe a 8x8 matrix, and setting up that matrix is very much > decoder-dependent) I think Marc and I agree on the realities of this situation, I just wanted to make clear that "lossy" re-saving doesn't necessarily cause any damage to the image. But that's NO REASON to be doing it, and no reason for Gimp to encourage it either. That was a public service announcement from the lossy compression posse Nick.
Re: JPEG correction (was Re: Gimp Wishes)
On Mon, Apr 03, 2000 at 10:30:47PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > This isn't true, IJG documentation and home made tests show that, for Yes, this is true. You (and the ijg group) assume that the image does not change between the load/save cycle. > This isn't guaranteed, but will usually work if you keep everything the > same (codec, compiler, libraries, CPU, direction of the wind...) (... image content) As such, why save an image if you didn't change it? > In any case it never does any harm. In fact, this improvement can be > enough for the difference between "obviously re-edited JPEG" and a > seamless fix to an image when you've lost the original. Given that the problem is unsolvable in theory and almost impossible even to approximate in practise, I believt hat such a automatic detection scheme will fool people into thinking that saving at the same quality wouldn't destroy their image. > the IJG codec was used at all. IMHO that's for the best. I should not > need to care which encoder was used to use the image. The problem here is that different encoders have different notions of "quality settings", and in most cases you can only approximate the quality setting of another encoder (quality settings are just a quick way to describe a 8x8 matrix, and setting up that matrix is very much decoder-dependent) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
JPEG correction (was Re: Gimp Wishes)
(although this is as a reply to Marc's post I only noticed it in the more recent replies, sorry if that screws up threading for anyone) On Sat, Apr 01, 2000 at 07:46:03PM +0200, Marc Lehmann wrote: > I don't think this really is so much of a problem. Saving a jpeg in the same > quality as it was originally saved will do no good to your quality. The only > thinvg it will ensure is that the file-size will be similar. This isn't true, IJG documentation and home made tests show that, for what little it is worth JPEG(75) -> JPEG(75) -> JPEG(75) applied to any set or subset of image tiles can do much LESS damage than e.g. JPEG(75) -> JPEG(85) -> JPEG(75) -- even though the latter results in the same size files, give or take. This isn't guaranteed, but will usually work if you keep everything the same (codec, compiler, libraries, CPU, direction of the wind...). In any case it never does any harm. In fact, this improvement can be enough for the difference between "obviously re-edited JPEG" and a seamless fix to an image when you've lost the original. The only trouble with this fact is that there's no usable mechanism for divining which settings were used to compress the image, or even whether the IJG codec was used at all. IMHO that's for the best. I should not need to care which encoder was used to use the image. Nick.
