imageRead timeouts

Is anyone else struggling with imageRead (or imageNew) for larger files? This seems to timeout more often than not. I am running latest version of lucee on this server, but I’ve tried it on a few different versions and OS’s and am running into the same issue, though it’s not standard, ie. sometimes a timeout, sometimes not.

I also tested it with one of the uploaded images via https://docs.lucee.org/reference/functions/imageread.html and it errorred 2 out of 3 times (the third it showed the image), so this seems to be standard imageRead problem, not something related to my setup. I used following if you want to replicate.

img = imageRead('https://www.urcie.com/uploads/1/austin-distel-TluMvvrZ57g-unsplash2.jpg') writeDump(img);

Could this be based on the image itself? It seems to start kicking in above 2MB, but not always. Locally it works more often than not, in production it’s the reverse.

Lastly, is there a way to resize an image without then using imageRead/imageNew etc? The files are being uploaded, but I want to return them smaller, so I’m doing a set imgData = imageRead(location), then imageResize(imgData…). If I’m missing a simpler way which skips this step, that would be way preferred of course :slight_smile:

Don’t forget to tell us about your stack!

OS: Ubuntu 20
Java Version: Latest
Tomcat Version: Latest
Lucee Version: Latest

how long does it take to timeout?

there’s probably a built in timeout, otherwise it could hang forever. it might be the timeout for the request, so you could try increasing it by setting requesttimeout=50;

I think imageResize accepts a url as well (i.e. type=any)? https://docs.lucee.org/reference/functions/imageresize.html#argument-image

I have set it to 25s for now, which should be enough? I’ll try expanding that further to 60, though I think I’ve done that in the past without success as well. But will definitely look into the imageResize just accepting a url - that would, I think make matters a lot smoother.

25s should be ample, I can’t see why any image should take so long to load…

if that doesn’t work and you need more control, use cfhttp (that’s what lucee is doing under the hood anyway)

I’ve never used cfimage, because I’ve done image manipulation with imageMagick before there was cfimage around, and I’ve kept that since then. At that time there was a cfx of cfimage around with very limited functionality.

What I can say from my experience with ImageMagick manipulations is, that certain functions would hang with certain images. Of course, that is a shot into the dark because its not cfimage related, but just like then I would try getting a set of different timeouting images and carefully look for similar caracteristics between them with an real image editor. Characteristics such as e.g. them being RGB, transparency, ratio or having additional data embedded. That is what I would look into.

if that’s the case, saving the image locally and reading it from the local file system would be a good test.

From memory, the latest image extension supports CYMK images

I filed a bug some years ago here related to CMYK images I think, which is I think the fix that Zac mentions, and those indeed were fixed. With those I’d get an error though - this just times out and is more arbitrary, with the same image sometimes failing, but other times working.

Uploading images is going to be an important part of what I’m building, so I kind of need it to be robust. Are you happy with ImageMagick or do you still have issues from time to time? I know nothing is going to be perfect here.

BTW, your Ubuntu setup of lucee was gold for me Andreas. I swapped to a fresh DO droplet and just followed that for the most part (had to use x2go for the remote graphical interface from a mac). The only thing I’d probably add somewhere (but this is recent so not a knock on your guide - more something lucee should list as common changes that need making after installing) is that anyone running a newer version of tomcat better update their umask if they want uploaded files (like photos) to be viewable online - that one took me some googling to figure out :slight_smile:

I’ll try this next. Increasing to 60 didn’t help.

can you log another bug with any sample images which fail/hang?

1 Like

Will do. Just realized I got in some errors after increasing to 60s yesterday and doing a test before I had to run. Seems it’s corking the java heap space:

additional Struct (ordered)
Detail string
ErrorCode string 0
Extended_Info string
ExtendedInfo string
Message string Java heap space
StackTrace string lucee.runtime.exp.NativeException: Java heap space Caused by: java.lang.OutOfMemoryError: Java heap space
TagContext Array
type string java.lang.OutOfMemoryError

Form
Scope
fieldnames string file
file string /var/lucee/web-contexts/xxxx/temp/tmp-11.upload

resizing uses a lot of memory, were there perhaps concurrent resize requests?

No, I was the only user on the server, and this was one image. It also wasn’t even at the resize step yet as I have email notifications for each step (to try and track down the problem) and it’s not getting to the step after imageRead.

I’ve also encountered this issue with ACF (slow, memory issues, etc). We’ve also had legitimate iPhone 4 JPG images that were unreadable. Our solution was to switch to GraphicsMagick (also used by Flickr and Etsy.) In order to support HEIC/HEIF (which iPhone/Mac users often accidentally upload), we also use ImageMagick to convert HEIF/C-to-JPG on-the-fly so that we don’t frustrate the end users. I recently started switching some web applications to use Lucee and we plan on continuing to use these 3rd party command-line programs.

Hmm, the heic issue is definitely one that is bound to pop up as I hit that myself all the time when airdropping pics. Any reason you didn’t just use imageMagick the whole way (given graphicsMagick is based on it)? I was reading up on both yesterday and kind of wanted to go with graphicsM since it seems simpler, but imageM has more functionality/options.

We adopted GM in 2015 because “GraphicsMagick is much smaller than ImageMagick and has dramatically fewer dependencies on external libraries.” We wrote a CFTag to support multiple operations that we commonly perform. (NOTE: We were still using ACF9 at the time.)

Regarding HEIF/C support, I couldn’t find anything other than ImageMagick that could convert via the command line. We currently use IM only for HEIC/F conversion and are waiting for either GM to include this functionality or another solution to become available. (I don’t want to rewrite our library just because IM has this single feature before anyone else.)

For many public-side images that require resizing solely for optimization purposes, we’ve started using dedicated servers running ImageProxy and ImageFlow since it seemed a better solution.

1 Like