...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.
I saw your earlier comment on the interesting effects that can come about from bad compression and other digital glitching, and the idea IS intrieguing.
The pixilation and compression actually gives the image the suggestion of concussion and or/raw energy...and the pinking-shears effect on the gradient is pretty interesting too.
Meanwhile, to me, the combination of luminous, dense lines and the weird graininess induced by the JPEG artifacting is putting me in mind of an old book of computer art I have, where most of it went from screen to film to paper, adding in these delicious multiple levels of grot: scan lines and film grain.
Now that we can casually store, display, and print perfect images, every single technique we used to use to get around the old limitations is fair game for artistic expression. The fact that this image is 1600x700 pixels and only 44k in size is far less important now than the fact that it's so deliciously messy, in such a unique way...
*nods* I was about to mention that if you had the resources for it, you could go a step forward and see how far you could take this process in regards to printing: effects that rise from uncalibrated monitor/printer work with mismatched color profiles and the wrong sort of paper, for example.
One of the things that has always niggled at the back of my mind about computer art is how very clean and sharp it can look, which sometimes dampens its impact in my mind. This piece is, as you say, a deliciously messy alternative to all of that. And I can only imagine the creative possibilities of controlling the compression level of different parts of an image!
Frankly, I'd love to see what would happen if you took this idea and ran away with it. :)
I opted to save a high-quality jpeg of just the noise instead.
(make crisp png of the original, overlay on the noisy jpg as 'difference', then throw in a levels adjustment layer to really bring out the glory of the noise. Check out the crazy, subtle colors in the right side of the gradient!)
one of the things I love and one of the things I hate is the smoothness that vector programs like illustrator creates, i'll have to remember this for next time I want a little grit.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
egypturnash
no subject
Date: 2006-09-24 09:23 pm (UTC)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.
no subject
Date: 2006-09-25 03:22 am (UTC)no subject
Date: 2006-09-25 05:03 am (UTC)I saw your earlier comment on the interesting effects that can come about from bad compression and other digital glitching, and the idea IS intrieguing.
The pixilation and compression actually gives the image the suggestion of concussion and or/raw energy...and the pinking-shears effect on the gradient is pretty interesting too.
no subject
Date: 2006-09-25 05:04 am (UTC)no subject
Date: 2006-09-25 06:47 am (UTC)Now that we can casually store, display, and print perfect images, every single technique we used to use to get around the old limitations is fair game for artistic expression. The fact that this image is 1600x700 pixels and only 44k in size is far less important now than the fact that it's so deliciously messy, in such a unique way...
no subject
Date: 2006-09-25 12:05 pm (UTC)One of the things that has always niggled at the back of my mind about computer art is how very clean and sharp it can look, which sometimes dampens its impact in my mind. This piece is, as you say, a deliciously messy alternative to all of that. And I can only imagine the creative possibilities of controlling the compression level of different parts of an image!
Frankly, I'd love to see what would happen if you took this idea and ran away with it. :)
no subject
Date: 2006-09-25 05:14 am (UTC)JPG crushed it down to 43173 bytes, which is pretty impressive.
no subject
Date: 2006-09-25 07:14 am (UTC)I opted to save a high-quality jpeg of just the noise instead.
(make crisp png of the original, overlay on the noisy jpg as 'difference', then throw in a levels adjustment layer to really bring out the glory of the noise. Check out the crazy, subtle colors in the right side of the gradient!)
no subject
Date: 2006-09-25 02:38 pm (UTC)no subject
Date: 2006-09-25 05:41 am (UTC)It feels like the end. We tried.. and we went out with a bang and we think the bang is great.. but we still went OUT.
Weird thought. z.z;
no subject
Date: 2006-09-27 12:39 pm (UTC)