large png image fails to open [BUG]

[cverb]

Xviewer 1.2.2, on Linuxmint 18.1. Opening a large (13264 x 10119), all-white png image fails, showing only a pure black image. Interestingly, if the image is cropped to either 13263x10119 or to 13264x10118 it opens fine. This is not related to file size, (image is only about 412kB), as much larger images, png or jpg load. Local disk or remote share makes no difference.

I narrowed it down to that exact image size by incrementally cropping and blanking an image in gimp, determining that image content was irrelevant (pure white worked), file size was irrelevant (a 30MB file of slightly smaller dimensions displays fine), and the threshold for failing was that exact image size. Note that prior to upgrading from linuxmint 17.3 to 18.1, the default image displayer (eog I think) did not have this problem.

Steps to reproduce:

1. Open gimp, create a new, blank (all-white) image of 13264 x 10119.
2. Export image as png.
3. Attempt to load in xviewer. Xviewer loads slowly (expected), but then shows a pure-black image. As well, the 2nd row of GUI buttons are missing icons (although when clicking on them they seem to be actually working, even if the image is not being displayed).

[cverb]

Note that a jpg image of the same dimensions fails too, although in that case the GUI icons still show up. Also, suspiciously, the total failing image dimensions at 32 bits/pixel, requires 33 bits to represent, while the dimensions that are 1-pixel smaller in width or height, at 32 bits/pixel still multiply out to a value that fits in (unsigned) 32 bits.

[josesac]

I have the same problem with some panoramas above 15MB with xviewer 1.2.2. Gthumb is able to open it but then is not able to save the modifications, it crashes as xviewer sometimes when saving or when I try to crop it. Tried with Pix and have the same problem displaying them... it crashes. The jpg images are 4521 × 10359 (20MB) or 15000 x 3800 (17MB). Gimp is working fine with them. I am using Mint 18.1 64bit

[dansk]

I'm having the same issue as described above.

[tomay3000]

Has it been solved? because I have the same problem with Pix

[danielleedeveloper]

Me too.

[programmer-ceds]

Linux Mint 20 xviewer 2.8.1 pix 2.4.11

Both xviewer and pix open jpg and png plain white images of 13264x10119 successfully for me (not horrendously slowly but not what you would call fast!)

[rmast]

Xviewer 2.8.3 on Mint 20 makes nothing of a 10570x14702 png with 8 colors. It also breaks in the same way on a PPM from this PNG. Pix 2.6.3 does however show it right.

[programmer-ceds]

Does it still fail with V3.0.2?

Can you post the file that you are having problems with (or a link to it)?

[rmast]

Unfortunately there is a very high libxapp dependency:

sudo dpkg -i packages/xviewer_3.0.2_amd64.deb Uitpakken van .../xviewer_3.0.2_amd64.deb wordt voorbereid... Bezig met uitpakken van xviewer (3.0.2) over (2.8.3+ulyssa) ... dpkg: vereistenproblemen verhinderen de configuratie van xviewer: xviewer is afhankelijk van libxapp1 (>= 2.2.1); maar: Versie van libxapp1:amd64 op dit systeem is 2.0.7+ulyssa.

Even newer Ubuntu versions don't have this high version: https://pkgs.org/download/libxapp1

Only OpenSuse Tumbleweed seems to have such a high version, 2.2.3.

[programmer-ceds]

xviewer 3.0.2 runs on Mint 20.2.

Can you post an image (or a link to the image) that causes the problem so that I can see if it still fails with the current version?

[rmast]

I was able to update to 20.2, and that automatically contains xviewer 3.0.2-uma. However it still has issues with the picture. I don't want to put the picture on a public forum. Can I mail it to you?

[programmer-ceds]

I can't see a way to PM you my email address. Apart from that it would be better if you could post a simple image that has the problem then you might get someone else to look at the problem as well. Could you create a new image, bucket fill with one of the colours and then just put one (small) area each of the other 7 colours - or is the problem specific to one particular image?

[rmast]

210913 nog 2-000ga.png.gz I removed some private data and the picture now seems to load correct. However, when rolling the mousewheel the issue is shown: Only two little horizontal lines remain. I previously also saw such lines in the menubar-buttons.

The image should look like this, and does so with nomacs or pix:

[programmer-ceds]

When I load your file with xviewer all I see is a small line near the top of the image - so I can reproduce the problem and will take a look at it (can't promise that I can fix it though).

The file opens correctly, as you say, with pix and also with GIMP.

Update: If I open the file when xviewer is maximized then I see what is basically a white image (after a brief flash of the image as it should be). If I set xviewer un-maximized then, like you, I see the image as it should be until the mouse is moved - so I can reproduce what you describe.

Given that xviewer can display the image correctly it should be possible to stop it messing up when the mouse is moved or the image is zoomed in or out. I will try to track down the problem.

[programmer-ceds]

I have a solution for this later problem posted by rmast but it means a change to file xviewer-scroll-view.c and that file is one of the ones changed in PR #143 (which is currently open) and I'm not sure what happens if I create another branch from my master version that modifies a file that is included in the first branch. If this is a problem then this fix will have to wait until the outstanding PR has been merged or rejected.

The change is that in xviewer-scroll-view.c/display_draw() there is a statement that sets interp_type to CAIRO_FILTER_BILINEAR. The comment says that this was changed from CAIRO_FILTER_GOOD as CAIRO_FILTER_GOOD is too slow during zoom changes.

With CAIRO_FILTER_BILATERAL larger images, such as the one posted by rmast are not displayed correctly (I just get the image shown as white). This applies not just to png files but also jpg, bmp and tiff files (at least).

Changing the code to use CAIRO_FILTER_GOOD causes the image posted by rmast to display correctly in maximized and un-maximized windows and it will zoom. The display of the image is not fast but then it is large.

With regard to timing I timed as best I could with a stopwatch the zooming of a Nikon D3200 jpg image (6016 x 4000 pixels) from 2% zoom to 2000% zoom and vice versa (by holding down the + or - key and watching the displayed percentage at the bottom of the window). Both directions took around 5.41 seconds with CAIRO_FILTER_BILATERAL and around 5.2 seconds with CAIRO_FILTER_GOOD - so not a lot in it but it does look as though the GOOD filter is, if anything, the faster of the two.

Whilst pix displays the posted image successfully it doesn't appear, from my looking at the source code, to use CAIRO_FILTER_BILATERAL for image viewing.

[rmast]

I see clefebvre has made this commit on that subject of choice between GOOD and BILINEAR: https://github.com/linuxmint/xviewer/commit/0cfc41a6fa2576a01337f2080ee4ab82c005bfd3#diff-cdf148dd8620f372f87846c2c1bdfb9af25bb1336170c15f129b5114e96e7f9d

[programmer-ceds]

I have just tried zooming the rmast image form 2 to 2000% and vice versa. The times for the CAIRO_FILTER_GOOD are around 0.5 seconds faster than the times for CAIRO_FILTER_BILINEAR (although only plain white images are displayed when using the BILINEAR filter). So CAIRO_FILTER_GOOD is faster and displays the image correctly.

(Note that with the V3.0.2 release code the filter is set to BILINEAR and then GOOD each time the image is zoomed a step the call of cairo_paint() when the GOOD filter is selected still results in a white screen - it looks like something that the BILINEAR filter is doing messes up cairo.)

[rmast]

The bleed of the issue through other pictures suggests the biliniar filter doesn't respect allocated memory boundaries.