Welcome to TalkGraphics.com
Page 5 of 8 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 80
  1. #41
    Join Date
    Oct 2000
    Location
    Essex, UK
    Posts
    223

    Default

    Klaus

    I'm sorry I upset you. Nothing deliberate but a great element of confusion. In fact I think I'm getting there or maybe even there due in large part to the site pointed to by Egg. This has two small graphics (.jpg) both the same size physically and in file size but one is 200dpi and the other 2000dpi. By having a look at the properties of these graphics and spending some time thinking about it I believe I understand what is going on.

    My partner will be delighted. Anyway thanks for your understanding and patience in explaining the subject. I will nevertheless keep a close eye on this thread.

    Tracey

  2. #42
    Join Date
    Feb 2001
    Location
    Kinlochleven, Scottish Highlands
    Posts
    747

    Default

    Michael, I consider myself 'smitten' (albeit with a grin like the Cheshire Cat!)...

    But let's let the thread run — it's not graphics intensive and it's turning into a cracker!

    Peter</p>

    Peat Stack or Pete's Tack?</p>

  3. #43
    Join Date
    Aug 2000
    Location
    Leigh, Lancashire, UK
    Posts
    436

    Default

    That's ok then! [img]/infopop/emoticons/icon_smile.gif[/img]



    Michael Ward
    http://LeighCenturions.net

  4. #44
    Join Date
    Aug 2000
    Location
    Norway & Sweden & USA
    Posts
    1,233

    Default

    Tracey, welcome to the club - all is forgiven!

    :-)

    K
    www.xaraxone.com/featuredart/kn/
    www.klausnordby.com/xara
    K
    www.klausnordby.com/xara (big how-to article)
    www.xaraxone.com/FeaturedArt/kn/ (I was the first-ever featured artist in the Xone)
    www.graphics.com (occasional columnist, "The I of The Perceiver")



  5. #45
    Join Date
    Aug 2000
    Location
    Norway & Sweden & USA
    Posts
    1,233

    Default

    Small files and big memory consumption? Scanner settings and interpolation? Guys, guys - now we're really getting into the sexy stuff! Gee, maybe I need a life outside of Pixel Park?

    I'm very tempted to do a Big Article on all of these resolution-related topics, to say the Last Word on these vexing matters. But I need to find a publisher who's willing to pay me. I've just written to my German c't editor, so we'll see . . .

    Hmm, what about if you guys inundated him with imploring mails, to kick them into hiring me? It may be a dirty trick, but why not? The poor guy's name is Gerald Himmelein and he can be reached at ghi@ct.heise.de. Yes, he understands English - passably.


    K
    www.xaraxone.com/FeaturedArt/kn/
    www.klausnordby.com/xara

    [This message was edited by Klaus Nordby on December 09, 2001 at 17:06.]
    K
    www.klausnordby.com/xara (big how-to article)
    www.xaraxone.com/FeaturedArt/kn/ (I was the first-ever featured artist in the Xone)
    www.graphics.com (occasional columnist, "The I of The Perceiver")



  6. #46
    Join Date
    Dec 2000
    Location
    the twilight zone
    Posts
    1,238

    Default

    Long time ago, a monitor had a fixed setting. With a little math (remember Pythagoras?) it is easy to see that if a monitor has 14inch diagonal, and it displays 72 picture elements in one inch, then it can show 806x604 picture elements.
    Later on a monitor was made to follow the videocard and this setting could be changed. This was probably due to the fact that the strength of the magnets around the electron beam gun became adaptable. These monitors that can follow the videocard settings are called "Multisync". From then on, it wasn't necessary anymore to adhere to this 72 norm, but because of Mac's supremacy in the graphic world and their wish to stay consistent with older , non-multisync monitors, this 72 lingered and lingered on. Most writers still use this norm, just like they hang on to the hoax of 216 websafe colours because they simply copy each other. Still, depending on the quality of the monitor and its size, the maximum resolution is limited as there will be a loss of sharpness and quality if there is not at least one phosphor triplet per picture element.

    If you don't work against time, time often works for you.

  7. #47
    Join Date
    Nov 2000
    Location
    Nottingham, England
    Posts
    78

    Default

    Just to add to the confusion, I would say that to be extra safe, you should set the DPI of web graphics correctly. The PNG and JPEG file headers specify the DPI the image is stored at and I believe that web browsers are meant to use this information. The fact none of the current browsers do use this information is not really a good reason for not setting it correctly. If everything did work as intended, users would set their operating system to report the correct DPI to applications and applications would in turn use this information to render images at the right size (scaling images if necessary). This means that if you set the DPI incorrectly and then browsers start supporting DPI, things could go wrong.

    For anyone who is interested, it is possible to tell the operating system what DPI to use under Windows 2000 and XP. This can be done by going the ‘Settings’ tab of the display properties, clicking the advanced button and using the DPI settings in the ‘General’ tab of the dialog that appears. Using this, you can specify a custom DPI which shows a ruler on the screen which you are meant to line up with a real ruler. Unfortunately changing this setting can mess up a lot of Windows applications so I advise you not to use it.

  8. #48
    Join Date
    Oct 2000
    Location
    Bath, UK
    Posts
    109

    Default

    Hi there. Just thought I would pitch in at this stage. I think we have all arrived at the correct conclusion now. Scanners further complicate the issue, so here are my tips for this. For a start, forget you ever heard the term "interpolated resolution" Gee really - of up to 1800 dpi? Find out what the OPTICAL res of your scanner is (usually 300 or 600) and scan image at that res. Then resample to the actual size (in pixels)you want in Photoshop or whatever, and slap unsharp mask on it. If this makes for really unweildy file sizes, then go with 50% increments. IE if you have a 600 ppi scanner, then scan at 300 or 150. All you really want from a scanner is an image as nice and sharp as possible. You can't expect the built in software on a £100 scanner to achieve any acceptable results. The resampling engines on Photoshop and PSP are actually built for the job, so use them instead.
    I'm glad this topic came up and some Xarans have been enlightened. I know i was really confused about the whole issue for ages. And yeah..those respected expensive big books don't explain it either. 72 ppi indeed! Pah! For further reading on scanners and resolution, I would highly recommend http://www.scantips.com

  9. #49
    Join Date
    Aug 2000
    Location
    New York, NY, USA
    Posts
    171

    Default

    <BLOCKQUOTE><font size="-1">quote:</font><HR>I would say that to be extra safe, you should set the DPI of web graphics correctly. The PNG and JPEG file headers specify the DPI the image is stored at and I believe that web browsers are meant to use this information. <HR></BLOCKQUOTE>

    Okay, but what DPI is "correct" for the web?

    Marcus Geduld
    { email me } { visit me }
    Marcus Geduld
    { email me } { visit me }

  10. #50
    Join Date
    Aug 2000
    Location
    New York, NY, USA
    Posts
    171

    Default

    I DID oversimplify one point in my long post when I wrote, "Filesize is determined by number of pixels -- NOT by dpi." This is true, but it's not JUST number of pixels that determines filesize; it's the number of pixels AND the color bit depth. Or, more precisely, it's number of pixels times color bit depth.

    You all probably know that computers only understand ones and zeros (in reality, the understand positive and negative electrical charges, but we can think of them as ones and zeros). A BIT is one binary digit. So this is a bit:

    0

    And this is also a bit:

    1

    When you save an image file (in Photoshop or whatever), each pixel's colors must be translated into a code, and the code must be made out of bits. It doesn't really matter which color is translated into which sequence of bits. For instance, we could decide that 0011010 = red. Or we could decide that 11110001 = red. As long as we're consistent in coding and decoding, we're fine.

    The question is, how many bits do you need to describe all the colors in your image? The simplest method would be to use 1 bit to code each pixel's color. So each pixel could be either 1 or 0. Which means you only get to use two colors. Traditionally, an image with a color bit depth of 1 is a black and white image. 0 = black. 1 = white. But 0 and 1 could be any two colors. You can visualize a 1 bit depth images like this:

    00000000000
    01111111110
    01000000010
    01010001010
    01000000010
    01000100010
    01000000010
    01011111010
    00000000000

    If you look closely, you'll see this is a little white face against a black background.

    Obviously, 2 colors isn't enough for most images, so 1 bit depth images aren't used very often. But you do run into alot of 8 bit depth images. 8 bits might look like this: 00101110. Or this: 11010101. In an 8 bit depth image, every color is coded into eight bits. How many colors does this give you? Well, if you figure out how many possible combinations of ones and zeros you can have when you line up eight of them, the answer you'll get is 256. So you can have a maximum of 256 colors in an 8 bit depth image.

    8 bits is also known as 1 byte. Computers work very efficiently with bytes, which is why you run into the number 256 so often when working with computers (actually, you usually run into the number 255, because the 256 values are specified from zero to 255 rather than from one to 256).

    An 8 bit depth image might look like this (I've used spaces to indicate where one pixel starts and another one ends):

    01011001 01001110 10101100 11000111 00001100 01011001
    10100111 00111011 00100111 11110011 00100111 11000111
    01110000 01111000 11111110 01011001 01011001 00100111
    10101011 00001100 01011000 00001100 11000111 01011001
    11110011 00111000 00000110 11110011 01011001 00001100
    00111100 11000111 01111000 00100111 01011001 01011001

    This image is 6 pixels across by 6 pixels wide, so it contains 6 x 6 = 36 pixels. Each pixel contains 8 bits, so the entire image contains 36 pixels x 8 bits = 288 bits (or 36 bytes). Incidentally, I kilobyte = 1000 bits. So this image is well under 1K.

    Where do you find 8 bit depth images? All over the web, that's where, because all GIFs, animated or otherwise, are 8 bit depth images. That's why GIFs can only contain up to 256 colors. Which is why they're not very good for photographs, which usually contain thousands .or even millions, of colors.

    On the web, we use JPEGs for photographs and other complex color images. This is because each pixel in a JPEG is coded into 24 bits (3 bytes). So two pixels next to each other in a JPEG look like this.

    010110010101100101011001 1111100100101100100000001

    If you have a 300 x 300 pixel JPEG on your website, that's 30000 pixels altogether. 30000 pixels x 24 bits = 720000 bits. 720000 divided by 1000 = 720. So this is a 720k image. (Note: if you try to create a 300 x 300 pixel JPEG in Photoshop, you may wind up with an image well under 720k. This is because JPEGs can be compressed. If you compress a JPEG, you lose some quality, but the filesize gets smaller. Also, an UNCOMPRESSED JPEG with these dimensions will be a bit LARGER than 720k. This is because there's some other info stored in the file besides the pixels and the color depth).

    How many colors can you get with 24 bits to describe each color? Over 16 million! Which is the maximum number of colors currently displayable on standard computers.

    Programs like PhotoShop build all colors in web images out of three primary colors: red, green and blue (The RGB system for web is generally NOT used in print -- except with desktop inkjet printers. Most print graphics use the primary colors cyan, yellow and magenta. Supposedly, you can build all standard print colors out of these primaries, and if you mix them altogether at their maximum intensities, you SHOULD get black. But due to impurities in ink, it's very difficult to get true black from the primaries. So print systems "cheat" by throwing in black ink. The four-color printing system used in print is often called the CMYK system, which stands for cyan, yellow magenta and black -- K stands for black, because if B stood for black, people might confuse it with blue.)

    In a 24 bit depth graphic, each pixel is composed of three bytes: 1 byte = 8 bits. 8 + 8 + 8 = 24 bits. Each byte is used for coding one of the three primary colors. The first byte is for red, the second for green and the third for blue. So ONE pixel in a JPEG might look like this:

    RED: 00101110
    GREEN: 11101010
    BLUE: 10100101

    Since each byte can equal any number from zero to 255, you can see that each primary can be set from 0 - 255.

    RED: 0 - 255
    GREEN: 0 - 255
    BLUE: 0 - 255

    A pixel set like this ---

    RED: 255
    GREEN: 0
    BLUE: 0

    -- is pure red. Whereas a pixel set like this --

    RED: 0
    GREEN: 0
    BLUE: 0

    -- in pure black (imaging three flashlights in a completely dark room. One shines a red light, one shines a green light and one shines a blue light. If you turn them all off, NO lights are shining, so you get pure darkness -- pure black.)

    RED: 255
    GREEN: 255
    BLUE: 255

    This is pure white (the more lights you shine, the brighter -- or whiter -- the total light).

    In HTML colors (like the background color of a web page) are specified using "hex codes" like #32FC0D or #99BB21. What do these mean? Well, when people count, they tend to count in base 10. This means that multiples of 10 are really important to us. We give mystical significance to 10, 100, 1000, etc. Remember all the flack about the year 2000. Many biologists have suggested that out obsession with tens comes from the simple fact that we have 10 fingers and 10 toes, so we learned to count in 10s.

    And we have 10 digits: 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9. Imagine if we came from a planet where everyone had 16 fingers. We'd probably have 16 digits and we'd count in a base 16 system. Base 16 is easier for computers to handle than base 10. So to please the machines in our lives, we sometimes use this awkward sytem. We don't really have 16 digits, but we can use letters of the alphabet to stand in. So we write the 16 digits as follows:

    0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E and F.

    Translating from base 10 to base 16, we see that:

    0 = 0
    1 = 1
    2 = 2
    3 = 3
    4 = 4
    5 = 5
    6 = 6
    7 = 7
    8 = 8
    9 = 9
    A = 10
    B = 11
    C = 12
    D = 13
    E = 14
    F = 15

    (The digits end at 15, not 16, because they start at zero, not one -- just as in our base 10 system, the ten digits end at 9 not 10.)

    Sometimes base 16 is called hexadecimal, so we can call the HTML color codes hex codes, because they use base 16 numbers to encode 24 bit depth colors.

    Lets look at an example: #48CAF9. When looking at a code like this, ignore the pound-sign at the beginning. This just tells the computer we're using the hex system. But immediately following the #, there are always six hexadecimal digits. The first two represent red, the second two green and the final two blue.

    So #48CAF9 can be broken down as follows:

    RED: 48
    GREEN: CA
    BLUE: F9

    In the hex system the possible ranges for each primary color run as follows:

    RED: 00 - FF
    GREEN: 00 - FF
    BLUE: 00 - FF

    I won't waste your time with a lot of base 16 - base 10 translation, but you should know that 00 = zero and FF = 255.

    So this is pure red:

    RED: FF
    GREEN: 00
    BLUE: 00

    Or we can express it like this #FF0000. This is pure black: #000000 (all colors turned off). This is pure white #FFFFFF (all colors turned up to 255). Most mortals (myself included) don't work well with these codes. I can understand #FFFFFF, but I have no idea what color this is: #CA82F3. Which is why I use programs like Photoshop in which I can pick a color and let the program tell me the code. You can also buy swatch books with hex codes under each swatch, but you'll never find a book with ALL colors and ALL codes, because there are over 16 million of them!

    Finally, I'd like to discuss 32 bit depth graphics. You'd think that by going from 24 to 32, you'd get even MORE colors, but that's not true. Both 24 and 32 bit graphics support the same 16 million (or so) colors. But whereas 24 bit graphics contain 3 bytes for each pixel --

    RED: 0 - 255
    GREEN: 0 - 255
    BLUE: 0 - 255

    -- 32 bit graphics contain four bytes for each pixel (8 + 8 + 8 + 8 = 32):

    RED: 0 - 255
    GREEN: 0 - 255
    BLUE: 0 - 255
    ALPHA: 0 - 255

    Sometimes this last byte is referred to as the "alpha channel" and it's used to define TRANSPARENCY for each pixel. So --

    RED: 255
    GREEN: 0
    BLUE: 0
    ALPHA: 255

    -- Is a pure red pixel that is fully opaque. Whereas --

    RED: 255
    GREEN: 0
    BLUE: 0
    ALPHA: 0

    Is a pure red pixel that is totally invisible (so it's color really doesn't matter). And --

    RED: 255
    GREEN: 0
    BLUE: 0
    ALPHA: 128

    is a pixel that is 50% transparent, like the glass in a stain-glass window.

    Why is this called ALPHA and not TRANSPARENCY? Because the original computer scientist who came up with this coding system randomly chose the word "alpha" to name the extra information. (This might by untrue. I've heard this for years, but there's something mythic about the sound of it.) But it MEANS transparency.

    Unfortunately, JPEGS only support 24 bit depth graphics, which is why you can't have a JPEG with a transparent background. Tiff graphics support alpha channels, but this doesn't help us on the web, because browsers can't display tiffs. And if you try to convert a tiff to a JPEG, the alpha channel with be stripped out. GIF graphics do support a crude sort of transparency in which one color can be designated as transparent. But this isn't true alpha transparency, because the tagged pixels are always 100% transparent. You can't make a stain-glass window with a GIF. The only type of web graphic that supports alpha channels is the experimental PNG. PNGs are not supported by pre-version 4 browsers, so many people don't like using them. Also they tend to have larger file sizes than GIFs or JPEGS. Also, I'm not sure if all the current browsers can read the alpha information in PNGs. But they will probably become more useful as newer, more sophisticated browsers come out.

    Sorry about the length of this post, but this info has been really helpful to me. Hopefully it will also help some of you!

    Marcus Geduld
    { email me } { visit me }
    Marcus Geduld
    { email me } { visit me }

 

 

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •