...while it's well-known to be theoretically and practically possible to manually compress different sections of a JPEG differently, the only program I've ever been able to find that lets you actually do so is Windows-only.
There is an insane part of me that's tempted to build a utility like that myself, actually!
And I do have a couple of Windows machines handy these days. I don't think my boyfriends would mind me borrowing their boxen for a few minutes to output a jpeg that's grunged up just right. Thanks for the link!
Yeah, the actual 'engine' of such code is pretty easy. It's making a functional UI for it that's a pain to me. I'm vaguely tempted to resume the work I'd had before that let you specify greyscale 'quality maps' for GIMP at least as one approach, as that would also let you (mostly) benefit from mixing grayscale and colour work in one image, beyond just varying the quality level.
Get a nice crisp high-quality bitmap in, set a basic compression level. Then you have the 'crapify' brush and the 'crispify' brush. Smear it around. Paint with quality.
That's where I'd go with it if I wrote something, what with seeing it as very much an artistic effect to deploy rather than a task of optimizing for file size. I'm all about the immediate feedback whenever possible, these days. I'd have to look into the details of just how a jpeg is structured to see how feasible it'd be.
"This bit isn't crisp enough. *swab* There, that's better. Yeah, save it out."
Well the structure of a JPEG image (which is entirely seperate from the structure of a JFIF file, .jpg/.jpeg files are actually JFIF files with JPEG images inside, but nothing else ever used JFIF to speak of so calling them .jpeg's works) is pretty trivial if you skip the single-pass/multiple-pass differences. (And you can, conversion to/from 'progressive' images is lossless and can be done with external tools.)
Once you get past the JFIF wrapper, the JPEG is pretty basic once you convert things to the color-space it works in, and decide on the downsampling factors, and convert through the DCT, you're dealing with (essentially) flat planes of blocks of 64 numbers. All of the blocks can be arbitrarilly scaled down with per-item (NOT per-block) divisions that are declared ahead-of-time, before being truncated to integers and finally encoded.
Since it relies on reducing a lot of the later numbers to 0 when truncated to an integer for it's compression, simply zeroing out things further from the end of the list of numbers results in lowered quality and increased compression of arbitrary blocks, since you can't (as I understand it) declare multiple quantization matrices (what the divisor blocks are called) for a single plane.
So basically you'd be looking at zeroing out arbitrary columns in the big fat table of blocks in individual planes, optionally with zeroing out from a given column onwards. To be honest, losing things arbitrarilly in the middle could result in interesting artifacting as well, so that's something else to experiment with perhaps?
And the Wiki article says it somewhere, but just to be comprehensive with my comment, the compression is done seperately on each plane, which means one block for the 'value' plane may cover only 8x8 pixels on the output image, but one block for a 'color red' or 'color blue' plane will cover 16x8, or 16x16 pixels.
I was reading the comments below, and it seems the visual effect of the compression is more important than file size, so, while annoying, you could simply layer compression effects by working on an image in parts where each part is a different saved compressed JPEG.
Working as a brush, I can see a couple possible difficulties. First, I thought that the brush would need to be some factor of 8 in size, but I could see some ways around it. What struck me as most important, was going over the same spot repeatedly with this brush tool. I don't think that a Q of 1 is equal to Q of 10 with 10 passes of the brush, so it wouldn't be as uniform a result as what you have now.
Personally, just being able to apply it to a selection would be nice, IMHO.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
egypturnash
no subject
Date: 2006-09-24 11:49 pm (UTC)Now to find something that'll let me manually play with the compression levels so I could, say, keep the signature legible while turning the rest to shit...
Unfortunately...
Date: 2006-09-25 01:10 am (UTC)XAT's JPEG Optimizer (http://www.xat.com/jpegopt/index.html)
If you'd actually have a use for such a utility again though, I'd be happy to build one for you as long as you could live with an X11 version? =^.^=
Re: Unfortunately...
Date: 2006-09-25 01:25 am (UTC)And I do have a couple of Windows machines handy these days. I don't think my boyfriends would mind me borrowing their boxen for a few minutes to output a jpeg that's grunged up just right. Thanks for the link!
Re: Unfortunately...
Date: 2006-09-25 03:55 am (UTC)Re: Unfortunately...
Date: 2006-09-25 06:38 am (UTC)Get a nice crisp high-quality bitmap in, set a basic compression level. Then you have the 'crapify' brush and the 'crispify' brush. Smear it around. Paint with quality.
That's where I'd go with it if I wrote something, what with seeing it as very much an artistic effect to deploy rather than a task of optimizing for file size. I'm all about the immediate feedback whenever possible, these days. I'd have to look into the details of just how a jpeg is structured to see how feasible it'd be.
"This bit isn't crisp enough. *swab* There, that's better. Yeah, save it out."
Re: Unfortunately...
Date: 2006-09-25 07:13 am (UTC)Once you get past the JFIF wrapper, the JPEG is pretty basic once you convert things to the color-space it works in, and decide on the downsampling factors, and convert through the DCT, you're dealing with (essentially) flat planes of blocks of 64 numbers. All of the blocks can be arbitrarilly scaled down with per-item (NOT per-block) divisions that are declared ahead-of-time, before being truncated to integers and finally encoded.
Since it relies on reducing a lot of the later numbers to 0 when truncated to an integer for it's compression, simply zeroing out things further from the end of the list of numbers results in lowered quality and increased compression of arbitrary blocks, since you can't (as I understand it) declare multiple quantization matrices (what the divisor blocks are called) for a single plane.
So basically you'd be looking at zeroing out arbitrary columns in the big fat table of blocks in individual planes, optionally with zeroing out from a given column onwards. To be honest, losing things arbitrarilly in the middle could result in interesting artifacting as well, so that's something else to experiment with perhaps?
Re: Unfortunately...
Date: 2006-09-25 07:15 am (UTC)no subject
Date: 2006-09-25 05:02 pm (UTC)Working as a brush, I can see a couple possible difficulties. First, I thought that the brush would need to be some factor of 8 in size, but I could see some ways around it. What struck me as most important, was going over the same spot repeatedly with this brush tool. I don't think that a Q of 1 is equal to Q of 10 with 10 passes of the brush, so it wouldn't be as uniform a result as what you have now.
Personally, just being able to apply it to a selection would be nice, IMHO.