Differences in jpg lossless rotate freeware

M

MsOsWin

I rotated the same original photo using "lossless" rotation feature of each of these:
Fotoview, IrfanView (Jpeg_transform plugin), and Faststone.

The 3 resulting files all appear the same when viewed in all of those apps and when
viewed in IE6, Firefox 1.0, and WinXP's viewer (shimgvw). However resulting files look
*different* when viewed in thumbnail view of WinXP. Also, filesizes differ a little:


Photo view in XP thumb filesize kb

IMG_1342.jpg = Orig (compare to this) 765
FastoneRotat1342.jpg slightly sharper 764
FotoviewRotat1342.jpg dotted 765
IrfanviewRotat1342.jpg equally (?)smooth 751


Here are the files. "th" versions are thumbnail versions:


Original:
http://img160.exs.cx/img160/6933/img13425rf.th.jpg
http://img160.exs.cx/img160/6933/img13425rf.jpg

Fastone
http://img55.exs.cx/img55/7285/fastonerotat13428yo.th.jpg
http://img55.exs.cx/img55/7285/fastonerotat13428yo.jpg

Fotoview
http://img146.exs.cx/img146/4803/fotoviewrotat13420ov.th.jpg
http://img146.exs.cx/img146/4803/fotoviewrotat13420ov.jpg

IrfanView
http://img75.exs.cx/img75/8983/ifranviewrotat13424sj.th.jpg
http://img75.exs.cx/img75/8983/ifranviewrotat13424sj.jpg

Does anyone have any theories as to why the differences? I'd choose IrfanView, but I
also need lossless cropping and IrfanView Jpeg_transform lacks lossless crop.
 
M

Mike

Simple solution: save the original JPG in TIFF or another lossless
format, and crop/save as JPG from there.
 
S

Steve Wolfe

I rotated the same original photo using "lossless" rotation feature of
each of these:
Fotoview, IrfanView (Jpeg_transform plugin), and Faststone.

The 3 resulting files all appear the same when viewed in all of those apps and when
viewed in IE6, Firefox 1.0, and WinXP's viewer (shimgvw). However resulting files look
*different* when viewed in thumbnail view of WinXP. Also, filesizes differ
Click to expand...
a little:

I saved all four images, opened them in photoshop, rotated the original,
and pasted the various rotations of yours overtop with the layer set to
"difference", even at 800% magnification, I saw nothing but black.
Flattening the image, then turning the contrast up to 99 produced a couple
of odd pixels in each one - but the difference is so miniscule that they
might as well not even be there.

As to why the thumbnails would look different, I can't say, but it is
probably a flaw or weakness in XP's thumbnail generation and/or caching.

steve
 
T

Toke Eskildsen

I rotated the same original photo using "lossless" rotation
feature of each of these: Fotoview, IrfanView (Jpeg_transform
plugin), and Faststone.

The 3 resulting files all appear the same when viewed in all of
those apps and when viewed in IE6, Firefox 1.0, and WinXP's viewer
(shimgvw).
Click to expand...

They pixels are the same. If you convert the files to BMP and compare
them, you'll see that they are identical down to the last bit.
However resulting files look *different* when viewed in thumbnail
view of WinXP.
Click to expand...

That's because XP displays the thumbnails embedded in the JPEGs.
Apparently the three utilities uses different methods for creation of
the embedded thumbnails.

If you don't like that, you can use a tool like jhead to remove the
embedded thumbnails. Note that this will slow down previewing.
 
T

Toke Eskildsen

Mike said:
Simple solution: save the original JPG in TIFF or another lossless
format, and crop/save as JPG from there.
Click to expand...

By using your method, an additional JPEG compression with resulting
artifacts would be introduced, while the lossless scenario avoids this.
 
M

MsOsWin

I saved all four images, opened them in photoshop, rotated the
original,
and pasted the various rotations of yours overtop with the layer set
to
"difference", even at 800% magnification, I saw nothing but black.
Flattening the image, then turning the contrast up to 99 produced a
couple of odd pixels in each one - but the difference is so miniscule
that they might as well not even be there.
Click to expand...

Ah, thanks for pursuing a comparison I was unaware is possible.

since Irfan produced smallest kb, I wondered if Irfan 'optimized' non visual data out of
existence. but during lossless rotates, i chose transform Options that saved info. And,
file Properties showed the text data retained.

i didn't check whether any of the other apps might have deleted EXIF type data.
As to why the thumbnails would look different, I can't say, but it
is
probably a flaw or weakness in XP's thumbnail generation and/or
caching.
Click to expand...

the flaw seems to be consistent in that files cropped by Fotoview are 'dotty' looking (in
XP thumb view), while Irfan's are smooth. (I discovered this only because I saw this
obvious difference within a folder of both Irfan and Fotoview files.)
 
M

MsOsWin

Toke Eskildsen <[email protected]> in 130.133.1.4:

They pixels are the same. If you convert the files to BMP and compare
them, you'll see that they are identical down to the last bit.


That's because XP displays the thumbnails embedded in the JPEGs.
Apparently the three utilities uses different methods for creation of
the embedded thumbnails.
Click to expand...

aha!
now i recall reading about that internal thumbnail 'feature' in digicam file creation.
If you don't like that, you can use a tool like jhead to remove the
embedded thumbnails.
Click to expand...

also creating slightly smaller images for web browsers.
Note that this will slow down previewing.
Click to expand...

and presumably xp thumbs would be forced to create identical thumbs.

noting your other response regarding tiff >> jpg loss, i'll probably keep using the
lossless transforms, since in this case, i'm not picky about *precision* crop or rotation.

thanks for all replies.
 
K

Keith Sheppard

Apparently the three utilities uses different methods for creation of
I can think of three ways an application might go about this. The embedded
thumbnail is, itself, jpeg encoded so you could:

1. Perform lossless rotation of the thumbnail jpeg.

2. Perform bitwise rotation of the thumbnail and re-encode.

3. Create a new thumbnail from the rotated main image.

In my own application I used option 3 because it was the easiest. It means
that the new thumbnail may not be a precise rotation of the original
thumbnail but the quality should be equivalent. Mind you, I am not
convinced that option 1 is any better. The original thumbnail was
(presumably) created by reducing and encoding the original image so there's
no reason to suppose that rotating it will produce better results than
repeating the reduce/encode process on an identical but rotated image.

Option 2 is the worst because it implies progressive degradation of the
thumbnail image with each rotation.

Keith
 
C

Colin D

[email protected] said:
I rotated the same original photo using "lossless" rotation feature of each of these:
Fotoview, IrfanView (Jpeg_transform plugin), and Faststone.

The 3 resulting files all appear the same when viewed in all of those apps and when
viewed in IE6, Firefox 1.0, and WinXP's viewer (shimgvw). However resulting files look
*different* when viewed in thumbnail view of WinXP. Also, filesizes differ a little:

Photo view in XP thumb filesize kb

IMG_1342.jpg = Orig (compare to this) 765
FastoneRotat1342.jpg slightly sharper 764
FotoviewRotat1342.jpg dotted 765
IrfanviewRotat1342.jpg equally (?)smooth 751

Here are the files. "th" versions are thumbnail versions:

Original:
http://img160.exs.cx/img160/6933/img13425rf.th.jpg
http://img160.exs.cx/img160/6933/img13425rf.jpg

Fastone
http://img55.exs.cx/img55/7285/fastonerotat13428yo.th.jpg
http://img55.exs.cx/img55/7285/fastonerotat13428yo.jpg

Fotoview
http://img146.exs.cx/img146/4803/fotoviewrotat13420ov.th.jpg
http://img146.exs.cx/img146/4803/fotoviewrotat13420ov.jpg

IrfanView
http://img75.exs.cx/img75/8983/ifranviewrotat13424sj.th.jpg
http://img75.exs.cx/img75/8983/ifranviewrotat13424sj.jpg

Does anyone have any theories as to why the differences? I'd choose IrfanView, but I
also need lossless cropping and IrfanView Jpeg_transform lacks lossless crop.
Click to expand...

I get a different file size than your table above when I right click on
the image and look at file info. Here is your table with the sizes I
obtained:
IMG_1342.jpg = Orig (compare to this) 782,972
FastoneRotat1342.jpg slightly sharper 781,865
FotoviewRotat1342.jpg dotted 783,192
IrfanviewRotat1342.jpg equally (?)smooth 768,903
Click to expand...

Can't say at this point whether the varying sizes are due to algorithmic
differences or due to the rotation. However, since ordinary jpeg
compression uses a 16 x 16 matrix of pixels, for lossless rotation the
image dimensions need to divide evenly by 16 - which your 1600 x 1200
pixel images will do (this can be a problem if you crop and re-save with
non-divisible dimensions). So, I guess that the differences are indeed
due to different algorithms being used. I presume you used the same
compression level on each image.

Colin
 
A

Alfred Molon

Can't say at this point whether the varying sizes are due to algorithmic
differences or due to the rotation. However, since ordinary jpeg
compression uses a 16 x 16 matrix of pixels,
Click to expand...

Should be 8x8 unless they changed something.
 
D

Dave Martindale

[email protected] said:
since Irfan produced smallest kb, I wondered if Irfan 'optimized' non
visual data out of
existence.
Click to expand...

If it did that, the rotation wouldn't be lossless.

However, if you check the "optimize" box in the Irfanview JPEG rotate
dialog, what this (almost certainly) does is select two-pass Huffman
encoding instead of one-pass Huffman encoding of the data. The former
takes longer but usually produces smaller files. The *decoded* data is
the same in both cases; it's just a choice between a more efficient but
more expensive compression algorithm and the default compression.

Dave
 
D

Dave Martindale

Should be 8x8 unless they changed something.
Click to expand...

Don't forget the chroma downsampling. The basic block of the source
image for compression can be 8x8, 16x16, 8x16, or 16x8 depending on
which directions chroma downsampling is used in. You only get 8x8
source image blocks if there is no chroma downsampling at all. Some
encoders give you this choice, some do not.

Dave
 
J

Jürgen Eidt

Colin D said:
Can't say at this point whether the varying sizes are due to algorithmic
differences or due to the rotation. However, since ordinary jpeg
compression uses a 16 x 16 matrix of pixels, for lossless rotation the
image dimensions need to divide evenly by 16 - which your 1600 x 1200
pixel images will do (this can be a problem if you crop and re-save with
non-divisible dimensions). So, I guess that the differences are indeed
due to different algorithms being used. I presume you used the same
compression level on each image.
Click to expand...
JPEG uses a 8x8 block, but with the color sub sampling, the minimum coding
unit (MCU) is a multiple of 8x8. 16x8 for most camera pictures. If you have
a scanned picture, it depends on your settings.
So when the picture is rotated lossless and the trim option is used, the
image is cropped to this grid. Doesn't apply to pictures from a digital
camera, since they are a multiple of this.
 
K

Keith Sheppard

OK, first a couple of questions. I replied to this posting yesterday but I
don't see my response when Outlook Express displays the newsgroup.

Q1. Did my original response appear in the newsgroup?

Q2. If not, why might it not have made it? It's in my sent items folder?
If it did make it, why can't I see it?

Any responses from Outlook Express experts greatly appreciated.

Original response below signature.

Keith

I can think of three ways an application might go about this. The embedded
thumbnail is, itself, jpeg encoded so you could:

1. Perform lossless rotation of the thumbnail jpeg.

2. Perform bitwise rotation of the thumbnail and re-encode.

3. Create a new thumbnail from the rotated main image.

In my own application I used option 3 because it was the easiest. It means
that the new thumbnail may not be a precise rotation of the original
thumbnail but the quality should be equivalent. Mind you, I am not
convinced that option 1 is any better. The original thumbnail was
(presumably) created by reducing and encoding the original image so there's
no reason to suppose that rotating it will produce better results than
repeating the reduce/encode process on an identical but rotated image.

Option 2 is the worst because it implies progressive degradation of the
thumbnail image with each rotation.

Keith
 
J

John Fitzsimons

OK, first a couple of questions. I replied to this posting yesterday but I
don't see my response when Outlook Express displays the newsgroup.
Click to expand...
Q1. Did my original response appear in the newsgroup?
Click to expand...

You mean.....

X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Message-ID: <[email protected]>
Date: Thu, 06 Jan 2005 10:32:44 GMT
NNTP-Posting-Host: 62.252.196.72
Q2. If not, why might it not have made it? It's in my sent items folder?
If it did make it, why can't I see it?
Click to expand...

< snip >

Your ISP might not get every post in the newsgroup(s) you posted to.
It might, or might not, appear in a day or two.

The solution is to get a better news feed and/or get your newsgroups
from multiple newsgroup servers.

Regards, John.

--
****************************************************
,-._|\ (A.C.F FAQ) http://clients.net2000.com.au/~johnf/faq.html
/ Oz \ John Fitzsimons - Melbourne, Australia.
\_,--.x/ http://www.vicnet.net.au/~johnf/welcome.htm
v http://clients.net2000.com.au/~johnf/
 
Top