What program is best at JPEG compression?

In article <Xns9977DCA45B4ABReplyScoreID.RemoveThis@140.99.99.130>,
HEMI-Powered <none.RemoveThis@none.en> wrote:
>Mike S. added these comments in the current discussion du jour
>...
>
>>>That's what I always thought, until I read about these magic
>>>programs in this thread. I'm no expert and not interested in
>>>trying to verify the veracity of the claims because my work
>>>isn't such that would be helped. But, in keeping with my
>>>general philosophy that learning is a life-long endeavor, if
>>>somebody has invented a better mouse trap, I'm interested
>>>enough to at least listem.
>>
>> JPEG Wizard's claims for lossless processing are quite clear.
>> Photoline 32 suffers from poor translation from German, both
>> on their web site and the help files. A strict reading would
>> suggest that only crop and rotate functions are lossless,
>> which is not a unique achievement. But they talk about changed
>> and unchanged "JPEG data" which probably means something more
>> exact in the original German.
>>
>Mike, sorry to still be dense, but is the rotate general or in 90
>deg increments?

It's in 90 degree increments as you would suspect.
 >> Stay informed about: 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
 >> Stay informed about: What program is best at JPEG compression? 

In rec.photo.digital HEMI-Powered <none DeleteThis @none.en> 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!
 >> Stay informed about: What program is best at JPEG compression? 

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

> In rec.photo.digital HEMI-Powered <none.RemoveThis@none.en> 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
 >> Stay informed about: What program is best at JPEG compression? 

On Jul 25, 3:25 am, Bill Tuthill <ccree... RemoveThis @yahoo.com> wrote:
> In rec.photo.digital HEMI-Powered <n... RemoveThis @none.en> 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
 >> Stay informed about: What program is best at JPEG compression? 

On Jul 26, 3:13 am, "HEMI-Powered" <n....DeleteThis@none.en> wrote:
> Bill Tuthill added these comments in the current discussion du
> jour ...
>
> > In rec.photo.digital HEMI-Powered <n....DeleteThis@none.en> 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
 >> Stay informed about: What program is best at JPEG compression? 

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
 >> Stay informed about: What program is best at JPEG compression? 

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
 >> Stay informed about: What program is best at JPEG compression? 

In rec.photo.digital Martin Brown <|||newspam|||@nezumi.demon.co.uk> 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.
 >> Stay informed about: What program is best at JPEG compression? 

"HEMI-Powered" <none DeleteThis @none.en> wrote in message
news:Xns997A6359B2A6DReplyScoreID@140.99.99.130...

>
> 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
--
 >> Stay informed about: What program is best at JPEG compression? 

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
 >> Stay informed about: What program is best at JPEG compression? 

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

>> 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.
>
> You can convert RAW to Tiff in ZoomBrowser EX that was
> included with your Canon Rebel XT.

Assuming that the best quality of JPEG is Okey, Dokey, I could
convert that to TIFF if I were of a mind to convert it to any
lossless format, which I am not. I don't do RAW yet because
despite more than a year of looking, I have year to find a "RAW
for Dummies" book that can get me to the first step in the
learning process. One time. I am interested in all of this, but
until I hear of a truly better mousetrap, my current workflow
works just fine, with a rare need to save in pspimage,

> From the EOS DIGITAL Software Instruction Manual Windows (PDF,
> 3.98 MB). The Supported Images are JPEG, RAW, BMP, TIFF and
> PCD (Kodak Photo CD images).

I also have Raw Shooter Premium, but do not have the need yet,
considering the above - don't know how to get to the starting
line for RAW, and don't really want to shoot at 8 mega pixels
when I save to about 1.5 MP eventually.

> But I was talking about converting the Jpeg image in a Photo
> editor(Photoshop or The Gimp) to a Tiff image, before doing
> any edits.
>
> By the way, Tiff does support EXIF info.
> Tiff is one of the image formats in the EXIF 2.2
> specification. The metadata part of a EXIF Jpeg are TIF tags.

I thought that to get EXIT into TIFF, it has to be the
uncompressed kind.
>
> You load the jpeg, and immediately Save As Tiff.
> You then work on the Tiff image only, you leave the jpeg as
> the master image.
>
> Tiff LZW supports EXIF also, the only difference is a smaller
> file in most cases, however there are cases where the Tiff LZW
> file is actually larger than the uncompressed TIFF.

I'll look again, maybe I am harboring a misconception. Thanks.

--
HP, aka Jerry
 >> Stay informed about: What program is best at JPEG compression? 

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

> 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.
>
My experience with PSP 8 some time ago and 9 more recently is that
1x2 creates larger files but higher quality due to less artifacts
of various types, one insidious one looking for all the world like
noise but it isn't. 2x2, OTOH, produces a much smaller file size;
you need to visually judge the difference in quality to see which
you like better. I only use 2x2 when I am desperate for smaller
size and upping the JPEG compression number is also producing
unacceptable defects. It is a big juggling act and some
experimentation may be necessary for you.

--
HP, aka Jerry
 >> Stay informed about: What program is best at JPEG compression?