Hands on your home page - Part 2
- 1 Hands on your home page II - Photos and images
- 1.1 Polite and Considerate
- 1.2 GIF or JPG
- 1.3 How to be provident?
- 1.4 Adding images to your page
Hands on your home page II - Photos and images
Have you ever visited a web page without any image or similar items added to it? Sure, but it is not every day, or let us say, text only pages are very rare. And when you find them they are close to always very boring and of technical kind or alike. Last time we learned to create such pages, though with lists and links.
This time we will concentrate on images only. Honestly I do not know much about how to add sound, I have added quite a few applets and I really know how to wrest my HTML around. If I need to I will learn more on the sound tag and other tags as well <grin>.
With images we first have to discuss being polite, considerate and provident. Then we will continue with the two different image formats mainly used, the differences and which one to use. How to take and edit screen shots will be explained and how to then be polite and provident.
Of course we will finally see how to add the edited images to the web pages, letting them be links if you like to.
Polite and Considerate
Still most of the private users are connected to Internet through a dial up line, generally using modems. I have no figures on which speed is mainly used, but I think quite a few still use a 28.8 [#note kilobit] modem and that is slow when surfing non-polite modern sites. Every single item that is added to a page forces the browser to make another connection and download that item. The time to connect is something between a tenth of a second to ... you name it, the server may be heavy trafficked or the cable shared by too many users, and you do pay the telephone costs. To that we add the download time. Pretty much here we see that being polite and considerate is to reduce the number of items added to a page and reduce the file size of each item.
The number of images may be resolved by this simple question: "Does this image bring value to the text (or page) and is it then essential?" If "No", then drop it.
Further we do not know much about the readers' screens, do we? There are still an amazing numbers of 14" screens around, and a lot of users with 640 x 480 screen resolution. But most of the web designers are playing with 21" and 1280 x 1024 or better. What a conflict indeed! But being polite and considerate is to care about the common user, isn't it? Hence no image will be wider than it can be viewed by any reader. What sizes are we talking about then? Do not be misled by the 640 x 480 figures since first the web browser will take a number of pixels away, let us say about 30 pixels, and then the page may be styled using tables and thus it is only the width of the table cell left, minus cell padding if used.
For example, this page is constructed using a table (that topic will be discussed in the next article) and the "page header" containing 1/ the logo, 2/ the vertical coloured bar and 3) the navigation links (which themselves are put in another small table) above the article headline. These three items are put in separate cells. If I would like to use an image immediately beneath the head line, how much is left to the rightmost cell?
- The logo is 240 pixels wide, the vertical bar (an image resized to 2 x 400) are padded with a horizontal space of 10 pixels each side summing up to 2 + (2 * 10) = 22 pixels, that is 240 + 22 = 262 pixels only for the first two cells, and to that we add 30 pixels for the browser, ending up with almost 300 pixels. If then the reader use a 640 x 480 screen resolution there is only an image width of 340 left in our example.
If we, on the other hand, are placing the images in the big cell containing this text we can use up to a width of 600 pixels but no more. As you have seen there are two page styles used in OS/2 e-Zine, the common style and the style of my articles used so that code lines may be of a usable length. The common style does not offer space for images wider than 340 pixels, else some users will run into trouble.
- Reduce the number of items
- Reduce the file sizes
- Use no images wider than 600 pixels or computed from the available space
You can not do much about the bottlenecks on the Internet, but you can help not to overload it. You can not give greater screens to everyone, but you can help not to overfill older screens. The next part will guide us into the technical part of our qualities.
GIF or JPG
The two most used image formats on the web are GIF and JPG. GIF (Graphics Interchange Format) was designed in 1987 and was added some features in 1989. Since GIF uses a file compression algorithm patented by Unisys, some application makers have chosen not to support GIF, but it is still the most widely used image format on the web. GIF gives you a maximum of 256 colours, though the palette may be chosen anyway you like. That is all of the 256 colours may be shades of red if you like. Further GIF is a lossless format and hence preserves images with a limited numbers of colours very well.
JPG, or JPEG as it is actually named, is on the contrary a "lossy" image format, and thus destroys the image upon compression. On the other hand it reproduces photographs very well with plenty of colours. That this format is "lossy" excludes it from some uses, it really destroys the image that the decompressed image is not the same that you saved. The eye will not easily see the loss but it is still there, the eye is "fooled" to think that the image looks perfect but it does not. Images may be more or less compressed, thus providing a minimal to maximal loss. For more details I recommend the exhaustive Help of PMView.
When to use GIF or JPG?
The common answer is, use GIF to screen captures and plain images, and photographs and alike are saved using JPG. If the images uses 256 colours or less you may always use GIF and then try to convert them to JPG using different compression degrees and compare the file sizes. Can photographs be converted to GIF? Sometimes, sometimes not. You have to try and see. Many times the file size will increase and thus there is no benefit to it. But you can not convert a JPG image to GIF and get a good result, since the JPG format is "lossy"
- Screen captures & plain images => GIF
- Photo quality => JPG
What is web safe (or Netscape) colours?
Upon the time when colours were limited in numbers but the web was evolving fast there was a scheme introduced that used only 216 colours, only 6 shades of red, 6 of green and 6 of blue. These shades were fixed to certain values that the older browsers supported, and until this day some still can not render more than these, believe me. So if you really like to be safe then you save your images using GIF and 6-6-6 palette type. Another benefit is that the file size may be drastically reduced without that much quality loss, hence I recommend you to always give it a try.
The Java instalment of September, the ColourBox article, used a screen capture that originally looked as the upper image. It used 24-bit colour depth and had a file size of 7,966 bytes using the GIF format. Trying to use JPG with 75% quality gave me 13,856 bytes in spite of using "Optimize entropy encoding" that further reduced the JPG file size about 3 kB (without this latter encoding the file size was about 15 kB, more than double compared to GIF).
The next image is saved using the 6-6-6 colour palette. That image have a file size of 4,402 and is only using 14 colours. As you see there is no important difference in the image quality. The difference is mainly seen in the shading of the buttons of the upper right corner that are more brutally shaded. But since the essential part of the image did not get lost I was pleased with the result and used it.
Hence we find that by using the 6-6-6 palette we almost halve the image file size. That is not the case every time but in most cases we will benefit from using that colour palette. Not only the file sizes decreases, black will indeed be black and white will be white, as red, green or blue will be clear and crisp. But more on that later on.
How to be provident?
We will start from the end, the image size, since it is the best thing to start with. As stated the image size is set by the available width, maybe set by the screen, or maybe by how the table of the page is created. First you have to figure out the worst case and that will give you the maximum image width. The height is not that important, but do not be too optimistic. Once you have computed a usable image width you can get such an image.
There are two file formats to use, photo quality images and simpler images such as screen captures. If the image you want to use is of photo quality let us hope that it is of high quality from the beginning, else it may not be possible to transform the image size. You have to try and see how the result looks like. It does not matter the quality of your image editor, if the file you have to work with is too heavily compressed you are in trouble. Then try to get the original file and work with a copy of that one. Or maybe drop the use of it.
If you get a good image to start with, first transform it to the image size you will use, then you can start experiment with it (please save a backup copy first) to see how hard you may compress it and if it is as good looking when using GIF. As long as the image quality is okay to you it is only thing that matters is the file size. This part is a mere time consuming experiment, but soon you can see such things by a short look at it.
When you are planning for a screen capture (a dump) there are some steps to take. First the image size, then the file size.
You will get the best result if you can take the snap shot at the size you will later use. For example, you like to get an image 260 x 200 and it will be a complete application frame, like the one above. Then try to resize the application that it is 260 x 200 from the very beginning, hence you will get no loss as when you later try to resize it by the image editor. Transforming the image size later on will indeed give you a quality loss.
Sizing an window to the wished width and height is not always as easy as it looks like. Some frames, or perhaps most often dialog boxes, do not allow resizing. How do you do then? First try to capture the item and transform the size using your favourite editor (Note, the application I used for this article is PMView. But most image editors have features that work more or less the same way), but if the quality loss is too heavy, lessen the resolution of your own screen (perhaps you then have to reboot) and take the snap shot from there. Then return to your usual resolution. Cumbersome, yes indeed, but considerate.
Taken the preliminary steps the snapshot is very simple. Under "File" you find "Capture" that gives you some options and a necessary "Setup". The setup may be "Instant" , "Delayed by ... seconds" or "Activated by ..." and some options more, pretty self explanatory. After accepting your choice you have to choose between the options viewed at the image. A suggestion may be to get the "Window" and later make a selection of the captured image using your mouse button number one.
Having the capture at hand, do not save the screen dump as JPG or some other "lossy" file format that destroys the snap shot. If the number of colours are more than 256 you perhaps can not use GIF either since that file format will drop colours. Then you are to use PNG or TIF file formats that are fully lossless. But since TIF are not always fully supported by other applications, maybe PNG is a somewhat better choice (PNG is in fact supported by Netscape/2).
A last word on image sizes, it is not always essential to get the whole of an application, maybe it is only one item of an application you are interested in, then limit yourself to that part. Every extra stuff included only mess things up. And the image size increases.
What do I do if my image really is too big anyway?
Then you create a "thumb nail", use your image editor to transform to a smaller picture and save that as a originalImage_small image, that you use at the web page but that also works as a link to the full sized image. Or, capture an interesting part of the image to use as that link. This technique may be used in two circumstances, when the image size is big, or when the file size is big and cannot get reduced. Then it is always better having a link to the bigger image and let the reader do the decision if to download that image or not. Do not forget to tell the reader the image and file sizes.
If the image is of photo quality, please see above under "How to be provident?" and then try "Save as" and choose the JPG file format, go to "Options" and you will see the dialog box shown here. PMView recommend a "Quality" of 75% and I recommend you to use the "Optimize entropy encoding" that further reduces the file size. The "Smoothing" can help both to give you better results, filtering away noises, and lessen the file size.
Then it is safe to "Save" from the "File save" dialog box. Under "View" => "Show" you check the "Image Info" option and then you may see the actual file size. Keep this box open when you experiment with different "Quality" and "Smoothing". Unfortunately you can not see the file size until you actually saved the file, and that way destroyed the one you had before. Fortunately the "Undo (Ctrl+Z)" works (PMView folks, a suggestion is an option to compute the future file size in advance).
Some applications support the "Progressive JPEG" that when used over a network sends the image in scans that the image will be sharper as the times goes. If you do not know if this feature is supported or not, leave it unchecked.
Once you have found the most optimal mix of settings, combined with the file size, you are done.
If the image is a screen capture of an application, a terminal, a dialog box or similar, I am certain you can save the copy as a GIF. Then you choose "Color" => "Convert to" => "Indexed 256-Color (8-bit) ..." and another dialog will show up. I will discuss the options to some extent.
To the left you see "Palette type" and five options. Talking screen captures of applications I recommend "6-6-6 levels" that will give you a good file size without too much quality loss (see discussion above). And best, you do not have to do so much tinkering yourself later on, but still it is you that have to try and see.
The "Adaptive" may be combined with "Number of colours" and will try to adapt to some average values, depending on the image colours. Experiment with it and see if you like the result better than the "6-6-6 levels" option. If you then choose the "Dither type" "None" the adaption will go on a best match basis. The other two will try to compensate for colour errors that the adaption introduces. I have experimented a lot with different settings of ditherings and colour of numbers but ended up mostly using the "6-6-6 levels".
Using the "6-6-6 levels" you most seldom have to edit the colour palette manually, maybe only look at it to see if every colour is essential, else change it to a nearby shade. But if you used some other option you really have to edit the colour palette. The colour palette is found by "Color" => "Edit Palette".
You simply choose your colour and then adjust the sliders to the value you wish. When using the "Adaptive" option you will find white not being white (255, 255, 255) and black not black, and lots of colours to edit. Many shades are really close to each other and may be joined to one shade. This tinkering is hardly fun, but if you really like to get the minimum file size it may be essential. Now you might understand why I recommend the "6-6-6 levels" option that practically takes that work away, and you get "web safe colours" into the bargain.
- Reduce the numbers of images, only use them that are essential to the web page
- Reduce the file size of the image by
- Finding the proper file format
- Screen captures are saved as GIF
- Photo quality images are saved as JPG or GIF, whichever has the lesser foot print
- GIF file format:
- Reduce the numbers of colours as far as possible with reasonable quality loss
- JPG file format:
- Find a good combination of "Quality" and "Smoothing"
- Save using "Optimize entropy encoding"
- Finding the proper file format
Adding images to your page
Adding images is as simple as to add a tag to the html code. The image tag looks like:
The result will look like this. That is, the default is to put the following text at the bottom line of the image and the image will be placed to your left.
Adding an extension to the tag - ALIGN=MIDDLE - will give this result. But interestingly the text will not continue were we would like it to continue, and hence this extension to the tag is seldom used. If this is not properly shown here your window is too wide, please resize it for a while.
And the extension ALIGN=TOP will not too surprisingly give this result. But interestingly the text will not continue were we would like it to continue, and hence this extension to the tag is seldom used. If this is not properly shown here your window is too wide, please resize it for a while.
This extended tag is more of what we use, but some values are exaggerated to illustrate the effect they have. The order of the extensions is not at all important.
One of the most important extensions are the WIDTH and HEIGHT that tell the browser the dimension of the image. With that information the browser may allocate space on the page for not yet downloaded images and thus show the text much faster. If not, the browser has to wait until the download is initiated and that much of the file is read that the image's header can tell the browser these values. You simply have to wait until that information is available.
How can you tell these values if you have no image editor open to see? Open only the image in Netscape and it is told in the browser's title bar.
BORDER is normally set to zero, or omitted since default is zero. But if you would like to use the image as a link to another resource, then a border is appropriate since else the link is almost invisible. I suggest a size of 2, but anything works.
The ALIGN extension may also be set to LEFT or RIGHT, and then the text flows at the free side of the image as we normally would like it to.
ALT gives you an opportunity to introduce an alternative text that is visible when the image did not load, the reader turned image downloading off or, in Netscape/2, when you move your mouse pointer over the image. Note that the text is enclosed by quote marks.
The two extensions HSPACE and VSPACE add extra pixels at the Horizontal and the Vertical directions of the image, both sides. Else the text will flow as close as possible to the image as is seen in the first three basic examples.
Whenever your site grows it is a good idea to store your images in a separate directory or folder. The principle to point to such a stock-room is as simple as to point to nearby web pages. Here come some examples.
<IMG SRC="howtohtml-color2.gif"> <IMG SRC="images/howtohtml-color2.gif"> <IMG SRC="../images/howtohtml-color2.gif"> <IMG SRC="../../images/howtohtml-color2.gif"> <IMG SRC="../images/articles/howtohtml-color2.gif"> <IMG SRC="http://www.os2ezine.com/images/howtohtml-color2.gif">
The topmost is the previous example and points to an image residing in the same directory as the page is (the working directory). Next line is first directing the browser to a directory in the working directory named "images" and then to the file in that directory. Then a line were the browser has to climb upwards one level closer to the root and there find the directory to dive into. Fourth line is simply to climb two levels closer to the root before diving into the directory of your choice. It is also possible to climb downwards as in the next line, first up one level and then into "images" only to dive into "articles" to find the image there. All these examples are relative paths.
The last example is a direct path or full path. It is simply the full URL to an image that do not have to reside on the same site as your web page is. You are free to point to any image you like to, but you are not free to use the image as if it is your own. Hence you have to tell the reader who the owner is, thus not violating any copyrights (that is you act as a private person, and the mileage of your country may vary).
Last month we learned how to add links to a page and this is as simple. This code will give us the image-link seen below:
You simply encompass the image tag, that is one tag but rather lengthy, with the normal <A HREF=" ... "> and </A> tags. The URL may be relative or a full URL, that is no problem.
I will not go into how to make image maps, how to add several links to one sole image. If you do not know what it is, think of a map of Europe and as you move the mouse pointer over different countries the links change dynamically. (Anyone around to write about that and about OS/2 image-map tools? Then write to Wright!)
This time we have only dealt with images, and still there is more to say about them. There are, as said, image maps, animated GIFs, resized images on the client side, transparency, interlaced images and much more. Please start with the tags we have discussed this month and then the best way to learn more is to use the "View" => "Page Source" to see how nice pages are set up.
Next month we will finish these three articles with a look on how to do the layout on web pages, "how do they do that with basic html code?" Stay tuned.