[Award Winner] Bitmapped Images - The technical side of things explained.

[Gidde]

I found this yesterday when I started trying to translate Ascension's atlas tutorial into gimp. Since PS has a set of blend modes gimp doesn't have, this was very useful. It has a pretty detailed explanation of what each mode means (multiply, etc.), but I don't think it includes the "others."

http://en.wikipedia.org/wiki/Blend_modes

[Redrobes]

Good link there Gidde and I think that covers most of the modes. Theres a minimum and a max which I didnt see. Thats where you take two images and pick the pixel from either one or the other depending on whether its red, green or blue value is brightest between the two or darkest - done on a per component basis so if one had high green and low blue then it takes the green value from one and blue from the other and result is the RGB value with that green and blue in it. Same in reverse for minimum.

By treating an image with pixel values from 0 to 255 as brightness, divide those integer values by 255 to get a real value between 0.0 and 1.0 and most of the math is done like that and per component basis and then the final image is those resultant math ops then multiplied by 255 to get back to one byte per component RGB again.

So in theory you can do lots of math with images as long as you don't mind using a limited precision of 1/255 as the smallest increment. This also shows that its better to all of your math ops on images which have brightnesses across the full range. No point in doing them on limited range shades of gray like dark colors etc. Thats where some of the height banding comes from on the height mapped greyscale images you see.

[Midgardsormr]

That article does just fine up through Screen, then the details (i.e. the math) vanish. I had the same problem with the CGTextures tutorials (which I find far more enlightening than the Wikipedia article, by the way). Some of the blend modes are explained in great depth, and others just say something like
"Soft Light: Very much like Overlay, but the result is much more subtle." So what's going on in the channels that makes the effect more subtle?

[Redrobes]

Ahh, well the exact names that people give these things I cant help out with much. If its brightest, darkest, add, subtract, multiply, difference, invert (NOT), AND, OR, XOR. The other stuff like blur etc are not math functions but I can explain how to do those along with sharpen, emboss, edge enhancements or edge finding. But the more esoteric stuff like the buttonize, soft plastic, watercolor etc are all voodoo depending on what the programmer did. I don't think that these have exact specifications.

A lot of the non strict math stuff have a set of parameters - like the blur amount for example. In this regard soft light and hard light are algorithms that might consist of several so its a bit of a recipe or a vintage wine of taste to suit.

[su_liam]

Here's a site with the math on a lot of these blend modes, and a few of his own devising.

Blend modes

[Redrobes]

This is a paper and some results of a new collaboration between two researchers, one from a university and one from microsoft. The results are very impressive:

http://www.geekosystem.com/depixelat...art-algorithm/

some interactive samples of it.

http://research.microsoft.com/en-us/...omparison.html

[Redrobes]

Another paper outlining a new way of doing similar. Dont know much about it but you can compare by clicking on the buttons. It looks good to me with a few instances where its breaking down compared to the bicubic but not many. Also, I have to say that some of these images seem to lend itself to the algorithm. Interesting zebra pic but without a high res version of the original its not possible to note whether the leg of the zebra with stripes has been corrupted and then fixed up into something visually appealing but still incorrect. Hard to say...

http://www.wisdom.weizmann.ac.il/~vi...leImageSR.html

[Midgardsormr]

It's pretty easy if you remember what "dpi" actually means: "Dots per inch." Dots = pixels (sorta, but for these purposes it's close enough). So if you have A4, which is 8.3" x 11.7", you need to know how many "dots" (pixels) fit into that area. 300 dots per 8.3" is 300 x 8.3 = 2490. That's only if you can print all the way to the edge, though, so probably plan on losing at least half an inch in each direction, making it more like 7.8 x 11.2.

7.8 x 300 = 2340
11.2 x 300 = 3360

Those would be your maximum pixel dimensions for A4 with a quarter-inch margin printed at 300dpi. You do have to make sure the printer driver honors that resolution, though. It may not be carried along in the metadata of the image for one reason or another, or the printer may ignore it. If the print resolution is not read from the file and you use some default, it may print at 100 dpi or even as low as 72 if the printer assumes an ancient Macintosh screen standard, resulting in a much larger print than you expected. If you force the printer to 300dpi mode, though, it should print at the expected size.

Just make sure that the paper you're using can handle that ink load. Ordinary copy paper will be saturated at that resolution; colors will run, and the paper will warp.

[damonjynx]

wrote stuff....

Thanks Bryan. That's very helpful, particularly the last part about paper stock.

[Voolf]

It's pretty easy if you remember what "dpi" actually means: "Dots per inch." Dots = pixels (sorta, but for these purposes it's close enough). So if you have A4, which is 8.3" x 11.7", you need to know how many "dots" (pixels) fit into that area. 300 dots per 8.3" is 300 x 8.3 = 2490. That's only if you can print all the way to the edge, though, so probably plan on losing at least half an inch in each direction, making it more like 7.8 x 11.2.

7.8 x 300 = 2340
11.2 x 300 = 3360

But how does it translate into real size? what is 2340 pixels in cm? If dpi scales the actual width and height size, what is the reason for choosing it anyway, if i can just make default 72 dpi and make dimensions larger putting what i want in pixels.