Strange behaviour of (some) JPG thumbnails

[Terry Pinnell]

This is really puzzling me. I have a folder of images made in FastStone
Viewer by using its Frame Mask tool. Here's a screenshot:
https://dl.dropbox.com/u/4019461/ThumbnailProblem-1.jpg
ALL the JPGs should have the 'feathered' look just like 82.jpg, but to get
that displayed I have to manually select them, right click, and use
'Refresh thumbnails'. Yet they are just plain JPGs. No layers or any other
stuff.

Once I've manually refreshed them, if I close that folder and re-open it,
or edit one or more of the images, or change their names, etc, they return
to the 'original' thumbnails you see, without the 'feathered' white space
created in FS Viewer.

This is unaffected by the setting Tools > Folder Options > View > 'Do not
cache thumbnails'. Ringing the changes on that (rather poorly worded
setting IMO) was about the first thing I tried, and it makes no difference
either way. (Side issue: just what is that setting supposed to do?)

After closing and re-opening that folder (or going up the tree and back)
this is what I see:
https://dl.dropbox.com/u/4019461/ThumbnailProblem-2.jpg


HOWEVER, this problem is confined to JPGs. If I make BMP, PNG or GIF
versions of those same images,
they DO retain their correct thumbnails!
https://dl.dropbox.com/u/4019461/ThumbnailProblem-3.jpg

(And BTW that's true whether 'Do not cache thumbnails' is checkmarked or
not.)

More tests reveal the strange fact that only these 'frame masked in
FastStone Viewer' JPGs exhibit this behaviour. If I take a JPG photo, open
it in say IrfanView and crop it, the changed thumbnail of that is
immediately displayed correctly. And if I open a JPG in PaintShop Pro and
crop it to an irregular freehand shape and save that as a JPG (with
irregular white surrounding the remaining picture) then that too gets and
keeps its correct thumbnail.

Anyone have any ideas as to what may be the cause of this apparent quirk
please?

--
Terry, East Grinstead, UK

[Martin Brown]

I would hazard a guess that Fastone or whatever it is modifies the main
image JPEG stream but leaves the embedded thumbnail as it is.

Browsers will typically grab the small embedded thumbnail and only read
the entire image stream when you force a full manual refresh. If you
send me a sample image privately it would be easy enough to check.

--
Regards,
Martin Brown

My strange looking Usenet email address is perfectly valid provided that
it is *not* altered in any way.

[Terry Pinnell]

Thanks, Martin, that explanation sounds very plausible to me.

I've emailed you an example and look forward to reading your conclusions.

But here's the same example file in case anyone else wants to check it
out.
https://dl.dropbox.com/u/4019461/ExampleFromFSV.jpg

[Me]

With W7:
The thumbnail for that image shows correctly if large or extra large
icons are selected in Windows Explorer. But it uses the embedded
thumbnail if "tile" or "normal" or smaller icon view size is selected.
Irfanview and XNview internal browser show the thumbnail correctly at
any size, but Nikon software shows the embedded thumbnail.
The thumbnail also shows correctly in the default file manager in Android 4.
So, sometimes programs use the embedded thumbnail, sometimes they don't,
and sometimes (W7 explorer) it just depends...
I agree with Martin - the problem seems to be with the image editing
software you're using.

[Terry Pinnell]

Thanks, that indeed seems to be the cause.

It's interesting that W7 shows it correctly. And presumably retains that?
Unlike XP (which has just the single thumbnail view, not two).

[Martin Brown]

It is hard to know whether to blame your software for not recognising
the embedded compressed TIFF thumbnail or the horrible abortion that is
the Exif II spec for permitting it to exist in the first place. The
embedded thumbnail is there but in a form that only some Exif readers
can see - I am not surprised that the poor program missed it!

I have never seen a thumbnail use this encoding before nor can I quite
see how the OS can decode it since it looks at first glance to be
intrinsically malformed (but I know much less about TIFF format quirks).

Camera identifies itself as Ixus 220 HS JPEG Firmware Version 1.0 and
the file as Exif II. You could strip out the Exif data and that would
force the OS to generate a thumbnail from the real data stream.

--
Regards,
Martin Brown

[Mayayana]

| I have never seen a thumbnail use this encoding before nor can I quite
| see how the OS can decode it since it looks at first glance to be
| intrinsically malformed (but I know much less about TIFF format quirks).
|

As you probably already know, there are 3 possible encoding
types. I've also only see "type 6", an embedded JPG. The file
here is type 1. It's not only different format, though. The info.
needed to extract it is stored in different places!

If the value of Compression(0x0103) Tag in IFD1 is '6', thumbnail image
format is JPEG. Most of Exif image uses JPEG format for thumbnail. In that
case, you can get offset of thumbnail by JpegIFOffset(0x0201) Tag in IFD1,
size of thumbnail by JpegIFByteCount(0x0202) Tag. Data format is ordinary
JPEG format, starts from 0xFFD8 and ends by 0xFFD9. It seems that JPEG
format and 160x120pixels of size are recommended thumbnail format for
Exif2.1 or later.


TIFF format thumbnail
If the value of Compression(0x0103) Tag in IFD1 is '1', thumbnail image
format is no compression(called TIFF image). Start point of thumbnail data
is StripOffset(0x0111) Tag, size of thumbnail is the sum of
StripByteCounts(0x0117) Tag.

If thumbnail uses no compression and PhotometricInterpretation(0x0106)Tag in
IFD1 has a value '2', thumbnail uses RGB format. In that case, you can see
thumbnail image by simply copy data to computer's RGB format

[Terry Pinnell]

Thanks, Martin, appreciate your taking the time to check that. Is it
something I could do myself in future? I did just take a look with a Hex
Editor, but found only these few 'strings':

Address Length
00000006 00000004 JFIF
00000018 00000004 Exif
000000C4 00000005 Canon
000000CA 00000011 Canon IXUS 220 HS
000000EC 00000013 2012:06:22 21:47:42
00000297 00000013 2011:07:27 09:50:00
000002AC 00000013 2011:07:27 09:50:00
000004F3 00000014 IMG:IXUS 220 HS JPEG
00000508 00000015 Firmware Version 1.00

Nothing there about embedded thumbnails, so I assume you used some special
tool?

You mentioned TIFF. Is the thumbnail a different type to the file (JPG)?
And I'm curious about that 'JFIF' above?

[Terry Pinnell]

Ah, just seen this after replying to Martin. Although much of it is over
my head, it answers the questions that were puzzling me, thanks.

My practical solution for now is to open those quirky JPGs in IrfanView
and re-save as BMP or PNG.

[Martin Brown]

On 12/09/2012 13:51, Mayayana wrote:
> | I have never seen a thumbnail use this encoding before nor can I quite
> | see how the OS can decode it since it looks at first glance to be
> | intrinsically malformed (but I know much less about TIFF format quirks).
> |
> As you probably already know, there are 3 possible encoding
> types. I've also only see "type 6", an embedded JPG. The file
> here is type 1. It's not only different format, though. The info.
> needed to extract it is stored in different places!

As I said TIFF isn't really my thing and I loathe Exif because it is so
often malformed and teetering on the brink of disaster.

>
> If the value of Compression(0x0103) Tag in IFD1 is '6', thumbnail image
> format is JPEG. Most of Exif image uses JPEG format for thumbnail. In that
> case, you can get offset of thumbnail by JpegIFOffset(0x0201) Tag in IFD1,
> size of thumbnail by JpegIFByteCount(0x0202) Tag. Data format is ordinary
> JPEG format, starts from 0xFFD8 and ends by 0xFFD9. It seems that JPEG
> format and 160x120pixels of size are recommended thumbnail format for
> Exif2.1 or later.

And analysis of the JPEG stream gets the thumbnail automatically.
Usually after seeing a random number of SOI tags between 1 and 3.

> TIFF format thumbnail
> If the value of Compression(0x0103) Tag in IFD1 is '1', thumbnail image
> format is no compression(called TIFF image). Start point of thumbnail data
> is StripOffset(0x0111) Tag, size of thumbnail is the sum of
> StripByteCounts(0x0117) Tag.
>
> If thumbnail uses no compression and PhotometricInterpretation(0x0106)Tag in
> IFD1 has a value '2', thumbnail uses RGB format. In that case, you can see
> thumbnail image by simply copy data to computer's RGB format

What was confusing me was that it managed to have enough spread in the
values of bytes in the RGB uncompressed image blocks to convince my JPEG
analyser that it was a compressed binary stream with entropy >5.
I was looking for TIFF compressed format headers - my mistake.

You are right it is 24 bit RGB 8,8,8 160x120 uncompressed TIFF.

There should be utilities around that will let you selectively remove
Exif data from a file although offhand I can't think of one. I think
Guido's JPEGcrop will let you strip all header info by using a lossless
transcoder with preferences set to Marker Copy Option = None

That works on the coefficients directly maintaining original JPEG data.

--
Regards,
Martin Brown

[Mayayana]

| Ah, just seen this after replying to Martin. Although much of it is over
| my head, it answers the questions that were puzzling me, thanks.
|

If you're curious, the info. I posted is from here:
http://www.media.mit.edu/pia/Research/deepview/exif.html

That's the most clear doc I know for the JPG EXIF data
header format. There's a more thorough v. 2.2 version here:

http://exif.org/Exif2-2.PDF

But that one is the whole spec and not very explanatory.
And I don't know of any notable changes to EXIF tags in
v. 2 vs v. 1 of the spec.
As Martin Brown said, the standard is a mess. It's also
designed so that "everyone and his brother" can claim their
own piece of it. Which many camera companies do. Even
Microsoft usurped an EXIF tag for itself to save "Summary"
values in the Properties window. (Right-click -> Properties.
I've forgotten which version[s] of Windows they use that in.)

| My practical solution for now is to open those quirky JPGs in IrfanView
| and re-save as BMP or PNG.
|

Makes sense. There isn't really any other option.
You can't change the thumbnail without rebuilding
the file. I'm surprised that Fastone saves any of
the data in the first place. I would have thought it
would write a fresh JPG, losing all EXIF tags, once you
edited it.

[Mayayana]

| >Camera identifies itself as Ixus 220 HS JPEG Firmware Version 1.0 and
| >the file as Exif II. You could strip out the Exif data and that would
| >force the OS to generate a thumbnail from the real data stream.
|
| Thanks, Martin, appreciate your taking the time to check that. Is it
| something I could do myself in future? I did just take a look with a Hex
| Editor, but found only these few 'strings':
|
| Address Length
| 00000006 00000004 JFIF
| 00000018 00000004 Exif
| 000000C4 00000005 Canon
| 000000CA 00000011 Canon IXUS 220 HS
| 000000EC 00000013 2012:06:22 21:47:42
| 00000297 00000013 2011:07:27 09:50:00
| 000002AC 00000013 2011:07:27 09:50:00
| 000004F3 00000014 IMG:IXUS 220 HS JPEG
| 00000508 00000015 Firmware Version 1.00
|
| Nothing there about embedded thumbnails, so I assume you used some special
| tool?
|
| You mentioned TIFF. Is the thumbnail a different type to the file (JPG)?
| And I'm curious about that 'JFIF' above?
|

I don't know if this will be useful, but it may be of
interest to some people:

http://www.jsware.net/jsware/scripts.php5#jpginf

Explanation: At one time I wrote VBScripts to extract EXIF data
and thumbnails from JPGs, mostly for the purpose of viewing
large numbers of thumbnails, from very big files, quickly and easily.
Your dilemma made me revisit those scripts. I had only written code
to extract JPG-type thumbnails. A thumbnail can also be "uncompressed",
of 3 types: monochrome, RGB, and yCbCr. But until you posted your
picture I had never seen a thumbnail that was not JPG. Yours is
uncompressed RGB. I'm guessing that the other two types are
probably even more rare.

I updated my scripts to extract both JPG and uncompressed RGB
thumbnails. (The latter is actually just the bitmap bytes of the image.
While a JPG thumbnail is a whole file embedded, the RGB thumbnail
requires that the bytes be re-ordered and a BMP file header be
constructed before writing the data to disk.)

I also wrote scripts to remove the EXIF section altogether, as
there seemed to be some interest in that. It's all in the download
linked above, along with an info. file.

JFIF is a somewhat pointless but "traditional" header included
in JPG files. Neither EXIF nor JFIF is necessary, but at least one
seems to be present in all JPGs. While the EXIF section can hold
a great deal of structured information, the JFIF header does not
usually hold anything of much interest. Yet image editors saving
to JPG, when not incorporating EXIF data, seem to always put in
a JFIF header after the first two "magic" bytes of FF D8. In some
cases there may even be multiple JFIF headers strewn about,
without any harm to the image data. All sections have unique marker
bytes, so a JPG can have numerous sections, they can be in great
disarray, and they often are. Since all are marked, decoding software
has no trouble parsing the actual image data despite that. But it
does make things very confusing for anyone trying to make sense of
the file structure. Most file headers have very specific structures,
but with JPGs, apart from the required sections of image data, any
prepended data sections are often just a willy nilly collection of
information and debris.

The scripts are VBScript. They can be edited as desired. As written
they work by just dropping a file [or folder] onto the script. They will
work on any Windows PC and on Linux under WINE with the Windows
Script Host libraries installed to the WINE system folder. But I don't
know of any way to get them working on a Mac.