Re: FW: TIF or GIF?

[Arlen -dot- P -dot- Walker -at- jci -dot- com]

Truth is, I rarely if ever use TIFF, for several reasons. Biggest one is a
work across several platforms, and TIFF is *not* a cross-platform format.
It's dependent upon the byte order of the machines it's running on.
Compress an image on a machine whose CPU uses the low byte for the MSB, and
you will not be able to decompress it on one which uses the high byte as
the MSB, without the premeditated help of the application developer.

Several people have remarked that TIFF is lossless; you should probably be
aware that this is no longer guaranteed, as TIFF now includes the ability
to use the JPEG algorithms to store and compress images. It *can* be
lossless, but doesn't have to be.

Define some terms:

Lossy: removes information from the image while processing it.

Lossless: image stored in this format is identical in every way to image
before processing.

GIF is lossless. JPEG can be either.

GIF is lossless, because you have to first turn the image into a 8-bitcolor
image before it can be turned into a GIF. The image after being processed
by the GIF algorithm is identical in every way to the image before
processing by the GIF algorithm, because the GIF algorithm itself does
*not* turn a 24-bit color image into an 8-bit image. Something else has to
do that first.

GIF has a dynamite compression algorithm, so on 8-bit images it outperforms
TIFF (which, contrary to some information posted, is quite capable of
handling 8-bit images).

I wonder how many people realize EPS often uses JPEG compression
techniques? (Yes, JPEG is moving in on everything, likely because it's such
a good algorithm.)

JPEG is probably the most misunderstood algorithm in the bunch. It has a
variable setting for its compression algorithm. At the least compression
setting, it is completely lossless. At the heaviest compression setting,
the results are practically unusable.

A JPEG image is reconstructed in memory every time it's read into the
system. The lost color information is, of course, no longer there. But to
act as if therefore the next save will throw away or otherwise modify the
pixels in their place in some sort of a bizarre "memory effect" is plain
wrong. Now, an image *can* degrade once again, but only if, in the newly
recreated image, colors now find themselves placed beside similar colors.
Good implementations of the JPEG algorithms will look for this opportunity
the first time around, bad ones won't. So test it, but you may find that
you can save and resave in JPEG with no further loss of detail. (Note:
after modifying a file, you have created a different file, so the same
compression options that worked on the first one will not necessarily work
as well on the second.)

Lots of folks hate JPEG on a kneejerk, because they've heard it's lossy.
Don't fall for that. If you can see the difference between the original and
the JPEG copy, your compression settings were too aggressive. You only have
1 (or 3, or 6) settings to choose from? You're using a graphics program
with an incompetent implementation of JPEG. Go find a better one. Really
good ones use a hundred settings; 20 is probably sufficient.

A tip for working in JPEG: NEVER ACCEPT DEFAULTS! There, did I say that
loud enough? Tweak the settings to find what works best for each photo (or
get yourself a *real* graphics program which will allow you to preview the
effect of the JPEG setting before saving it -- both ImageReady and
Photoshop do this, and it's indispensible for serious web work). Odds are
you'll find a setting that works very well for your image without too much
extra work, and the savings will mount over time, and you'll get better at
it as you go.

Another tip for working with graphics of every format: Always save a copy
in the highest quality possible that makes sense (don't save a 300dpi scan
at 1200dpi, you don't gain anything). You never know when that cute 72dpi
web graphic will be asked to serve on a 3600dpi print page. Once you've
pulled the pixels out, they never, ever want to return.


Have fun,
Arlen
Chief Managing Director In Charge, Department of Redundancy Department
DNRC 224

Arlen -dot- P -dot- Walker -at- JCI -dot- Com
----------------------------------------------
In God we trust; all others must provide data.
----------------------------------------------
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17)
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by DigiPub Solutions Corp, producers of PDF 2001 
Conference East, June 4-5, Baltimore/Washington D.C. area.
http://www.pdfconference.com or toll-free 877/278-2131. 

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.