DTP


 
Lively discussions on the graphic arts and publishing — in print or on the web


Go Back   Desktop Publishing Forum > General Discussions > Print Design

Reply
 
Thread Tools Display Modes
Old 01-13-2007, 06:08 PM   #21
ktinkel
Founding Sysop
 
ktinkel's Avatar
 
Join Date: Oct 2004
Location: In Connecticut, on the Housatonic River near its mouth at Long Island Sound.
Posts: 11,189
Default

Quote:
Originally Posted by Franca View Post
Ack, just followed the link and my eyes crossed immediately. I decided I just don't care that much about how lossless compression is achieved, LOL!
That was pretty much my response!

It is enough to know that it is safe. If sometimes bulky.

   
__________________
[SIZE=2][COLOR=LemonChiffon]::[/COLOR][/SIZE]
[SIGPIC][/SIGPIC]
ktinkel is offline   Reply With Quote
Old 01-14-2007, 02:35 AM   #22
iamback
Member
 
iamback's Avatar
 
Join Date: Oct 2005
Location: Amsterdam, NL
Posts: 4,894
Default

Quote:
Originally Posted by ktinkel View Post
Not sure I quite understand it all, but it is some sort of encoding scheme. It is generally limited to about 50% size reduction.

This article on Lossless Data Compression may explain it so you can understand it. My mind goes blank when I try to read it.
Let me give a very simple example how lossless compression is achieved.

Say you have a string like the following:
Code:
AAAABBBBBBCDDDDCDDDDCDDDD
That string is 22 bytes long.

If you look at it, you can spot several repetitions in there, and it's the repetitions that allow it to be compressed. In a simple compression scheme, I could write it as:
Code:
4A6B1C4D1C4D1C4D
That's only 16 bytes, or just about 73% of the original. It also illustrates that the shorter your repeated chunks are, and the more occurrences of only one or two bytes, the worse the compression performs: more of the same compresses better.

Of course, I've only used a single byte for the repetition counter (but a single byte can express a number 0 - 255); for longer repetitions I could use (always) two bytes (allowing more than 65000 repetitions), or just take a full chunk of 255 and write "255A" and then move on to the next chunk. Whether always using two bytes or using smaller chunks of up to 255 bytes long results in better compression actually depend on your original.

In general, this type of approach to lossless compression (meaning all the original bytes can be completely reproduced from the compressed version) is called "Run length encoding" (RLE); the Windows OS/2 bitmap format (BMP), which many people think cannot be compressed, actually supports this kind of compression. Of course, for bitmapped images, a "pixel" is defined in three bytes, so what such a scheme looks for there is not repeated bytes, but repeated pixels; the general algorithm is the same though.

GIF compression is very similar, and you can actually judge the "compressability" in GIF of an image by looking for pixels of identical color in rows. If you have long rows of nearly identical color, but with only a few slightly different from the surrounding ones, you can change the single pixels to be the same as their surrounding ones to achieve a much smaller GIF image.

In such compression schemes, things like "16A" should be read as an instruction that says "repeat the following byte (A) sixteen times". Of course the GIF compression scheme is a bit more sophisticated than that, making it generally better at compression than the simple RLE encoding in BMP format. But both still only work on a row-by-row basis; each new row of pixels starts the algorithm anew. PNG adds a new twist (many, in fact, but one that is important for compressability), by being able to look "across" rows as well. It can do something like this:
original:
Code:
AAAAAAAAAABBBBBCCCBBBBB
AAAAAAAABBBBBBBCCBBBBBB
compressed:
Code:
10A5B3C5B
^82B^52C1B^5
(I'm not saying this is literally how it is stored, just illustrating the principle!) You could read the instructions as:
  1. 10*A, 5*B, 2*C, 5*B
  2. 8 bytes from above, 2*B, 5 bytes from above, 2*C, 1*B, 5 bytes from above
It is this principle of "working across rows" that makes PNG compression much better at compressing line art with large areas of the same color than GIF compression. And as with GIF you can improve compressed size by making single slightly-different pixels exactly the same as their neighbors in a row, to improve PNG compression you can also apply this vertically.

There are many other types of compression than what I illustrated above for compression schemes based on "run length". Another important type of compression is to use a "dictionary" approach. The original is "scanned" and each time a string is found that has occurred before, the string is added to a "dictionary", and for each "word" in the dictionary the position of each occurrence is noted. In my very first sample string for instance, a dictionary approach would notice that "CDDDD" actually occurs repeatedly, and store that string in the dictionary. Such approaches can of course also be combined with run-length encoding (for instance by storing "1C4D" as a dictionary word, instead of "CDDDD").

I've only explained "principles" here, not actual encoding schemes, but I hope that gives you some idea at least of how lossless compression works; and the compressed file contains instructions to completely reproduce the original. (It glosses over the fact that GIF can use only 256 colors; but if your original has no more colors, GIF compression is lossless; reducing to a 256-color palette (or smaller) is not itself part of GIF compression, merely a condition for it to be possible.)

And this little explanation may actually give you the tools to make crisper and smaller GIF or PNG images of line art, just by knowing these principles; and how to judge (without trial and error) whether PNG might achieve better compression than GIF. If file size is important, half an hour or so spent on changing single pixels and/or equalizing areas of color that should be monochrome (but often aren't on close inspection) can make an enormous difference to file size.

   
__________________
Marjolein Katsma
Look through my eyes on Cultural Surfaces (soon!), My ArtFlakes shop and Flickr.
Occasionally I am also connecting online dots... and sometimes you can follow me on Marjolein's Travel Blog
iamback is offline   Reply With Quote
Old 01-14-2007, 07:19 AM   #23
ktinkel
Founding Sysop
 
ktinkel's Avatar
 
Join Date: Oct 2004
Location: In Connecticut, on the Housatonic River near its mouth at Long Island Sound.
Posts: 11,189
Default

Thanks for all that. I thought it was a form of run-length encoding. It was all the rest of that paper I linked to that made my eyes glaze over!

Anyway, the point of this discussion is to avoid lossy compression schemes in original art, then make your GIF or PNG or JPG for printing. And when you get a JPG and need to make modifications, to convert it as soon as possible (often, not soon enough, I have found) to TIF or PSD.

   
__________________
[SIZE=2][COLOR=LemonChiffon]::[/COLOR][/SIZE]
[SIGPIC][/SIGPIC]
ktinkel is offline   Reply With Quote
Old 01-14-2007, 09:22 AM   #24
iamback
Member
 
iamback's Avatar
 
Join Date: Oct 2005
Location: Amsterdam, NL
Posts: 4,894
Default

Quote:
Originally Posted by ktinkel View Post
Anyway, the point of this discussion is to avoid lossy compression schemes in original art, then make your GIF or PNG or JPG for printing. And when you get a JPG and need to make modifications, to convert it as soon as possible (often, not soon enough, I have found) to TIF or PSD.
I certainly agree you should start by first storing the original in a non-lossy format; TIF and PSD are two options, PSPIMAGE (Paint Shop Pro's internal format like PSD is Photoshp's internal format) is another one.

However, if your final format is going to be a GIF or PNG to be published on a website, my little explanation should come in handy, too.

   
__________________
Marjolein Katsma
Look through my eyes on Cultural Surfaces (soon!), My ArtFlakes shop and Flickr.
Occasionally I am also connecting online dots... and sometimes you can follow me on Marjolein's Travel Blog
iamback is offline   Reply With Quote
Old 01-14-2007, 12:58 PM   #25
Molly/CA
Member
 
Molly/CA's Avatar
 
Join Date: Jan 2005
Location: Central California
Posts: 235
Default

Oh, no, you're not going to get me to try to read, much less understand, anything that throws around phrases like "asymptotic optimality" and says it's the easier one.

But oh, wow. As some of you know I'm always in need of jargon to throw at a certain Press, and what a supply.
Molly/CA is offline   Reply With Quote
Old 01-14-2007, 01:24 PM   #26
bmann
Member
 
Join Date: May 2006
Location: Minneapolis, Minnesota
Posts: 192
Default

Quote:
Originally Posted by Molly/CA View Post
Oh, no, you're not going to get me to try to read, much less understand, anything that throws around phrases like "asymptotic optimality" and says it's the easier one.

But oh, wow. As some of you know I'm always in need of jargon to throw at a certain Press, and what a supply.
This is where my Dictionary Search plug-in for FireFox comes in handy. Kind of sad when I look up a word and then have to look up words that are used in the definition of that word.
bmann is offline   Reply With Quote
Old 01-14-2007, 02:35 PM   #27
ktinkel
Founding Sysop
 
ktinkel's Avatar
 
Join Date: Oct 2004
Location: In Connecticut, on the Housatonic River near its mouth at Long Island Sound.
Posts: 11,189
Default

Quote:
Originally Posted by Molly/CA View Post
But oh, wow. As some of you know I'm always in need of jargon to throw at a certain Press, and what a supply.
So glad you can make some use of it!

   
__________________
[SIZE=2][COLOR=LemonChiffon]::[/COLOR][/SIZE]
[SIGPIC][/SIGPIC]
ktinkel is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
what to consider in Magazine Design Maracas Print Design 1 06-13-2006 06:46 AM
Lay Out Programs Marilynx Print Design 16 03-24-2006 08:50 AM
(almost) newest design dacoyle Web Design 30 01-06-2006 11:43 AM
Print vs Web Design vavroom Print Design 2 09-30-2005 06:40 AM
Logo design PeterArnel Print Design 2 09-29-2005 02:45 PM


All times are GMT -8. The time now is 07:27 PM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Contents copyright 2004–2014 Desktop Publishing Forum and its members.