What program is best at JPEG compression?

On Jul 30, 11:23 am, "HEMI-Powered" wrote:
Martin Brown added these comments in the current discussion du
jour ...

On Jul 28, 12:02 am, Bill Tuthill wrote:
In rec.photo.digital Martin Brown
wrote:

PSP 8 has a demonstrably very broken chroma subsampling
implementation in its JPEG codec. It is a testament to just
how robust JPEG is that more people have not noticed this
flaw.

Thanks for your excellent explanation of the issue.

The simplest line art test to show its failings on chroma
encoding is to encode a pure red and pure blue 16x16
pokerdot test pattern in each of the possible phases save
as JPEG default 2x2 subsampled at maximum quality and then
reload it. Half of the newly decoded image not even a
vaguely satisfactory approximation to the original (with
gross residual colour errors - completely the wrong colour
bright red instead of purple). 2x1 subsampling gets an even
more incorrect result with alternating blue and red stripes
in addition.

Is 2x1 same as 4:2:2? I thought the ImageMagick
-sampling_factor option only accepted 1x1 and 2x2, but it
does accept 2x1 and produces what looks (to jpegdump) similar
to 4:2:2 chroma subsampling from digital cameras.

2x1 is typically the encoding used by digicams. 1x2 sampling
was unknown until the lossless JPEG transcoder allowed images
to be rotated in the coefficient space. Some decoders don't
decode 1x2 chroma especially well.

I can neither confirm nor deny your assertation here, none of my
digitals tell me what they use. I generally do NOT use 2x2

If it is the Canon Rebel EOS 350D then the images are 2x1 chroma
subsampled. It isn't an assertion either it is a statement of fact
that anyone with appropriate tools can verify for themselves.

Utilities like JPEGDUMP or DUMPJPEG and their ilk will display the
header info in human readable form (even if most of it may look like
gobbledegook). There is something slightly odd about the example files
from this camera at DPReview - they seem to crash at least one old
JPEG header analysis program with a curious message of finding two SOI
markers. The IJG version works OK though and will display the
subsampling details.

It appears to contain nested JPEG thumbnails 160x120 and 432x288 as
well as the main 3456x2304 stream. I haven't investigated why this
distresses the older program. And it doesn't affect normal JPEG
decoding.

Regards,
Martin Brown

In rec.photo.digital Martin Brown wrote:

Utilities like JPEGDUMP or DUMPJPEG and their ilk will display the
header info in human readable form (even if most of it may look like
gobbledegook).

Martin, while I've got you reading this thread, please let me ask
a somewhat related question.

Photoshop, and to a lesser extent certain digital camera, create JPEG
where qtable0 and qtable1 have different "quality factor" ratings.

Whereas the excellent IJG libraries used by GIMP, ImageMagick, Irfanview
(etc.) seldom or never do this. Qtable0 and qtable1 always seem to have
the same "approximate quality factor", as jpegdump says.

Is it possible for the IJG libraries to create JPEG with different
quality factors in qtable0 and qtable1? Is it just that applications
written on top of IJG do not make use of this knob?

HEMI-Powered wrote:

John Turco added these comments in the current discussion du
jour ...

HEMI-Powered wrote:

heavily edited, for brevity

I keep in mind that the "P" in JPEG means "Photographer".

heavily edited

Hello, Jerry:

JPEG stands for "Joint Photographic Experts Group" -- just
being a stickler, dog. ;-)


same thing, I said it's been a long time, but P for Photographer is
close enough for P = Photographic to make the point I was making,
OK by you? thank you.


Hello, Jerry:

What's the matter, don't you appreciate my subtle brand of humor? g
Seriously, the JPEG committee consists of mathmeticians, as wells as,
photographers.


Cordially,
John Turco

On Jul 31, 1:51 am, Bill Tuthill wrote:
In rec.photo.digital Martin Brown wrote:

Utilities like JPEGDUMP or DUMPJPEG and their ilk will display the
header info in human readable form (even if most of it may look like
gobbledegook).

Martin, while I've got you reading this thread, please let me ask
a somewhat related question.

Photoshop, and to a lesser extent certain digital camera, create JPEG
where qtable0 and qtable1 have different "quality factor" ratings.

Yes. Various makers have decided that they can do slightly better on
quality/size trade off than by scaling the original canonical JPEG
standard "example" quantisation tables. For my money the Qtables
should be symmetric, and the standard should have specified that a
JPEG stream starts off with the default Huffman tables and Qtables set
to the standard defaults perhaps with an optional 0..100 scaling tag.

It would save a useful chunk of space off the front of every small
JPEG icon and thumbnail on the web had the "example" settings for
these parameters in the standard been adopted as defaults.

The standard writers did not anticipate that everyone would adopt
their example tables verbatim.

Whereas the excellent IJG libraries used by GIMP, ImageMagick, Irfanview
(etc.) seldom or never do this. Qtable0 and qtable1 always seem to have
the same "approximate quality factor", as jpegdump says.

Is it possible for the IJG libraries to create JPEG with different
quality factors in qtable0 and qtable1? Is it just that applications
written on top of IJG do not make use of this knob?

The IJG library provides two interfaces for setting quantisation
tables -

The quality factor 1..100 which is used to rescale the both the
standard default qtables according to taste which is what most (all?)
normal applications use. Some have maximum quality 0 or 1 and some
have it at 100. It scales both the luminance and chroma tables by the
same factor (which is usually the right thing to do).

The second wizard interface allows you to set the quantisation tables
explicitly to any set of values you like. It should come with a health
warning that bad choices will result in very poor results.

DOS command line program CJPEG which comes with the main distribution
of IJG with wizard switches -qtables or -qslots will let you play
around directly with unusual quantisation tables.

I reckon it was overkill to have square quantisation tables with 64
components. Imposing diagonal symmetry and storing only the 36 upper
diagonal quantisation values would be a very reasonable thing to do.
ISTR Adobe qtables are all symmetric (or at least all the ones I have
ever seen are).

Regards,
Martin Brown

Martin Brown added these comments in the current discussion du
jour ...

If it is the Canon Rebel EOS 350D then the images are 2x1
chroma subsampled. It isn't an assertion either it is a
statement of fact that anyone with appropriate tools can
verify for themselves.

That is what mine is. I understand that 350D is the name outside
the U.S. and it is Rebel XT here. Is that right? I said
originally that I didn't know the Chroma subsampling my Rebel
uses, and up to this very minute, I didn't. I also said that I
have never seen any real damage to images coming out of my
camera, but I HAVE seen damage when I use 2x2 with PSP 9, so
perhaps it is PSP that is misprogrammed, not the Rebel and not
the general standard.

Utilities like JPEGDUMP or DUMPJPEG and their ilk will display
the header info in human readable form (even if most of it may
look like gobbledegook). There is something slightly odd about
the example files from this camera at DPReview - they seem to
crash at least one old JPEG header analysis program with a
curious message of finding two SOI markers. The IJG version
works OK though and will display the subsampling details.

It appears to contain nested JPEG thumbnails 160x120 and
432x288 as well as the main 3456x2304 stream. I haven't
investigated why this distresses the older program. And it
doesn't affect normal JPEG decoding.

Regards,
Martin Brown





--
HP, aka Jerry

John Turco added these comments in the current discussion du
jour ...

same thing, I said it's been a long time, but P for
Photographer is close enough for P = Photographic to make the
point I was making, OK by you? thank you.

Hello, Jerry:

What's the matter, don't you appreciate my subtle brand of
humor? g Seriously, the JPEG committee consists of
mathmeticians, as wells as, photographers.


Cordially,
John Turco

Yes, I do just fine with humor, John, and yes, I knew there were
mathemiticians in the committee/consortia. Had there not been
mathemeticians/computer software developers, it would have been a
very nice spec but not one that was implementatble. So, please
excuse me for 1) not immediately catching your humor and 2) blowing
the correct word in the first place. I think everyone in this
thread has done a fine job in explaining themselves and in not
getting on anybody else's nerves. I can't tell if I annoyed anybody
or not, but if I did, I certainly apologize and will endeaver to do
better next time, e.g., not being so stubborn and rigid, two traits
I know my personality has in spades, so once in a while, somebody
has to tell me to lighten up.

--
HP, aka Jerry

On Jul 31, 12:56 pm, "HEMI-Powered" wrote:
Martin Brown added these comments in the current discussion du
jour ...

If it is the Canon Rebel EOS 350D then the images are 2x1
chroma subsampled. It isn't an assertion either it is a
statement of fact that anyone with appropriate tools can
verify for themselves.

That is what mine is. I understand that 350D is the name outside
the U.S. and it is Rebel XT here. Is that right?

I think that is the case, but maybe there are some other differences.
US domestic "pet" names for cameras are something of a mystery to me.
I can't see what is wrong with calling it Canon 350D.

Regards,
Martin Brown

In rec.photo.digital Martin Brown wrote:
I reckon it was overkill to have square quantisation tables with 64
components. Imposing diagonal symmetry and storing only the 36 upper
diagonal quantisation values would be a very reasonable thing to do.
ISTR Adobe qtables are all symmetric (or at least all the ones I have
ever seen are).

Au contraire, Photoshop writes symmetric quantisation tables
only at the very highest settings, maybe 11 and 12? I could check
if it's important. However I see a lot of Photoshop JPEG images
with qtable0 at 88 and qtable1 at 91 with 1x1 chroma.

When rewriting these, I have not studied whether to compromise and
save at 89-90, or take the higher number 91. GIMP does not offer
asymmetric saveAs. Best to use Photoshop itself, probably Q = 10.

Thanks for all your answers.

On Jul 31, 6:26 pm, Bill Tuthill wrote:
In rec.photo.digital Martin Brown wrote:

I reckon it was overkill to have square quantisation tables with 64
components. Imposing diagonal symmetry and storing only the 36 upper
diagonal quantisation values would be a very reasonable thing to do.
ISTR Adobe qtables are all symmetric (or at least all the ones I have
ever seen are).

Au contraire, Photoshop writes symmetric quantisation tables
only at the very highest settings, maybe 11 and 12? I could check

I was referring to the internal 64 numbers in the Adobe quantisation
matrix which have a diagonal symmetry.
It is a 8x8 square matrix and q[i,j] = q[j,i]

In essence it seems reasonable that the quantisation of an image
should not depend on whether you photograph it in landscape or
portrait modes (or at any other oblique angle for that matter). You
can make a reaonable case on symmetry grounds from the 3,4,5 triangle
that q[0,5] = q[5,0] = q[3,4] = q[4,3]

The scaling and matrices used for luminence and chroma are quite
different. Empirically it works best that way.

if it's important. However I see a lot of PhotoshopJPEGimages
with qtable0 at 88 and qtable1 at 91 with 1x1 chroma.

That is because Photoshop doesn't use scaled versions of the standard
tables.

When rewriting these, I have not studied whether to compromise and
save at 89-90, or take the higher number 91. GIMP does not offer
asymmetric saveAs. Bestto use Photoshop itself, probably Q = 10.

I would suggest choosing for the closest match on the intensity
channel but it will still introduce a significant requantisation hit.
Once it is a Photoshop image, best to resave a JPEG at the same
original level if you must.

If you want to send me a set of tiny 16x16 images compressed at each
of the 12 different levels of the current Photoshop release I will
compute what their approximate IJG equivalent is. The public utility
DUMPJPEG doesn't give very accurate answers on coarse quantised
heavily compressed images.

Regards,
Martin Brown
(the strange reply-to address is valid provided you don't alter it at
all)

In rec.photo.digital Martin Brown wrote:

If you want to send me a set of tiny 16x16 images compressed at each
of the 12 different levels of the current Photoshop release I will
compute what their approximate IJG equivalent is. The public utility
DUMPJPEG doesn't give very accurate answers on coarse quantised
heavily compressed images.

Deal. Thanks very much. Do you want the red/blue squares 16x16,
or something else?

Gordon Richardson's article http://photo.net/learn/jpeg/
contains this similar information, but note 10 is missing:
QUOTE
Photoshop Jpeg's do not use the IJG tables, so their
equivalent quality can only be estimated:

48X32_12: Approximate quality 98 horizontal sampling 1
48X32_11: Approximate quality 94 horizontal sampling 1
48X32_09: Approximate quality 91 horizontal sampling 1
48X32_08: Approximate quality 88 horizontal sampling 1
48X32_07: Approximate quality 83 horizontal sampling 1
48X32_06: Approximate quality 86 horizontal sampling 2
48X32_05: Approximate quality 82 horizontal sampling 2
48X32_04: Approximate quality 77 horizontal sampling 2
48X32_03: Approximate quality 73 horizontal sampling 2
48X32_02: Approximate quality 62 horizontal sampling 2
48X32_01: Approximate quality 52 horizontal sampling 2
/QUOTE