0.84: Thumbnail of large images are dark

[helmut]

XnView: MP 0.84 - 64-bit
OS: Windows 7 - 64-bit

When browsing a folder with very large images (e.g. 20.000 x 20.000 pixels), the thumbnails of these images are dark in brightness.

Effect: Thumbnails aren't displayed properly

To reproduce:
1. Download the attached PNG images and save them locally
2. Start XnView and browse the folder with the image files
Actual behaviour (bug): XnView builds the thumbnail. Thumbnail do not look the same: The thumbnail of the large image looks dark in brightness and somehow corrupted.

Expected behaviour: XnView builds the thumbnail. Both thumbnails look the same.

Notes:
• If the problem should not occur, try converting the large image to BMP format. If the problem still doesn't occur, resize the large image to 40.000x40.000 pixel with "Resizing: Nearest neighbor" and try, again.
• This problem might be related to following problems:
- 0.84: Problems when navigating over large image files
- 0.84: Resizing to large image fails silently

[CameronD]

Very odd indeed:
It is as if there is a V-shaped or saw-tooth curve mapping - darker to mid colours are OK, but then very pale tones get darker.
Also, there is a one or 2 pixel shift at some stage giving it a raised or depressed button effect edging. (wrong - see later post)
In the main body of the bug every square is OK except the palest.

screenshot showing thumbnail (top) and preview tabs in xnviewMP.

[XnTriq]

for 20000px.png and the following config:

1. Tools → Settings... → Thumbnail → Misc → Create high quality thumbnail is activated
2. Tools → Settings... → Thumbnail → Appearance → Custom thumbnail size is activated and Width/Height < 168 pixels
3. Tools → Settings... → Catalog → Catalog → Enable thumbnail caching is turned off

Additional bug to be reported separately ASAP: Turning off Create high quality thumbnail doesn't work for 4-in-1 thumbs (Show 4 thumbnails in folder's thumbnail (instead of 1)).

[CameronD]

Here's a better example: screenshot and test image.
The edge effect I mentioned above is simply because of the previous enlargement operation combined with the bug. I cannot find any way to make an enlargement that produces an exact reproduction of the image - for an N-times enlargement, photoshop and xnview always want to create an N-pixel boundary that is interpolated from all sides.

The test image has several grey or nearly grey ramps from black to white.
I can reproduce with thumbnails set to zip or jpeg high quality.

The screen shots show that there is a sawtooth greyscale remapping applied. The thumbnails with increasing size images show that the adjustment point changes with the image size.

screenshot of thumbnails and preview

I did another test (not shown here, and by reducing only the width of the image I can see that the sawtooth corresponds to the number of vertical pixels.

18000 pixels high is OK, 19500 is bad, 19000 is bad. (this is misdiagnosis - see later post)

The bad image is attached.

[CameronD]

if Create high quality thumbnail is activated.

BTW: Turning off Create high quality thumbnail doesn't work for 4-in-1 thumbs (Show 4 thumbnails in folder's thumbnail (instead of 1)).

Edit: This is all only misinterpretation of the symptoms - see following post.
I originally wrote:

I confirm that disabling of high quality almost eliminates the bug - the thumbnails for individual images in the browser window are good whether 4-in-1 is chosen or not - only the thumbs in the 4-in-1 are very dark.

Looking at it from another viewpoint - for 1 thumb per folder icon: the thumbnail created inside the folder icon will be bad, no matter what the setting is for Create high quality thumbnail . This applies whether or not a good thumbnail of the representative image has already been created and cached. BUT the thumb in the folder is GOOD if thumbnail caching is disabled.
If I enable high quality AND caching AND 4-in-1 folder icons then the sawtooth mapping that is applied is different from that applied to each individual image! Some large images that generate correct individual thumbs will produce bad thumbs in the 4-in-1 folder.

Alternatively, even with high quality enabled:
disabling caching of thumbnails produces good individual thumbnails;
enabling caching of thumbnails produces the same bad thumbnail, independent of compression storage chosen (even "None").

For each test, I would change cache mode, exit xvniewmp, delete the thumbs.db file and restart xnviewmp.

[CameronD]

More complications:

The same image will produce problems, but if rotated by 90 deg will produce a different image, as shown here:

The top left shows what it should look like (it is an 8-bit greyscale png). Top-right shows that rotating it without changing total pixel numbers triggers the bug.
The bottom row has double the number of vertical and horizontal pixels, and the left one has two step changes in the remap, while the right one has five.

The light creeps in:
Then I changed the thumbnail size - original was 192x144.
If I change it so that the X and Y size is the same, then the bad images are transformed in the same way.

The critical factor seems to be the ratio between image pixel dimension and thumbnail pixel dimension, and the magic number seems to be 128. Once the image needs to be reduced by more than that factor in either direction then it goes bad.

This explains why 4-in-1 and thumbs embedded in folder icons gave weird results: they are reduced by different amounts in each case, although it seem strange that the cached thumbnails are not used as a starting point - it would be much faster.

Also explained is why disabling thumb caching seemed to work - it seems to simply default to initially produce a thumb size determined by the current view. As I later found, a really large image will still produce a bad image with caching disabled. The default is also unequal in X and Y.

[CameronD]

Additional bug to be reported separately ASAP: Turning off Create high quality thumbnail doesn't work for 4-in-1 thumbs (Show 4 thumbnails in folder's thumbnail (instead of 1)).

If my final interpretation is correct, then this is all part of the same bug.

[helmut]

Thank you very much, XnTriq and CameronD for your many tests and detailed description of your observations! Good that you both could reproduce the problem - let's see whether Pierre also can.

Reproduced

[xnview]

This problem is supposed to be fixed in XnView MP 0.87. Please check and confirm the bug fix here.

[CameronD]

Version 0.87 beta 1 - all my test thumbnails now look like they should (after waiting for them all to be rebuilt!).
However, the 4-in-one folder thumbnails still have the problem. This is even if I visit the lower folder first, allow the correct thumbnails to be cached and then visit the folder above. It seems to reprocess the original images to derive the 4-in-one thumb, rather than using available thumbnails, which accounts for the very long time (a few minutes) it takes to create them.

I have deleted cached thumbnails and forced a rebuild just to confirm I was not seeing leftovers from the bugs of the previous version.

[XnTriq]

Version 0.87 beta 1 - all my test thumbnails now look like they should (after waiting for them all to be rebuilt!).

Confirmed

However, the 4-in-one folder thumbnails still have the problem. This is even if I visit the lower folder first, allow the correct thumbnails to be cached and then visit the folder above. It seems to reprocess the original images to derive the 4-in-one thumb, rather than using available thumbnails, which accounts for the very long time (a few minutes) it takes to create them.

Confirmed

Additional bug to be reported separately ASAP: Turning off Create high quality thumbnail doesn't work for 4-in-1 thumbs (Show 4 thumbnails in folder's thumbnail (instead of 1)).