Jump to content

Pixel Play


Janel

Recommended Posts

I started to put this on the metal clasp thread and felt too intrusive on the serenely beautiful images which Doug and Jim were sharing with us, so moved it to its own topic.

 

When Don complimented the fine, large but low k file of the JPEG image of the katakana, I played a little with my theory and what I've noticed about various images being saved for the web. The second post, with the garden background katakana image, is actually the first part of this thread, and this is a follow-up example.

-----

 

I wish I could find the source of my partial memory of the pixel/color/filesize topic. Instead, I've played with a new image the size of the katakana (800 x 545 pixels), and mock saved for the web at 100%. (I will spare you the illustrations, but will describe the path of discovery)

 

1- all white or all black = 5.35k

2- half white half black = 6.36k

3- quartered (two separate w & bl) = 7.48k

4- 8ths (four white four black-grid) = 9.12k

5- 16ths (eight w & bl grid) = 11.64k

6- 16ths-same but one is filled w/ red = 13.64k

 

See where this is going? I then put the blocks back together, edges touching

 

7- one red 16th, 7 16ths black, the rest (half) white = 8.37k (compare this to #2, half black half white = 6.36k)

 

Pixels are a dimensional piece of memory, but it seems that they also are counted by the variety of colors and dispersion.

 

The more different colors, the more to count, the more difference between the pixel's neighbors, the more to count.

 

Now, someone who knows about this please use what ever means of description to explain this correctly, please! I will keep looking for a written text to describe this technically and cleanly for you.

 

So what did you do with your Saturday afternoon and evening? I've been with the family mostly, but played with this during "my" time! :) I think it is fun!

 

And I apologize for straying from the serenely beautiful images in the metal clasp thread. I should know better.

Link to comment
Share on other sites

The above pieces are exquisitely beautiful. It just can not be done in any other medium than metal! (a seriously envious smilie, trying to imagine the wimpy effect this might have if done in wood alone :) )

 

Image lesson for the Photography forum: (I figured this out over time when file sizes were surprisingly different. There was something to be learned from that, though I still don't have ALL of the answers.)

 

Half of the katana image is filled with a very monochromatic, untextured background, so way more pixels have not had to be registered as an individual color.

 

For a contrasting example: I found a garden picture which has lots of two sorts of colors, with lots of variety between them. I took the shape of the gray background, copied a background from the garden photo and pasted it onto a layer over the katana, then merged the layers, and saved for the web at the following percentages.

 

19% = 54.9k (shows up in the finder as 56k)

20% = 72k

100% = 425.7k

 

Just to know more, I have saved for the web the original image harvested from this page:

 

100% = 124.9k

50% = 58.9k This image matches the pixelation of the 100% original image when the image is opened to 300% viewing.

 

I do not understand all of this, but the difference between the garden image at 100% and the original image resaved at 100% shows a relationship that must be interpreted by the difference of the backgrounds.

 

This is the 19% version at 56k:

 

katana_garden_19.jpg

 

 

When enlarged to 200%, there is much pixelation at 19%, but the saved file size is nearest in pixel file size to the original, more clear original katana image (which by the way, is pixelated a bit when magnified to 200%).

 

Interesting?

Link to comment
Share on other sites

Quick post-midnight reply on the issue of jpeg compression.

Like most compression algorithms (like mp3s for example) the jpeg algorithm tries to "summarise" the information in order to make it more concise.

In other words, the RAW format basically describes the characteristics of EVERY single pixel. The jpeg algorithm finds patterns in the picture and compresses accordingly. When the patterns are broad and can characterise large chunks of the picture (like the almost uniform background in the handle picture) the compression is more effective. When there is a large number of patterns (like the busier background that Janel added) the compression is less effective and the resulting image is larger.

 

In Janel's B+W examples, the more you spread the black and white pixels, the more patterns emerge, hence the image size is enlarged.

 

Think of it this way: some books can be summarised in one or two sentences and other require a few paragraphs. The length of the summary depends on how 'meaty' the material is.

 

Eyes are red and need some sleep. Let's see if this makes sense in the morning :P

 

Happy New Year to everyone.

-t

 

 

edit: (2 min after the original post :P) As an example think of the background in the picture of the sword handle. You can either describe every single pixel OR you can simply say "vertical gradient from medium grey to light grey". In the first case (which would be the RAW format), you have perfect accuracy but laaaaaaaaaaaaarge files, in the second case (jpeg) you have efficiency (small size) and pretty adequate reproduction.

Ok off to bed. Really... :)

Link to comment
Share on other sites

Good morning Tom and Toscano,

 

Toscano gets the concept that I am trying to describe, and Tom's first part of his question is part of the concept as well. I was not trying to describe compression, yet (and now I won't need to), but it is part of the concept of file size relationship to the image complexity and variation of colors. Thanks guys.

 

When preparing the images for the potter's tour web site recently (a regional group), I was reminded of this when saving the different images for the web. I was seeking as low a resolution in about fifty 240 x 360 pixel dimension images. A standard, automatic/equal percentage quality compression would have given a range of poor to good quality compressed images. Each piece was adjusted by hand, to just before the edges began to dance (my term for pixelating blur of the edge of the pot into the background). The variation had to do with the complexity of the pot and its surface, and the degree of variation in the background of the slide.

 

As an artist in the late 20th century, the pressure to move beyond film and to learn about digital imagery has forced many of us to learn about digital technology. My digital knowledge is not complete, but with repetition and asking questions, I am learning more. Since more shows, publications and image files are requiring digital information, it has been imperative that I learn what I can to be responsive to the requirements. It is not an easy time for older artists, especially those who don't have the ability to comprehend digital technology (for example, some artists can only do 2-D or 3-D work, not both) .

 

One urging to artists who supply slides to be scanned for subsequent use, please be sure that the slide is absolutely without dust and in good condition. A scanning technician will likely not clean the slides, and the dust, scratches and damage will be read by the scanner. The person who then uses the scan must spend time repairing the damage with photo processing software, time which could have been avoided at the outset. If you are paying someone to do that, your costs are multiplied. If you want a magazine to print a great picture, it can only be as good as the slide you give to the publisher.

 

Just food for thought as we rev up for the new year. :)

 

Janel

Link to comment
Share on other sites

Hi Janel,

 

I think I can answer your basic question about compression algorithms and file size if you want. Rather than just bull on ahead with a long technical description, I'll await your reply on whether or not you (or other forum members) want to read such a thing. You seem to have mastered the techniques for working with lossy compression limitations, even without a deep technical understanding, so I'll leave it up to you.

Link to comment
Share on other sites

OK, Don, you asked for it – no whining now!

 

Simplified Computer Graphics 101:

 

Computer images (in microcomputers like we typically use) are usually represented as RGB images (Red, Green, Blue). If you go look closely at your color tv screen (use a magnifying glass and just brave the x-rays) you’ll see it is composed of lots of little color dots (pixels). At each tiny location on the screen, in close proximity, is a Red, Green and Blue dot. By turning on each dot individually and controlling its’ brightness in combination you can come up with every color the screen is capable of showing. Computer color images (RGB ones, that is) act exactly the same way.

 

Each RGB color pixel is represented in the computer’s memory by three 8-bit bytes, one for each of the Red, Green and Blue color “channels.†Each 8-bit byte can store a number ranging from 0 to 255, so there is a possibility of 256 “values†(255 plus zero = 256) of red, or green or blue. Mixing the three channels together gives us over 16 million (256x256x256 = 16,777,216) possible combinations of colors. Of course, while this is fine mathematically, I question whether the human eye is capable of telling this many colors apart. If, for example, we have a pink pixel and change the adjacent pixel to the next “pink†value, I don’t think you would be able to tell they were different colors, even if your monitor was capable of showing this faithfully.

 

So, every color pixel takes three bytes to represent its’ color. Since computer memory appears to the computer’s “mind†as an incredibly long string of memory, from memory location zero to the limit of your RAM (many millions of memory locations, or bytes), we have to have a means of describing how to line up this long string of pixels into a rectangular image. Each image file has a header of information to describe such things as how wide and how tall the image is (as in Don’s suggested posting size limit of 640x480 pixels), what it’s physical size is supposed to be (as in 2 inches by three inches), and whatever else the programmer thought was important.

 

These sorts of things are determined by standards, as in the JPEG standard we typically use. JPEG is actually an acronym, and stands for Joint Photographic Expert Group, who came up with the original description of JPEG representations and compressions. JPEG is a useful standard since it describes a method of image file size compression implemented by practically everybody, so your web browser can look at any JPEG picture on the web and know how to handle so it looks at least remotely right on your computer screen. Incidentally, there are lots of image “standards†and compression methods. GIF, TIFF, JPEG, PNG, and BMP are probably the most common ones the average person will run across.

 

OK, with that said and understood(?), we’re now ready to tackle a simple description of compression. Since each RGB pixel takes three bytes to represent its’ color, and its’ location in the long line of bytes describes its’ location, plus a header of assorted other important information, you can see an uncompressed image file can be quite large. Oh, hell, let’s call it like it is, it is absolutely HUGE. A not very large 640x480 RGB image is 900 kilobytes (921,600 bytes representing 307,200 pixels) in Adobe Photoshop internal RAM memory. Almost a megabyte. With the addition of the added header info, the file would be a little larger than that if we were to save it in an uncompressed format. We would be eating up our hard drive storage very quickly if we didn’t compress them. Think about your digital camera. Mine takes 4 megapixel pictures. That’s 4 million dots of color – times 3 bytes per pixel makes a 12 megabyte file in uncompressed format. Doesn’t take many of those to eat up your many-gigabyte hard drive. That’s why my camera can keep about 50 JPEG compressed photos in its’ memory, or just a couple of high quality photos.

 

A simple compression method is to change the basic uncompressed file format to a description that reduces the amount of hard drive storage needed. We’ll use four bytes to describe each pixel, one for the number of adjacent pixels of the same color and three for RGB color description. For instance, if I had ten red pixels in a horizontal line, I would have one byte (with the value of 10) to tell me there were ten of them, and three bytes to tell me the value of the color red. Uncompressed, the representation of the 10 red pixels would take 30 bytes (10 pixels x 3 RGB color bytes = 30). Using our simple compression scheme, we accomplished the same thing with 4 bytes (1 byte [containing the value 10] x 3 RGB color bytes = 4). A huge savings in file size.

 

OF course, there is a fly in the ointment. You knew there had to be. How well this scheme works depends on the image. If for instance, my image is a 640 x 480 plain white field with a single vertical red line in the center, our compression algorithm would work fine. Uncompressed, the file size is 900kbytes, using a medium jpeg compression the file size is 56kbytes. Our simple file compression system would work even better (in this case). We would need only 12 bytes to describe an entire line of pixels. 4 bytes would describe the white pixels before the red pixel, 4 bytes would describe the red pixel, and 4 more bytes to describe the white pixels after the red one. Multiply the 12 pixels for the first line times the 480 pixels tall size, and you have the file size of the entire file, plus a little for the header info (total of 5,760 bytes, or 6 kilobytes, whereas the JPEG file is 56 kilobytes).

 

This simple compression works fine for images that have lots of pixels next to each other that are the same color, but we can postulate an image where the compression works against us and actually enlarges the file. If we take the same 640x480 pixel image and make every other vertical line a different color, we find our 4 byte scheme actually makes the file larger. Our first byte tell us how many pixels in a line have the same color, in this case 1, plus the three RGB color bytes. So, if we have 307,200 pixels, our compression scheme gives us a file size of 307,200 x 4 bytes per pixel = 1,228,800 bytes. Using our uncompressed format would give us a file size of 307,200 pixels x 3 bytes per pixel = 921,600 bytes. Our compression algorithm obviously doesn’t work in all cases.

 

So it is in real life with JPEG format. JPEG compression actually divides the image into 8 by 8 pixel blocks, “adjusts†each of those blocks using a Discrete Cosine Transformation based on the Low, Medium, High, Maximum quality scale the user designates when saving an image in JPEG format, then sorts through all of these 8x8 blocks to make a table of similar blocks. So, the JPEG compressed format does something like our simple algorithm by making a description of each unique “kind†of block and saves out the information so each block can be recreated when the file is opened again. The savings in file size come from being able to link lots of identical blocks to a single description of each “kind†of identical block. In other words, a single block description serves for lots of blocks. Of course, this works well for some images, and not so well for others. A checkerboard of red and yellow 8x8 pixel squares would result in a table containing 2 very simple block descriptions, and a place holder for each block – a very small file. In practical terms, I’ve found a closeup image containing lots of blades of grass doesn’t compress well at all, since there aren’t lots of similar 8x8 blocks. Each block tends to be pretty unique.

 

Now, let’s talk about “loss.†JPEG, as we see it implemented in most of our common applications is a “lossy†format. That means that the original image cannot be reconstructed completely from the compressed file. There is some loss of quality when the 8x8 blocks go through the Discrete Cosine Transform. If you don’t do this transform, however, then pretty much every 8x8 block in your image is unique, so your block description table is huge – result: no file size savings, or perhaps even a larger file than the raw format you started with. So, there is a tradeoff you’re making here. Sometimes, that tradeoff is making a deal with the devil, sometimes not. That’s why Janel’s description of tailoring each image based on the pot and the background is appropriate. As in much of art, science only takes you so far, and that’s where the “art†comes in. Lots of color changes in an image, as in blades of grass, or very smooth color gradients don’t compress well. You can see some of this by looking at the color bands in this sample image. I made a plain red gradient, then saved it as a Low quality JPEG. I’ve inverted a part of the image (the blue-green area in the lower half) to try and show the different bands a little better. What started out as a very smooth color gradient comes back as stripes of identical color. Not too bad, but a loss after all. You can see this a lot of times in the backgrounds of our arty images. It all depends on your requirements – small file size, or good quality. You can’t have them both. That’s why you have a smorgasboard of options in the JPEG format.

 

So, is this clear as mud?

 

If you really want some punishment, you can go here to see more discussion of the JPEG format: JPEG Specs

post-11-1137361575.jpg

Link to comment
Share on other sites

I did not read it yet, but WAY TO GO! You've made me laugh! I thought I could fill a page with text!

 

Yes, Tom, I would like to learn more too! (stated after the fact) I will go have a read now!

----------

 

Phew! Thank you Tom, that has been a very helpful description to read. I do understand it much better now and appreciate the clear presentation you have made.

Link to comment
Share on other sites

I thought about it for a little while, and came up with a few rules of thumb for using JPEG and GIF compression, so for what it's worth:

 

Don’t work on the original, work on copies, so you can go back to the original when you screw up. There are them that have, them that will, and them that will again.

 

Use the largest size original image possible.

 

Only resize down in size.

Never resize up in size.

Only resize once. IF your final image is still too large, determine the real size you need and go back to a clean copy of the original and resize again from scratch.

 

Quality isn’t a number - use your own judgment.

 

The less resizing steps you do, the better things will be. Every resizing loses more information and degrades the image.

 

Many graphics applications provide for several sampling algorithms for resizing ("Nearest Neighbor," “Bilinear,†"Bicubic," "Bicubic Smoother," "Bicubic Sharper," in my version of Adobe Photoshop). You may not know what they mean, but if you aren't happy with your results, try a different method.

 

JPEG compression generally works best for color “photograph†type images, or images with large areas of slowly varying colors, like gradations.

 

Experiment with different JPEG compression levels and use the highest level that provides the best tradeoff between acceptable image quality and file size.

 

GIF is a lossless type of compression. GIF tends to work best for images like line drawings, diagrams or text on single color backgrounds, or images with transparency (useful for website graphics so you can see the page background). GIF also allows moving images in small file sizes.

 

PNG will most likely replace GIF in the future, but for the time being many WEB applications and browsers do not support it.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...