Strange behaviour of (some) JPG thumbnails

Discussion in 'Digital Photography' started by Terry Pinnell, Sep 11, 2012.

  1. 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
    Terry Pinnell, Sep 11, 2012
    #1
    1. Advertising

  2. Terry Pinnell

    Martin Brown Guest

    On 11/09/2012 20:18, Terry Pinnell wrote:
    > 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?


    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.
    Martin Brown, Sep 11, 2012
    #2
    1. Advertising

  3. Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:

    >On 11/09/2012 20:18, Terry Pinnell wrote:
    >> 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?

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


    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

    --
    Terry, East Grinstead, UK
    Terry Pinnell, Sep 11, 2012
    #3
  4. Terry Pinnell

    Me Guest

    On 12/09/2012 8:42 a.m., Terry Pinnell wrote:
    > Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:
    >
    >> On 11/09/2012 20:18, Terry Pinnell wrote:
    >>> 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?

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

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


    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.
    Me, Sep 12, 2012
    #4
  5. Me <> wrote:

    >On 12/09/2012 8:42 a.m., Terry Pinnell wrote:
    >> Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:
    >>
    >>> On 11/09/2012 20:18, Terry Pinnell wrote:
    >>>> 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?
    >>>
    >>> 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.

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

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


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

    --
    Terry, East Grinstead, UK
    Terry Pinnell, Sep 12, 2012
    #5
  6. Terry Pinnell

    Martin Brown Guest

    On 11/09/2012 21:42, Terry Pinnell wrote:
    > Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:
    >
    >> On 11/09/2012 20:18, Terry Pinnell wrote:
    >>> 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?

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

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


    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
    Martin Brown, Sep 12, 2012
    #6
  7. Terry Pinnell

    Mayayana Guest

    | 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
    Mayayana, Sep 12, 2012
    #7
  8. Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:

    >On 11/09/2012 21:42, Terry Pinnell wrote:
    >> Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:
    >>
    >>> On 11/09/2012 20:18, Terry Pinnell wrote:
    >>>> 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?
    >>>
    >>> 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.

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

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


    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, East Grinstead, UK
    Terry Pinnell, Sep 12, 2012
    #8
  9. "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!
    >
    >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
    >


    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.

    --
    Terry, East Grinstead, UK
    Terry Pinnell, Sep 12, 2012
    #9
  10. Terry Pinnell

    Mayayana Guest

    | 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 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, Sep 12, 2012
    #10
  11. Terry Pinnell

    Martin Brown Guest

    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
    Martin Brown, Sep 12, 2012
    #11
  12. Terry Pinnell

    Mayayana Guest

    | >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.
    Mayayana, Sep 16, 2012
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Falcon

    Strange taskbar behaviour (notification area)

    Falcon, Aug 17, 2004, in forum: Wireless Networking
    Replies:
    0
    Views:
    712
    Falcon
    Aug 17, 2004
  2. joost68
    Replies:
    5
    Views:
    452
  3. panagiotis

    Blur on thumbnails of Sony DSC-S50 jpg-s

    panagiotis, Dec 26, 2003, in forum: Digital Photography
    Replies:
    0
    Views:
    397
    panagiotis
    Dec 26, 2003
  4. Replies:
    6
    Views:
    601
  5. Replies:
    6
    Views:
    344
Loading...

Share This Page