Sign in with
Sign up | Sign in
Your question

Differences in jpg lossless rotate freeware

Last response: in Digital Camera
Share
Anonymous
January 6, 2005 11:18:49 AM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

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.j...
http://img55.exs.cx/img55/7285/fastonerotat13428yo.jpg

Fotoview
http://img146.exs.cx/img146/4803/fotoviewrotat13420ov.t...
http://img146.exs.cx/img146/4803/fotoviewrotat13420ov.j...

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

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.
January 6, 2005 11:18:50 AM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

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

<MsOsWin@anon.com> wrote in message news:Xns95D636EAAC6DMsOsWinAnon@64.85.239.19...
> 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.j...
> http://img55.exs.cx/img55/7285/fastonerotat13428yo.jpg
>
> Fotoview
> http://img146.exs.cx/img146/4803/fotoviewrotat13420ov.t...
> http://img146.exs.cx/img146/4803/fotoviewrotat13420ov.j...
>
> IrfanView
> http://img75.exs.cx/img75/8983/ifranviewrotat13424sj.th...
> http://img75.exs.cx/img75/8983/ifranviewrotat13424sj.jp...
>
> 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.
Anonymous
January 6, 2005 11:18:50 AM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

> 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:

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
Related resources
Anonymous
January 6, 2005 11:56:51 AM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

MsOsWin@anon.com wrote:

> 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).

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.

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.
Anonymous
January 6, 2005 11:57:31 AM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

Mike wrote:

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

By using your method, an additional JPEG compression with resulting
artifacts would be introduced, while the lossless scenario avoids this.
Anonymous
January 6, 2005 12:21:42 PM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

"Steve Wolfe" <unt@codon.com> in news:344c93F45t0g9U1@individual.net:


> 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.

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.

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.)
Anonymous
January 6, 2005 12:43:11 PM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

Toke Eskildsen <darkwing@daimi.au.dk> in news:Xns95D66537D6327tokeeskildsen@
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.
>
>> However resulting files look *different* when viewed in thumbnail view
>> of WinXP.
>
> That's because XP displays the thumbnails embedded in the JPEGs.
> Apparently the three utilities uses different methods for creation of
> the embedded thumbnails.

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.

also creating slightly smaller images for web browsers.

> Note that this will slow down previewing.

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.
Anonymous
January 6, 2005 1:32:44 PM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

>>Apparently the three utilities uses different methods for creation of
>>the embedded thumbnails.

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
Anonymous
January 7, 2005 2:33:31 AM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

"MsOsWin@anon.com" wrote:
>
> 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.j...
> http://img55.exs.cx/img55/7285/fastonerotat13428yo.jpg
>
> Fotoview
> http://img146.exs.cx/img146/4803/fotoviewrotat13420ov.t...
> http://img146.exs.cx/img146/4803/fotoviewrotat13420ov.j...
>
> IrfanView
> http://img75.exs.cx/img75/8983/ifranviewrotat13424sj.th...
> http://img75.exs.cx/img75/8983/ifranviewrotat13424sj.jp...
>
> 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.

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

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
Anonymous
January 7, 2005 2:33:32 AM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

In article <41DD13FB.20702914@killspam.127.0.0.1>, Colin D says...

> 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,

Should be 8x8 unless they changed something.
--

Alfred Molon
------------------------------
http://groups.yahoo.com/group/Olympus_405080/
Olympus 5060 resource - http://myolympus.org/5060/
Olympus 8080 resource - http://myolympus.org/8080/
Anonymous
January 7, 2005 2:33:32 AM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

"Colin D" <ColinD@killspam.127.0.0.1> schrieb
> 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.
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.
Anonymous
January 7, 2005 7:14:08 AM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

"MsOsWin@anon.com" <MsOsWin@anon.com> writes:

>since Irfan produced smallest kb, I wondered if Irfan 'optimized' non
>visual data out of
>existence.

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
Anonymous
January 7, 2005 7:17:12 AM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

Alfred Molon <alfred_molonREMOVE@yahoo.com> writes:

>> 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,

>Should be 8x8 unless they changed something.

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
Anonymous
January 7, 2005 12:29:43 PM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

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

>>Apparently the three utilities uses different methods for creation of
>>the embedded thumbnails.

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
Anonymous
January 7, 2005 5:13:21 PM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

your orig post appeared for me
"Keith Sheppard" <keith.sheppard@tesco.net> in
news:gt8Dd.35$Ow3.12@newsfe2-win.ntli.net:


> 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.
Anonymous
January 8, 2005 1:50:38 PM

Archived from groups: rec.photo.digital,alt.comp.freeware (More info?)

On Fri, 07 Jan 2005 09:29:43 GMT, "Keith Sheppard"
<keith.sheppard@tesco.net> wrote:

>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?

You mean.....

X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Message-ID: <gt8Dd.35$Ow3.12@newsfe2-win.ntli.net>
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?

< 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/
!