Re: Lossless JPEG
> Most of you might know that I am an advocate for JPG, at this time. Opinions be whatthey may, change over time. I think many of us know that JPG is compressed and is lossy.
Here are some thoughts along those lines
> "baseline JPEG is lossy because it is subject to roundoff errors in various calculations."quality of it. So, then the final dome masters are what you make as JPG's. These are the
> The compress and re-compress of a JPG is known as something that degrades the
frames that aren't going to get editing any further. Produce the show with high quality
standards and files then PRINT it to JPG's.
This is not necessarily the forum for a discussion on this but may I make a few comments.
First, it is true that baseline JPEG is always lossy.
However the ISO standard DOES describe a lossless JPEG, that is, mathematically pixel
perfect lossless, not just perceptual lossless.
There is also "JPEG-LS" which is a lossless JPEG standard being used increasingly.
So as far as I am aware, the maximum quality quality setting in the Mac version (perhaps
others) of PhotoShop is implemented as lossless JPEG.
As far as personal opinions/recommendations are concerned, I would suggest PNG as a far
> However the ISO standard DOES describe a lossless JPEG, that is,N.B. that this does not give the kind of compression ratios that JPEG
> mathematically pixel perfect lossless, not just perceptual lossless.
admirers so deeply desire. More like 2:1 than 10:1.
> There is also "JPEG-LS" which is a lossless JPEG standard beingI know that JPEG-LS requires a special plug-in for Photoshop, which
> used increasingly.
rather makes me doubt the following:
> So as far as I am aware, the maximum quality quality setting in theAdobe doesn't make this claim anywhere that I can find. It seems
> Mac version (perhaps others) of PhotoShop is implemented as
> lossless JPEG.
like they'd tell us if that were the case, doesn't it? The online
manual has this to say:
"JPEG (Joint Photographic Experts Group)
"Lossy compression; supported by JPEG, TIFF, PDF, and PostScript
language file formats. Recommended for continuous-tone images, such
as photographs. To specify image quality, choose an option from the
Quality menu, drag the Quality pop-up slider, or enter a value
between 0 and 13 in the Quality text box. For the best printed
results, choose maximum-quality compression. JPEG files can be
printed only on Level 2 (or later) PostScript printers and may not
separate into individual plates."
It would have been easy to mention that "13" is lossless, right?
I've looked on online forums, in their support pages, etc., but I see
nothing to support the claim that the highest setting is lossless.
I'd appreciate it if one of the many people making this claim would
provide supportive documentation. (Sorry, this is getting to be a
sore spot with me.)
My biggest concerns with JPEG are color and geometry. As I
understand it, most JPEG compression schemes start off with an
immediate conversion to YCbCr, which gives you even less color range
than 8-bit, I believe, and further steps in this process knock the
color space down even further: with new display systems, we need to
be moving toward increased color depth, not less. As far as geometry
goes, everybody knows JPEG has problems with rotations, resampling,
and recompression, and that's exactly what we're doing when we put
dome masters onto a multi-projector system: we rotate the image to
match the projector position, resample it to match the geometry, then
(typically) recompress it to get it to play back.
Can anyone think of a way to do a side-by-side JPEG versus
uncompressed test? Maybe just on two adjacent channels of a multi-
BTW, I'm not saying we should leave JPEG out of the draft standard,
but I think we need to describe the pluses and minuses as clearly as
A somewhat amusing anecdote: you can see JPEG artifacts rendered in
bronze (I think it's bronze) at the Rose Center! We have a
topographic moon globe based on Don Davis's exhaustive mapping of the
lunar surface. To create the globe, a greyscale bumpmap of Don's was
used to yield the topology of the surface. Don provided an
uncompressed image, but at some point, an exhibit fabricator or
*someone* put the image through a JPEG compression that left
significant artifacts. Because theses artifacts were then used to
create the texture of the bronze globe, you can run your fingers
across little rectangular bumps that correspond to the way the image
was broken up and compressed by the JPEG routine. Sad, but true.
> As far as personal opinions/recommendations are concerned, I wouldOut of curiosity, does PNG experience orientation problems (e.g.,
> suggest PNG as a far superior format.
like TIFF, which defines orientation in a header that not all
More importantly, however, I don't believe that PNG appears in the
current draft of the dome master standard; we should add it.
Ryan Wyatt, Science Visualizer
Rose Center for Earth & Space
American Museum of Natural History
79th Street & Central Park West
New York, NY 10024
> > So as far as I am aware, the maximum quality quality setting in theAnd I'm not claiming that, just what I've been told. If I want to save
> > Mac version (perhaps others) of PhotoShop is implemented as
> > lossless JPEG.
> Adobe doesn't make this claim anywhere that I can find. It seems
> like they'd tell us if that were the case, doesn't it? The online
> manual has this to say:
images in a lossless way I will do so using a format specifically
designed for that, not JPEG.
> My biggest concerns with JPEG are color and geometry.I haven't really contributed to the full dome standards business so am
> BTW, I'm not saying we should leave JPEG out of the draft standard,
> but I think we need to describe the pluses and minuses as clearly as
not sure where file formats come in. As a practical matter I assume
(hope) full dome members aren't using JPEG as the storage format for
movies. There's a big difference between using such a format for the
final playback format (we use PhotoJPEG for our QuickTime movie codec)
compared to the archive format of the original frames.
> > As far as personal opinions/recommendations are concerned, I wouldAhhh, the old problem of standards that aren't supported properly in
> > suggest PNG as a far superior format.
> Out of curiosity, does PNG experience orientation problems (e.g.,
> like TIFF, which defines orientation in a header that not all
> programs recognize)?
software. I can't vouch for PNG support across a wide range of
software, especially since I rarely use MSWindows. I do know TIFF
support under MSWindows can be poor, many applications use libraries
that don't even handle the big and small endian information in the
TIFF file header.
The relative merits of PNG
- A freely available reading/writing library supplied as source code.
- 9 bit alpha channels (not so amazing).
- Gamma correction support (important).
- Up to 48 bit colour and 16bit grey (16 bits per RGB, interestng for
large dynamic range in domes).
- Doesn't allow vendor specific tags (biggest headache with TIFF).
- Good lossless compression (often much better than TIFF).
- Patent free, by design.
Having said all that, I use gzipped TGA files for original frames and
playback using "high" quality PhotoJPEG.
P a u l B o u r k e
- Ryan Wyatt wrote:
> Can anyone think of a way to do a side-by-side JPEG versusHow about blink-comparison? A severe test would be to use a
> uncompressed test? Maybe just on two adjacent channels of a multi-
> pipe system...?
lossless path to transport, say, even-numbered dome master frames,
and a high-quality JPEG path to transport odd-numbered frames,
on a single scene; then split each per projector and project the results.
Differences would show up as shimmering.
I haven't tried the above, but regularly do blink-comparison of single
frames to test JPEG visual quality. The results do depend on the display
system, and they're certainly more likely to show up on scenes with extended
areas of very low but nonzero brightness; still I've almost never
managed to notice a difference between 98-100% JPEGs and lossless paths.
On the other hand, our displays take only 8-bit data.
I'd be interested in others' reports on tests like these...
Stuart Levy, slevy@... (& at new.math...)