#Image compression
21 messages in this thread
I have a few questions:
1.) When selecting .TGA as the output file type, there is a button to select
"compressed." Is this a "lossy" compression? (I realize the .JPG file type
is/can be lossy, depending on the compression setting.)
2.) When storing or transferring files, is there any loss of info/quality if
you zip/unzip them, or use some other compression method such as Microsoft
Backup?
I will be aquiring some (100's to 1,000s) high quality images from a
client at their site. I plan to bring my portable re-writeable 238MB optical
drive (and extra disks!) to aquire the images for transfer to video, as well as
to archive the images. Should my client (3DS user) save them as compressed or
uncompressed .TGA's?
Thanks in advance,
Paul D. Sanford [LEVEL 5]
Hi Paul,
<< 1.) When selecting .TGA as the output file type, there is a button to
select "compressed." Is this a "lossy" compression? (I realize the .JPG file
type is/can be lossy, depending on the compression setting.) >>
No it's not lossy.
<< 2.) When storing or transferring files, is there any loss of info/quality
if you zip/unzip them, or use some other compression method such as Microsoft
Backup? >>
PKZIP/PKUNZIP will not loose data.
Targa compression is lossless, and zipping files doesn't affect them.
Compressed targas are the optimal method.
– G
I almost always use TGA files, but the JPEG files are substantially smaller.
Is there any "loss" with the JPEG output if the qulaity slider is set for 100%?
Yup, even at 100%, there's some loss in smooth gradients.
– G
Thanks…it seemed too good to be true!
If you have the option, you may want to try compressed TIFF files.
The use a much more effective compression scheme (also lossles) than
compressed TGA files. Compressed TIFFs are nearly as compact as a
lossless compression scheme can get. PKzip will generally not
compress them any further.
The only drawback is that some programs will not read compressed TIFF
files. We use them with both 3DS and Adobe Photoshop with no
problem. If you are dealing with a lot of files, it is probably not
worth manually compressing them, but if you have DeBabelizer on the
mac or image alchemy on the dos side, you can use them to batch
convert. Beware, though, image alchemy will throw away any alpha
channel!
Thanks, Tim.
No. When a Targa file is compressed, all it happens is that, consecutive,
constant (same) colors are stuck together. That means, if the image has a large
area with a same color, that information can be saved in a "packet" that
contains the color and the repetition count. This works great for computer
generated images but doesn't do any good in real life images. In fact, the
resulting file might turn out larger than the original if there is nothing to
compress.
ZIP compression is uses a different method. It scans the file checking for
bytes that repeat more often than others and "pack" them. This works great for
text data as some characters repeat a lot more often than others. For images,
the results are somewhat arbitrary due to the nature of the information (pretty
much random). Regardless, you will be better off saving the files as
"uncompressed" Targas and "Zipping" them up. ZIP compression is mostly used for
real data (such as databases and spreadsheet). It couldn't be lossy otherwise
it would run havoc on these files.
JPEG, roughly speaking, uses a method of compressing down the number of colors
in an image. For real life video, this works fine as it's rare a situation of a
smooth gradient running from end to end. On computer images on the other hand,
that's pretty common. If the number of colors is reduced, you will begin to
notice "steps" as you move up or down the gradient.
Gus,
Just a note to clarify the discussion about compressed Targa files (I'm
sure you know this, but for the eavesdroppers). In the .TGA format, a
compressed file will always be smaller than the uncompressed file, because
repeated runs of pixels will be compressed (run-length-encoded with a count +
color), and individual occurences are flagged as "raw" pixels. Admittedly, a
programmer could ignore the "raw" concept and load up the file with an extra
byte for the count at every occurrence. I don't recommend it <g>.
Kevin Krell – Computer Support Associates
The Targa file is either compressed or non compressed. The non compressed
version has all the pixels sequentially (as in BGR/BGR/BGR…). The compressed
version has a "header" byte for each packet. If no packet got ever compressed
(of few of them) as it is the case with most live video, you have an extra byte
for each packet of raw bytes. On a 640×480 image, that's 2,400 bytes of "header
bytes". It ain't much but it _is_ larger than what an uncompressed file would
be. A packet can be up to 128 pixels and cannot overlap lines.
I was going to write a whole bunch of stuff, but I realized I
screwed up in my explanation (OK, so I'm wrong <g>. God, I hate
that!). Agreed on 2400 extra bytes. My experience with video
captured images though is that some compression and reduction in file
size does take place. In 10 years of selling and using Truevision
products, I have not encountered a file that compresses to a size
larger than the uncompressed version. Boy, I'd hate to be on the
wrong side of a programmer's debate with you <g>.
>> [Gus] Boy, I'd hate to be on the wrong side of a programmer's debate with
>> you <g>.
Yes, Kevin, it's not a pretty sight! :^) Whole room-fulls of
programmers have been known to cringe when Gus walks into the area!
He, he… no worries… The whole thing started with the guy asking
if he would lose data by compressing a Targa. I tried explaining how
the process works so he could figure it out by him self what he had
asked as opposed to giving a simple yes/no question with no basis for
thought. Had I just said yes or no, he would have to "memorize" the
answer with no clue to why that's so.
Gus, or ? –
In your experience, what setting is satisfactory (minimal artifacts)
for 320X240 avi files that have been converted to sequential targas,
enlarged to 512X4??, cranked up with BRTCON and image-processed with
an ipas like Pennello?
I know much of this is subjective, but from a programmer's
perspective, what is just shy of walking on the wild side?
Sorry but I'm not sure I understood. You have an AVI file that you
converted to a series of Targas going from 320×240 to 512×486 in the
process. That alone would make it below "great looking". I assume you
cranked up the contrast with BRTCON (I had totally forgotten about
that one). Later you ran the series of Targas through Pennelo?
Ok, if that's the case…
I guess if you use one of those radical paint process, the fact the
original has been enlarged won't matter much. A lot of image
information is lost any way (so to speak). It's more of a visual
thing than a rule of thumb. If it looks good, who cares what's the
"kosher" thing to do? <g>
Pennello applies its effects by creating "brushes" based on the
underlining image and alpha masks with all sorts of forms (tiny gray
scale bitmaps with different shapes and textures). These brushes
"collect" image data and "paint" with it. It's sort of like having a
[painter's] palette full of colors and picking some colors here and
there. You won't use every single color. That's the reason it doesn't
matter much the image has been enlarged 3.5 times.
Gus –
>> These brushes "collect" image data and "paint" with it.<<
No wonder it looks great, the more pixelated and posterized it is! (within
limits, of course).
BRTCON is a great utility, especially for those of us who use image
processing routines like Pennello. In my user's group meeting
yesterday I demo'd Pennello, and the Xaos rep who was there agreed
that cranking up the contrast is a good way to get "more punch per
pixel." I know sometimes you're not your own master, but have you
given any thought to doing a set of image processing ipas's that
allow you to preview the effect before committing? This would save
having to render out multiple frames, looking for the best setting.
Products like Pennello and the forthcoming Kai's Power Tools often
benefit from "pre-treatement" of the source image. It would be even
nicer ("pie in the sky here") if you could display changes
interactively, like the Mirage ipas, or a Photoshop plug-in.
Couldn't do without BRTCON, though. Absolutely indispensible for some
of the stuff I'm doing now. HBLUR conteracts some of the pixelation,
if needed, and THERMO is great if you want a whole different color
temperature.
Hi Robert,
<< BRTCON is a great utility, >>
where can forum members find this?
Jonas:
>> << BRTCON is a great utility, >>
>> where can forum members find this?
Forum members, as well as the rest of the world, <g> can find BRTCON
(a brightness and contrast adjustor) on our "Action IPAS Utilities
Library".
This disk also includes HBLUR.IXP, (a blur which works with fields),
THERMO.IXP, (adjusts the color temperature of your images),
DEFIELD.IXP (removes fields), WHATTGA.EXE and WHATJPG.EXE (to verify
all your Targa and JPEG files respectively for consistency before
taking them out to tape) and LEGAL.IXP and JPEG.IXP (to legalize
colors and JPEG compress images for R2). All 8 programs available
for $125 at your local 3DS dealer.
Jonas –
This is one of the IPASs written by Gus Grubba for the Pyros Partnership. We
should probably ask Greg who interested parties should call. . . (Greg?)
bob
I will take a look at it and see how much I can do as far as updating
those routines. In order to have it doing real time previews, it has
to run in true color mode, thus, all those arguments we were having
about the ability to switch modes on the fly. Funny you mention KPT
does it. That's the main reason I haven't updated these routines. I
just can't find the time as I am writing KPT.