Author Topic: Bug in image viewer  (Read 49 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: 5059
    • 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: 5059
    • 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.