What program is best at JPEG compression?

Fed-Up-With-Corel added these comments in the current discussion
du jour ...

Correct. If you do a global change then yes, the whole image
would have to be ran through the JPEG routine again. The
upside is that when using "Save" (not "Save-As") the same
compression level that was used on the original will still
be applied to the result without you having to guess or do a
thing.

Isn't using Save vs. Save As inherently dangerous? If anything
at all goes bump in the night during the (re)Save, your
original is lost forever. I would imagine that it would be a
damn good idea to copy your file(s) to a temp folder just in
case.

Correct, but I'm not talking about over-writing any original
file intentionally. I'm talking about not degrading any
unedited data in my final COPY-OF result, no matter where I
save it or what filename I give it. Note too that the only
warning about using "Save-As" with PL32 is that if you choose
a compression setting that gives you a smaller file-size than
the original, only THEN will it globally recompress the
unedited data in your original image. So even "Save-As" has
the lossless editing capability, as long as you don't manually
choose a higher compression level than the original image.
This ensures you can also save a lossless copy under new
filenames at any time. Just don't fiddle with the compression
level slider trying to get a smaller file.

Thanks for the explanation, but, sorry, I still don't understand.
I thought the idea was to be able to do a specified small re-edit
and re-save the JPEG with minimal/zero damage. If you used Save
instead of Save as, doesn't that imply you're overwriting the
original that you wanted to change?

I've not tried these programs and probably won't for reasons I've
stated. I'm only "involved" here out of curiosity and the design
to learn new things, but people must be experiencing FAR greater
amounts of re-edit/re-save damage than I see in order to get them
to accept specialized editors that have severe limitations.

WRT to not changing the compression, AFAIK, in a normal re-save,
even at the same compression setting, a totally new block
sampling is done during the re-compresssion phase. So, again, I'm
confused here.

BTW: Simple crops are also immune to recompression data loss
when re-saving as JPG in PL32. If you haven't changed the data
in the cropped area before re-saving it, then there is zero
data loss in your saved portion. It also isn't limited to
8-pixel boundaries as so many other editors are forced to use.

That's the danger I was talking about, but instead of
inadvertantly overwriting the old file, you'd be doing it
intentionally. Seems naive on my part, maybe, but that seems
like an invitation for a visit from Murphy.

Again, you followed-up on a misunderstanding. I refer to the
extremely rare times I might mistakenly over-write an
original, and it has happened. With a wave of panic. It's nice
to know I can recover from it. Not so with PSP. In order to
retain the original data by backing up in "undo"s you would
have to re-save the unedited version as a JPG with a
compression value of 1, and a chroma subsampling of 1x1x1.
Resulting in a huge file compared to the original which was
already compressed. Choosing any compression more than that
would introduce new JPG artifacts and loss of original data.
Keeping in mind too that even at this lowest possible minimum
compression setting as a JPG file in PSP it's *still* going to
change some of your original image data. You may not ever be
able to visually detect it, but it *will* change it. To be
certain that you wouldn't change the data after backing out of
your edits you'd have to save it in a lossless filetype (BMP,
TIF, PNG, etc.). Your original JPG file and its native
compression scheme now gone forever.

I thought I'd understood you right, I was amplifying what I
thought you were saying by noting that Save vs. Save As sounded
to me like it was an intentional overwrite. Again, I thank you
for the explanation but am still confused as to your logic and
procedure. Don't spend a lot of time trying to enlighten me, it
isn't worth your time unless you think others reading this thread
will benefit.

In my normal processing, before I'm finished with a picture, I
will do a Save, not Save As, periodically and especially
before I do something really drastic in case the Undo function
fails or, in PSP 9's case, something higher up in the History
Pallette fails and all is lost. But, if I'm about to do some
serious experimentation to go in a couple of directions to see
what works best on a complicated edit, I'll do a Save As to a
different file name for safety. If you're a PSP user, you'll
understand why my real standard "save" function is the JPEG
Optimizer because it gives me not only easy access to Chroma
subsampling, but a real- time finished file size in full
bytes, not KB, which I find indespensible in judging how much
to compress a given image, based on long past experience.

I too save under a new filename after every major or small
sequence of minor changes. It's not uncommon to have some of
my images in a folder named: img_5283.jpg (which is a copy of
original), img_5283_B.jpg, img_5283_C,jpg, .... up to half the
alphabet away. If I find I want to diverge from a previous
editing stage then I go back to that letter and start tacking
on numbers after the letter. img_5283_C_02.jpg, etc. Some of
my most prized images have 5 or more different edit-endings,
and I still can't decide which I like best. They're all good.
(It's hard to ruin a good image that was taken right in the
first place. They look right no matter what you do to them
sometimes.)

Of course, I either delete all the intermediate versions of I
park them in an "old & alternate version" subfolder.

The option to select the subsampling sizes is a nice feature
in PSP, and at times I wish I had that in PL32 after having
left PSP. But I have found that the subsampling rates that
PL32 selects automatically depending on the percentage of
compression I choose to be better than anything that I could
manually select in PSP. Keeping in mind too that not all of
those subsampling choices in PSP are compatible with other
editors and viewers. Choosing the wrong subsampling options in
PSP can make your image "corrupt" if you share it or use it in
other applications. PSP will still read it but all others may
not.

I've never encountered a corrupt JPEG based on Chroma subsampling
choices alone, but then, I've not gone to the 4x4 extreme options
because even casual checking convinced me that it made mincemeat
out of my car pictures. Of all 12 choices in PSP 9, I think I
only use 3, again, based on visual evaluation, not anything
scientific and certainly not specialized utility software
designed to analyze an image for damage.

If you ever check what PL32 can do, be certain to try the "Web
Export" tool dialog. (Under Web Web Export ...) It's like an
all-in-one JPG & GIF optimizer panel. I put a button for it
right next to my "Save" button on the toolbar. Not only can
you zoom in on the image to pixel level to see how your
compression choices are affecting the image quality (as in
PSP), but you can compare 2 different file-types and
compression schemes to the original right next to each other
(3 view panels). Being able to even save your most often used
compression choices as well as color-bit depths, reduction
methods, palette type, and transparency methods (for GIF and
PNG types). As I mentioned I got to see the beta of the new
PL32 v13.90. The author is also now including options to save
or strip out EXIF, IPTC, and XMP data in the Web Export tool.
You can compare JPG, GIF, PNG, JPG2000, and HDPhoto
compression schemes against one another visually, as well as
seeing the resulting file-size in exact bytes. This sure beats
PSP's individual GIF, PNG, & JPG optimizers. I don't miss them
in the least.

Thanks. I'm parking all these replies where I can find them again
if I decide to investigate either of the programs being debated
here.

Please realize that I'm hardly refuting anything you or anyone
is saying, I'm just asking questions and commenting on what
I've personally seen and done. All this stuff that has been
transpiring in this thread is fascinating to me, even if I
never acquire any of the software.

You should just go download the demo of PL32 and play with it.
It's a surprisingly small download (~8megs) for all that it
can do. The demo is completely functional, just a small nag
screen at start-up. I even keep copies of it installed on my
memory-cards for my cameras. I can run it right through the
USB port on a card-reader or right from any camera's USB port
if it allows me see the card's folders as an external device.
It takes up so little space too, the same as a few images on
the card. I carry my complete better-than-photoshop editor
with me right in my camera . When out traveling I only need to
borrow any public-access computer or friend's laptop to do all
my final edits out in the field and then save my final images
right back to new folders on my memory-cards. A digital camera
with PL32 on the memory-card gives me a complete photography
studio, from photo to finish, all in the palm of my hand. I
doesn't get better than that.

I like your handle. I am more than "fed up with Corel". They have
destroyed a program I have been using since it's shareware days
when author Bob Voit was a fulltime airline pilot and part time
software developer. Corel's marketing strategy is to acquire
software from successful developers and redesign it's GUI to look
new so as to catch the upgrade business and attract new customers
that a new version is available. But, obviously you are of the
same opinion as I am that new is not always better, and in the
case of PSP X and PSPP XI, not only is it not better, but Corel
has shown itself to be a callously deficient tester and regularly
releases versions and patches that are extremely buggy and
compound old bugs with new ones.

Having said that, again, I appreciate all your comments and
advice, but for now, I just don't have the time and energy to
learn a new app. I am so far behind that I am still plodding my
way through LAST year's car show and museum pictures. I imaging I
will break away from PSP when I get my next PC built, with will
be a quad-core AMD processor when speeds and reliability get high
enough and the price gets low enough, and Vista to take advantage
of much larger memory spaces and the multiple processors, but
AFTER Vista is ready for prime time, which I would expect based
on past MS experience won't be until it's first SP in at least a
year.

--
HP, aka Jerry

In rec.photo.digital HEMI-Powered wrote:

BTW, you've said 8x8 a couple of times. Excuse my ignorance
again, but I thought that the JPEG spec allowed both 8x8 and
16x16 blocks to be considered when deciding which pixels to throw
away. Or, am I mixing this up with something else? If I am right,
I have no idea if an image could have both block sizes in the
same file or not.

It is true that the JPEG standard says both 8x8 and 16x16 blocks
are allowed, but in practice, they always seem 8x8.

I have never seen lossless-rotate truncate to 16-bit boundaries.
Nor have I ever seen 16x16 artifacting. If anybody has examples,
please post them!

Bill Tuthill added these comments in the current discussion du
jour ...

In rec.photo.digital HEMI-Powered wrote:

BTW, you've said 8x8 a couple of times. Excuse my ignorance
again, but I thought that the JPEG spec allowed both 8x8 and
16x16 blocks to be considered when deciding which pixels to
throw away. Or, am I mixing this up with something else? If I
am right, I have no idea if an image could have both block
sizes in the same file or not.

It is true that the JPEG standard says both 8x8 and 16x16
blocks are allowed, but in practice, they always seem 8x8.

I have never seen lossless-rotate truncate to 16-bit
boundaries. Nor have I ever seen 16x16 artifacting. If
anybody has examples, please post them!

Bill, I don't want to hit this at all hard, but I could swear that
during the beta test for PSP 8, Jasc's Chief Scientist, the same
guy, Kris Zaklika, that wrote the math for DCNR, said that PSP 8
could decide in a "smart" way which block size to use. I could be
entirely all wet. Ditto for PSP 9. I really don't know. I do know
this, though, I honestly don't care about the theoretical math. As
I commented on earlier, I am a consumate pragmatist, and I make my
image judgements visually, not through software inspection tools.
So, whatever magic the software is doing to implement the math is
fine by me - so long as I can figure out optimum ways to use it.

Thanks for your comments and observations.

--
HP, aka Jerry

On Jul 25, 3:25 am, Bill Tuthill wrote:
In rec.photo.digital HEMI-Powered wrote:

All good apps can do lossless rotation, in 90 degree increments.
If Irfanview can do an arbitrary rotation losslessly, I'm not
aware of it, Bill. Which did you mean?

Yes, Irfanview does 90/180/270 degrees, or vertical/horizontal flip.
Just like PSP, apparently. (I have PSP 9 but don't use it much.)

It's not really lossless, because most images are not evenly divisible
by 8 in both directions, so "lossless" rotation usually trims off
some pixels rows or columns on the bottom or right side.

A good implementation of true lossless rotation refuses point blank to
do it if the requirements for preserving all the original information
are not met. For a crop it is that the top left corner must start on a
block boundary. Unless you are eagle eyed and have fine detail
crossing the edge at an oblique angle you are unlikely to spot this
happening casually - a lossless crop need not be a multiple of 8 in
dimension as the bottom right corner is unrestricted.

The problem is due to a weakness in the original JPEG spec which never
envisaged that programs would crop or rotate images in raw coefficient
space. It could be almost trivially fixed by adding a top and left
crop offset TAG (2 bytes) to the existing spec and increasing the size
of the image to the next higher multiple of 8/16.

Applications that understand the new tag would display the image with
original dimensions and rotated, whereas old applications would see a
slightly larger rotated image with spurious borders displayed top and/
or left. The problem is one of inertia and getting any changes adopted
by the standards committee.

Given the number of digital cameras about these days I would hazard a
guess that most original source JPEG images are multiples of 8 in both
dimensions (and that a substantial number are now multiples of 256).

Digicams situation is slightly complicated by the default 2x1 chroma
subsampling. This means that although lossless rotation is exact and
truly lossless some applications will display a slightly different
image from the rotated coefficients. So for example:

JPEG BMP Rot90
JPEG Rot90 BMP

Will yield slighlty different results in some applications. Adobe
which uses pixel replication for chroma reconstruction gets the same
both ways, some other common codecs do not. Try it and see.

Regards,
Martin Brown

On Jul 26, 3:13 am, "HEMI-Powered" wrote:
Bill Tuthill added these comments in the current discussion du
jour ...

In rec.photo.digital HEMI-Powered wrote:

BTW, you've said 8x8 a couple of times. Excuse my ignorance
again, but I thought that the JPEG spec allowed both 8x8 and
16x16 blocks to be considered when deciding which pixels to
throw away. Or, am I mixing this up with something else? If I
am right, I have no idea if an image could have both block
sizes in the same file or not.

It is true that the JPEG standard says both 8x8 and 16x16
blocks are allowed, but in practice, they always seem 8x8.

I have never seen lossless-rotate truncate to 16-bit
boundaries. Nor have I ever seen 16x16 artifacting. If
anybody has examples, please post them!

Bill, I don't want to hit this at all hard, but I could swear that
during the beta test for PSP 8, Jasc's Chief Scientist, the same
guy, Kris Zaklika, that wrote the math for DCNR, said that PSP 8
could decide in a "smart" way which block size to use. I could be

Either way that statement is incredibily funny.

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.

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.

Correct JPEG encoders get something that decodes to look like the
original unless you zoom in to pixel detail.

BRBRBR..
RRRRRR..
etc

And the others based on replicating the other 4 pixel motifs RB,RR;
RR,BR; RR,RB

The original is online at http://www.nezumi.demon.co.uk/photo/jpeg/rb_1x1.jpg
A correct IJG JPEG encodign at http://www.nezumi.demon.co.uk/photo/jpeg/rb_2x2.jpg
And the mess that PSP 8 makes of it at
http://www.nezumi.demon.co.uk/photo/jpeg/rb_2x1.jpg
http://www.nezumi.demon.co.uk/photo/jpeg/rb_2x2.jpg

I would be curious to know if this defect was fixed in later versions.

Regards,
Martin Brown

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

It's not really lossless, because most images are not evenly
divisible by 8 in both directions, so "lossless" rotation
usually trims off some pixels rows or columns on the bottom
or right side.

A good implementation of true lossless rotation refuses point
blank to do it if the requirements for preserving all the
original information are not met. For a crop it is that the
top left corner must start on a block boundary. Unless you are
eagle eyed and have fine detail crossing the edge at an
oblique angle you are unlikely to spot this happening casually
- a lossless crop need not be a multiple of 8 in dimension as
the bottom right corner is unrestricted.

The problem is due to a weakness in the original JPEG spec
which never envisaged that programs would crop or rotate
images in raw coefficient space. It could be almost trivially
fixed by adding a top and left crop offset TAG (2 bytes) to
the existing spec and increasing the size of the image to the
next higher multiple of 8/16.

How big of a problem is lossy compression vs. lossles-but-with-
severe limitations, anyway? Sure, I've mangled a few by over re-
editing my JPEGs when I had no choice, and I've damaged a few
visibly but not catasttrophically, but by doing the re-save
judiciously and by using careful softening of the aliasing and
artifacts that may result, I've always been able to get by. I
don't think I have low standards of quality, but then, I am also
not a purist, theotician, nor extremist. I am a consumate
pragmatist and if an image meets my reasonable definition of
"acceptable", I don't worry about it. Which goes to why I've
never investigated more sophisticated solutions.

But, I AM interested in this thread because I DO want to learn.
New knowledge is always being created and to ignore it is to be
both stupid and ignorant.

Applications that understand the new tag would display the
image with original dimensions and rotated, whereas old
applications would see a slightly larger rotated image with
spurious borders displayed top and/ or left. The problem is
one of inertia and getting any changes adopted by the
standards committee.

Given the number of digital cameras about these days I would
hazard a guess that most original source JPEG images are
multiples of 8 in both dimensions (and that a substantial
number are now multiples of 256).

Since my first digital in early 2001, I have immedidately tested
the two or more "quality" or "compression" options available and
always come the conclusion that "standard" or "normal" produces
visible artifacts in a high enough percenteage, maybe 5%, maybe
10%+, I always select "fine", "quality", whichever is the least
compression since I do not use RAW so of necessity I will be
doing at least one edit and one re-save. That philsophy has been
quite successful for me in my type of photography and for my
standards of quality and excellence.

Digicams situation is slightly complicated by the default 2x1
chroma subsampling. This means that although lossless rotation
is exact and truly lossless some applications will display a
slightly different image from the rotated coefficients. So for
example:

I have no clue what my Canon Rebel XT uses, but is seems unlikely
that it is 2x1 as I have found that to be a fairly damaging
setting. I don't know, but would think they use either 1x1 (none)
or no more than 1x2.

JPEG BMP Rot90
JPEG Rot90 BMP

Will yield slighlty different results in some applications.
Adobe which uses pixel replication for chroma reconstruction
gets the same both ways, some other common codecs do not. Try
it and see.

--
HP, aka Jerry

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

Bill, I don't want to hit this at all hard, but I could swear
that during the beta test for PSP 8, Jasc's Chief Scientist,
the same guy, Kris Zaklika, that wrote the math for DCNR,
said that PSP 8 could decide in a "smart" way which block
size to use. I could be

Either way that statement is incredibily funny.

Why is that "incredibly funny", Martin? I get the feeling that
you are calling me a fool.

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.

Come again? I do not know either the math or the implementation
but NEVER had any major problems with PSP 8 during the years from
its release until PSP 9 was released, which I was not given the
opportunity to be a public beta tester for.

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.

I don't do line art, don't do vectors, don't do text, don't do
layers, I ONLY do raster graphics bitmap photo/scan editing. So,
pathological examples such as ANY JPEG implementation mangling
line art or text does not surprise me, as that is hardly what
it's authors had in mind. I keep in mind that the "P" in JPEG
means "Photographer". So, I will hardly dispute your conclusions
but do not see how that is relevant to JPEG's real purpose and
usage, other than line art people also want mimimal size images
as well. But, I would think that to maintain maximum quality, you
would want to use a lossless format or even save only to your
favorite editors proprietary format, e.g., pspsimage.

For my car pictures, 2x2 subsampling turns them into one big
artifact, I never touch the stuff, so never suffer from its
limitions or damage.

Correct JPEG encoders get something that decodes to look like
the original unless you zoom in to pixel detail.

BRBRBR..
RRRRRR..
etc

And the others based on replicating the other 4 pixel motifs
RB,RR; RR,BR; RR,RB

The original is online at
http://www.nezumi.demon.co.uk/photo/jpeg/rb_1x1.jpg A correct
IJG JPEG encodign at
http://www.nezumi.demon.co.uk/photo/jpeg/rb_2x2.jpg And the
mess that PSP 8 makes of it at
http://www.nezumi.demon.co.uk/photo/jpeg/rb_2x1.jpg
http://www.nezumi.demon.co.uk/photo/jpeg/rb_2x2.jpg

I would be curious to know if this defect was fixed in later
versions.

For my usage, I didn't that PSP 8 was broken and would still be
using it today except that I deperately wanted DCNR in 9. I see
no visible difference from 8 to 9, or only barely visible
differnces, if I use identical JPEG 1-100 compresion and the
exact same Chroma subsampling. But, again, that is my experience
and YMMV.

--
HP, aka Jerry

"HEMI-Powered" wrote in message
...


How big of a problem is lossy compression vs. lossles-but-with-
severe limitations, anyway? Sure, I've mangled a few by over re-
editing my JPEGs when I had no choice, and I've damaged a few
visibly but not catasttrophically, but by doing the re-save
judiciously and by using careful softening of the aliasing and
artifacts that may result, I've always been able to get by. I
don't think I have low standards of quality, but then, I am also
not a purist, theotician, nor extremist. I am a consumate
pragmatist and if an image meets my reasonable definition of
"acceptable", I don't worry about it. Which goes to why I've
never investigated more sophisticated solutions.

But, I AM interested in this thread because I DO want to learn.
New knowledge is always being created and to ignore it is to be
both stupid and ignorant.


The best way to handle a lot of photo editing is to convert the original
Jpeg image from the camera (if that is what you camera produces) to a
lossless format such as TIFF. Tiff can be compressed using LZW compression,
which is the same compression scheme as ZIP files. LZW does not compress as
much as JPEG, but the compression is 100% no loss.

After converting to TIFF, you can edit and save as many times as you wish,
with no loss in picture quality.

After you are done with editing, you can then save a final image as Jpeg.
You should only do very limited edits on a JPEG file.

Every time you save a JPEG you are re-compressing and losing information.

There are claims of lossless JPEG, but not very many photo editors are
supporting the lossless formats. And they are not common.

Jpeg and Tiff image formats have been around for years and are not likely to
go away.

Here is a good list of image file formats and the best use.
http://www.scantips.com/basics09.html

Continue reading the following pages. A lot of good information in those
pages

--
CSM1
http://www.carlmcmillan.com
--

CSM1 added these comments in the current discussion du jour ...

But, I AM interested in this thread because I DO want to
learn. New knowledge is always being created and to ignore it
is to be both stupid and ignorant.

The best way to handle a lot of photo editing is to convert
the original Jpeg image from the camera (if that is what you
camera produces) to a lossless format such as TIFF. Tiff can
be compressed using LZW compression, which is the same
compression scheme as ZIP files. LZW does not compress as much
as JPEG, but the compression is 100% no loss.

As you probably know, my Rebel XT can do JPEG or RAW or both, but
not TIFF. I understand your point, of course, but about Ivory
Soap Pure percent of the time, I can get there with just one
save. When I cannot, I will save the file as a pspimage file so
as to preserve layers and Alpha channel stuff. I do some of the
former but a LOT of the latter to store various kinds of
selections so I do not have to always do global edits when
working on color, brightness/contrast, noise, etc.

After converting to TIFF, you can edit and save as many times
as you wish, with no loss in picture quality.

After you are done with editing, you can then save a final
image as Jpeg. You should only do very limited edits on a JPEG
file.

Every time you save a JPEG you are re-compressing and losing
information.

I know you're replying to the whole NG, but this doesn't happen
to me, although I do understand the non-linear degradation that
begins at about the 2nd re-edit/re-save cycle.

There are claims of lossless JPEG, but not very many photo
editors are supporting the lossless formats. And they are not
common.

Lossless is supported by so few apps and not at all on the web
and Usenet that it is useless. As you suggest, TIFF is better but
has the disadvantage that EXIF cannot be saved if you do LZW
compression, which makes them pretty large. So, again, when I
need to, I use pspimage because it saves EVERYTHING I am doing,
same as PhotoShop proprietary files do and any other good app can
do.

Jpeg and Tiff image formats have been around for years and are
not likely to go away.

As I understand it, JPEG began with a committee or consortia of
about half mathemticians and half real photographers to develop a
new format that could vastly reduce file size beyond the approx.
50% of an LZW TIFF. I haven't read the spec in a long time, but I
vaguely remember that the definition for JPEG=1 out of a possible
100 was to approximate LZW TIFF. And, since photographers are
only interested in continous tone (to the extent that is true for
24-bit color) photos, and they were NOT interested in line art or
raster text, both of which take an awful beating by JPEG unless
you are extremely conservative in your settings. At least, that
has been my experience and what I have heard/seen others say is
true.

Here is a good list of image file formats and the best use.
http://www.scantips.com/basics09.html

Continue reading the following pages. A lot of good
information in those pages

Thanks muchly!

--
HP, aka Jerry

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.

The original is online at http://www.nezumi.demon.co.uk/photo/jpeg/rb_1x1.jpg
Correct IJG JPEG encoding http://www.nezumi.demon.co.uk/photo/jpeg/rb_2x2.jpg

I think you got that filename wrong.

And the mess that PSP 8 makes of it at
http://www.nezumi.demon.co.uk/photo/jpeg/rb_2x1.jpg
http://www.nezumi.demon.co.uk/photo/jpeg/rb_2x2.jpg
I would be curious to know if this defect was fixed in later versions.

It appears to be mostly fixed. I'm not certain that the colors are
as accurate as with the equivalent IJG encodings, but they certainly
don't display the wild inaccuracy of the above encodings. I put them
online for you to see:

http://cacreeks.com/psp/ (filenames hopefully self-explanatory)

What's the difference between PSP's 2x1 1x1 1x1 and PSP's 1x2 1x1 1x1
encoding? I used the former, not the latter. PSP also has a bunch of
weird encodings not encountered in other software.