NavList:

   

Reply

There have been some very large attachments in the past couple of weeks. 
Attachments are clearly useful to the majority of NavList members (don't get 
me wrong, I ENCOURAGE them), but it seems to me that a technically savvy 
group like this ought to be able to manage "slightly" better efficiency. I'm 
going to attach two examples of images that I re-sized and saved in a 
different format reducing their size, compared to the original attachments, 
by a factor of TWENTY or better. 

The first was a photograph of a sign. It's sort of the inverse of the old 
adage "a picture is worth a thousand words". If this sign had been 
transcribed as plain text (typed into a message), it would amount to less 
than 500 bytes. Even keeping it as a photograph, it was not hard to reduce it 
dramatically in size and still maintain readability. This reduced image file 
"mendoza-sign.gif" is less than 70kB. That's a lot more than the plain text 
which it contains, but it's much smaller than the original posted to NavList 
which was over 1,500kB. That's 95% wasted bandwidth.

The second image appears to be a scan of an old printed half-tone. This, too, 
could be easily re-sized and saved in a different format. The reduced file 
"worsleysmall.jpg" is less than 20kB while the original was 2,942kB. That's 
over 99% wasted bandwidth.

Let me just recommend to any of you who work with photos on your computers 
that you can easily save huge amounts of space and similarly save 
considerable upload and download time by doing a couple of simple things. You 
will need to find a nice photo-editing software package. It doesn't have to 
be complicated or sophisticated; you don't need the latest version of 
PhotoShop. Myself, I use a version of Paint Shop Pro that's over ten years 
old.
Step ONE) Check the file size. Is it over 500kB? If so, you should probably at 
least consider re-sizing before sending. 
Step TWO) Is the image in a "wrapper"? You shouldn't send image files as PDFs, 
for example, since this merely wraps the images in a thick layer of bytes 
with no added benefit. So if it's in a wrapper, copy and paste into your 
image editing software.
Step THREE) In preparation for the next step, increase the color depth to the 
maximum available (millions of colors or 24-bit). [note: digital images can 
be considered to have three dimensions, width in pixels, height in pixels, 
and color depth which determines the number of bytes per pixel in the image]
Step FOUR) Re-size in steps until the image is good enough for screen viewing 
but not significatly diminished in quality (typically your image should be 
smaller than 1000 pixels wide and in many case you can get by with smaller 
than 500 pixels wide without sacrificing apparent quality). Find the minimum 
size that preserves the CONTENT of your image.
Step FIVE) Trim off anything un-necessary. This one's fairly obvious. If 
there's a blurry background behind some foreground object that is the main 
content of your image, get rid of the background.
Step SIX) Ask yourself, is it mostly a diagram? An image with sharp edges? If 
so, save as a 256-color GIF image (or PNG equivalent, if you prefer). Or is 
it a photograph, like a portrait or a real landscape? If so, save it as a 
JPEG image (you can adjust the settings on jpegs, trading image quality for 
increased compression but this is not necessary --the default is usually the 
right choice). Be sure to save under a different name so that you can revert 
to the original if the results are not satisfactory. Don't send TIFFs.
Step SEVEN) Check the file size again. Sometimes, once in a great while, all 
of this is wasted effort and the original is nearly the same size. But you 
will frequently see the sort of dramatic reductions in size as above: files 
20x-50x smaller than the original with no loss of quality for screen viewing.

I would emphasize that these steps on any image take no more than two or three 
minutes which may well be less than the time it takes to upload the original 
full-sized image. This is not hard work, and it ain't rocket science. :-)

And finally, if you can't figure out any of this, then consider posting from 
fer3.com/arc. Upload large files there and select them to be "linked" rather 
than "attached". Then you can upload huge files if you must without causing 
headaches for those NavList members who have slow email connections. A 
half-dozen NavList members have done this with great success.

Someone is bound to ask why we should worry about bandwidth when there's so 
much traffic going into online video and other services that consume hundreds 
of megabytes in a single visit. Primarily, it's because "email is different". 
Apart from the issue of other NavList members who have slow email connections 
(and you may well say, tough for them), there's the issue of blacklisting. 
Mailing lists like NavList deliver a separate copy of each and every 
attachment. About half of NavList members receive messages by email (the 
others participate via the forum/archive at fer3.com/arc or via the web 
interface at google). That means that every megabyte of attachment spawns a 
hundred megabytes of traffic which can get us blacklisted or labeled as 
spammers. We don't want that. Oh, and for the techies out there, it's worth 
pointing out that email has to be fooled into sending binary files. It's 
text-based. So just like the old Usenet days (anyone remember UUencode?), any 
image file sent through NavList as an attachment is increased in size by 
being converted to "Base64" text. It's unavoidable waste, an extra 37%, but 
that's small potatoes compared to the issues above.

-FER

--~--~---------~--~----~------------~-------~--~----~
Navigation List archive: www.fer3.com/arc
To post, email NavList@fer3.com
To , email NavList-@fer3.com
-~----------~----~----~----~------~----~------~--~---

File:

File:

   

Reply