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 ImageRead() :: Lucee Documentation 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.
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
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 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.
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.
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
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
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.
