Author Topic: Bug in image viewer  (Read 65 times)

nietrupek

  • Junior Member
  • **
  • Posts: 23
    • View Profile
Bug in image viewer
« on: September 30, 2026, 15:08:56 »
Attached I send an example of JPEG image which is not shown in viewer (F3), but EXIF info is read (at least partially).
Gimp shows more image info and displays this image properly.
Newest MC version: 16.6, build 3221.

Mathias (Author)

  • Administrator
  • VIP Member
  • *****
  • Posts: 5061
    • View Profile
    • Multi Commander
Re: Bug in image viewer
« Reply #1 on: September 30, 2026, 18:07:32 »
MC do not decode jpg it self.. MC is using WIC  (Windows Imaging Component) So I don't know if there is anything I can do about it.

According to an AI analyze of the image
"The problem is its EXIF block (APP1, 2005 bytes). It contains a small thumbnail, and the thumbnail's Compression tag (0x0103) is written with type LONG instead of SHORT, which the EXIF spec requires."

Mathias (Author)

  • Administrator
  • VIP Member
  • *****
  • Posts: 5061
    • View Profile
    • Multi Commander
Re: Bug in image viewer
« Reply #2 on: Yesterday at 06:20:36 »
Might be able to add a workaround for it.. If It fails because of metadata.. It might be able to read file into memory.. strip metadata.. and then load the image.

nietrupek

  • Junior Member
  • **
  • Posts: 23
    • View Profile
Re: Bug in image viewer
« Reply #3 on: Today at 00:19:34 »
MC do not decode jpg it self.. MC is using WIC  (Windows Imaging Component) So I don't know if there is anything I can do about it.

So we can exclude MC itself. Problem lies either in WIC or in malformed file.

According to an AI analyze of the image
"The problem is its EXIF block (APP1, 2005 bytes). It contains a small thumbnail, and the thumbnail's Compression tag (0x0103) is written with type LONG instead of SHORT, which the EXIF spec requires."

Could you provide source of this information? I cannot reproduce it. There's no *long int* representation of 0x103 value in this file.

The command:
C:> hexdump -x plomyki.jpg

shows file content as 16-bits (short int) values. There are some "0103" values there, but no one has enough zeroes in their neighbourhood to form long int of this value.

As there may be not aligned longs in file, I also checked output of command:
C:> hexdump -X plomyki.jpg

This dumps file as bytes (2 hex digits, separated with double spaces). Searching for "03  01" sequences shows some results but again - there is not enough 00 bytes after them to form long int.

Besides, no software I have displays warning about malformed file. For example:
C:>exiftool -Compression -H plomyki.jpg

simply shows:
0x0103 Compression                     : JPEG (old-style)

without any warning about spec violation.

As this is my HI (Human Intelligence) analysis, I might have overlooked something. I am not JPEG expert.




Mathias (Author)

  • Administrator
  • VIP Member
  • *****
  • Posts: 5061
    • View Profile
    • Multi Commander
Re: Bug in image viewer
« Reply #4 on: Today at 07:04:43 »
WIC return WINCODEC_ERR_PROPERTYUNEXPECTEDTYPE when it tried to load the file.
Since it is not my code I can't dig down to exactly what,  AI also said it had bad metadata. and then I did not tell it what WIC also said that. so both of them say that.
I don't care exactly what in meta data is bad. It does not matter for me. It is not my code so I can't modify it anyway.
The code is part of Windows, All MC do is to use API calls provided by Windows. So if it is a bug in the loader. Then It is in Microsoft code. And I don't have access to that.

However, What I might be able to do is it add a fallback load method that will try to load the image without the metadata.


Told AI to analyze it again.. and to show where the error is, And it wrote script to validate it and gave this result
----------------------------------------------------
JPEG segments:
  FFE0 at 2 len 16 b'JFIF\x00\x01\x01\x01\x00H\x00H'
  FFFE at 20 len 63 b'CREATOR: gd-'
  FFE1 at 85 len 2005 b'Exif\x00\x00II*\x00\x08\x00'
  FFDB at 2092 len 67 b'\x00\x06\x04\x05\x06\x05\x04\x06\x06\x05\x06\x07'
  FFDB at 2161 len 67 b'\x01\x07\x07\x07\n\x08\n\x13\n\n\x13('
  FFC0 at 2230 len 17 b'\x08\x02\xbc\x01\xd3\x03\x01"\x00\x02\x11\x01'
  FFC4 at 2249 len 31 b'\x00\x00\x01\x05\x01\x01\x01\x01\x01\x01\x00\x00'
  FFC4 at 2282 len 181 b'\x10\x00\x02\x01\x03\x03\x02\x04\x03\x05\x05\x04'
  FFC4 at 2465 len 31 b'\x01\x00\x03\x01\x01\x01\x01\x01\x01\x01\x01\x01'
  FFC4 at 2498 len 181 b'\x11\x00\x02\x01\x02\x04\x04\x03\x04\x07\x05\x04'
  SOS at 2681

TIFF header b'II' magic 42

[IFD0] at offset 8, 2 entries
  0x0132 DateTime                     ASCII     count=20    @38      b'2012:03:07 10:23:20\x00'
  0x8769 ExifIFDPointer               LONG      count=1     inline   (58,)

[ExifIFD] at offset 58, 0 entries

[IFD1 (thumbnail)] at offset 64, 3 entries
  0x0103 Compression                  LONG      count=1     inline   (6,) <-- WRONG TYPE, expected SHORT
  0x0201 JPEGInterchangeFormat        LONG      count=1     inline   (106,)
  0x0202 JPEGInterchangeFormatLength  LONG      count=1     inline   (1891,)

PROBLEMS:
  IFD1 (thumbnail) tag 0x0103 Compression: LONG count=1 <-- WRONG TYPE, expected SHORT

parsed the file's EXIF data with a script. One thing is actually wrong: the thumbnail's Compression tag is stored with the wrong data type.

The file is small (14,665 bytes, 700×467). It was saved by PHP's GD library (the comment says CREATOR: gd-jpeg), with a short EXIF block added afterwards
┌───────────────────┬────────────────────────────────────┬─────────────────┬──────────────────────────────────────────────────────┐
│       Block       │                Tag                 │    Stored as    │                        Status                        │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD0 (main image) │ DateTime = 2012:03:07 10:23:20     │ ASCII, 20 chars │ OK                                                   │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD0              │ ExifIFDPointer → offset 58         │ LONG            │ OK                                                   │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ Exif IFD          │ (0 entries)                        │ —               │ Empty but parses fine                                │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD1 (thumbnail)  │ Compression = 6 (JPEG)             │ LONG            │ ❌ The EXIF/TIFF spec requires SHORT                 │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD1              │ JPEGInterchangeFormat = 106        │ LONG            │ OK                                                   │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD1              │ JPEGInterchangeFormatLength = 1891 │ LONG            │ OK; the thumbnail fits exactly inside the EXIF block │
└───────────────────┴────────────────────────────────────┴─────────────────┴──────────────────────────────────────────────────────┘

The value itself (6 = JPEG) is correct; only the type is wrong. Lenient readers like libexif, exiftool and browsers just read the number. WIC checks the type against its schema and returns WINCODEC_ERR_PROPERTYUNEXPECTEDTYPE.

The rest of the file is fine: the JPEG structure, quantization and Huffman tables, and frame header are all valid.
----------------------------------------------------

and looking at http://www.fifi.org/doc/jhead/exif-e.html#IFD1Tags for spec

0x0103   Compression   unsigned short   1   Shows compression method. '1' means no compression, '6' means JPEG compression.
« Last Edit: Today at 08:09:58 by Mathias (Author) »