feh fails for massive images

[dayne]

At first I thought this was a single-band TIFF image problem but when I starting playing with resizing things I noticed feh becoming happy.. so I started twiddling until I was right between the edge of failing and working:

By massive I mean the original image is: 30691x30661

Playing with resizing to various gets me:
23325x23302 fails (76%)
23018x22995 good (75%)

Next phase was to make sure it wasn't just the TIFF libraries.. so converted the TIFFs to PNG
tifftopnm | pnmtopng >

Same behavior - the 76 fails, 75 works. Trying one more time this time converting to JPG for a last sanity check.

Feh blows up with No Imlib2 loader for that file format on the 76 but the 75 works. Gimp opens both images (in any of the formats) fine (considering the size of the images). XV opens all sizes fine.

I can't distribute the raw (source TIFF) imagery (licensing issue) but I can provide the JPG and PNG files for others to confirm the behavior.

http://beef.gina.alaska.edu/pub/feh-testing/

I put the 75 and 76 as PNG and JPG there along with the original as a PNG.

Running feh 1.9-21-gbeecfaf from github on a FC13 x86_64 machine.

[derf]

Looks like the limit is caused by hardware-dependent maximums, at least none of your images work on my 32bit machine. I can't even convert(1) them to a smaller version without invoking the OOM killer. :>

Anyways, I'm not sure if this issue should be addressed to feh or Imlib2, but I'll investigate it some more some time. Thanks for reporting!

[livibetter]

I tracked down why it fails at least for the bigger one, because Imlib2 (1.4.4) has image size limitation.

in load() of loader_jpeg.c

    if (!IMAGE_DIMENSIONS_OK(w, h))

and in image.h

# define IMAGE_DIMENSIONS_OK(w, h) \
   ( ((w) > 0) && ((h) > 0) && \
     ((unsigned long long)(w) * (unsigned long long)(h) <= (1ULL << 29) - 1) )

#endif

and

>>> (1 << 29) - 1
536870911
>>> 23018 * 22995                                                                                                      
529298910
>>> 23325 * 23302                                                                                                      
543519150

I got IMLIB_LOAD_ERROR_UNKNOWN for BOTH files (on x86_64), if imlib2 had IMLIB_LOAD_ERROR_IMAGE_TOO_BIG, then I didn't need to get into the code. No idea why the smaller one fails.

[livibetter]

I know why the good one failed on my computer, it's because I don't have enough free memory. (why I didn't notice the number is 536,870,911?) I guess imlib2 will see if there is enough memory to use or it just allocates and see if it can gets memory. I only have 2GB, even I closed all programs I could, but it was still not enough. So I turn on swap, nearly 3GB was used and feh showed the image.

As stated in my previous comment, there is a limitation and there is nothing feh can do. Actually, feh has nothing to do with the loading failure.

I don't know if you can just lift that limit in imlib2 to get image loaded, anyway, this should be reported to imlib2 if you want this to be fixed.

[rcbarnes]

I actually get feh crashes with images 1920(w) by <8k(h). I don't know if this is related, but if not, I'm happy to open a new bug and provide some example images...

[dayne]

Noticed this issue still open - looped back and tested against latest feh against the same images as before. Problem has been solved at some point. Used the system installed feh on an Ubuntu 16.04 system

Closing!