The error message is referring to bytes, not bits.
You’re right.
Ben is, I think, one of the developers, so perhaps he can say if the error log & message are wrong (i.e. it should say bits) or if they really need 256MB memory to handle re-sizing a 20MB JPEG.
If the latter, then there’s a big issue with using Backlight to upload licensable (full size) files.
I saw in the PHP info that ImageMagick is being used and my previous site (using some now unsupported plugins) used that too for watermarking and making smaller versions of uploaded full size images. It was fine with a 128MB memory_limit in that environment
Hi Jo Ann,
I’d like to try to see if I can duplicate this. I assume you’re using Backlight Publisher to upload the images? What are sizes of the images being created? Are you having Backlight create renditions for purchase? What size?
Anything special about the file names of the images that are failing? Do they all use letters, numbers, underscores, or hyphens? No spaces, decimal points, commas or special characters?
Rod, I am using Backlight Publisher and the images which fail are large-ish (12-21 MB JPEGS), but they aren’t the largest images. In other words, many larger ones have worked fine
The file names are letters (mixed case) with hyphens and underscores in many. The only period is in the .jpg extension. As an example (this one worked) MM-buoy line in vivid lake 130819_0038.jpg is typical. There are spaces. I never use other characters to minimize problems with older-style file systems.
To get Backlight to give me the uploaded size for purchase, I’ve said 9999 x 9999 pixels is the size to create and that appears to give me “originals” (I just tried to find where I’d set that, but I couldn’t. I know it’s somewhere, but I’ve no clue whether this is an album, gallery, page, cart or other attribute; you can tell I’m still really struggling with the organization. As an aside, it would be great if one could search the documentation).
You can look at the masters and photos-for-purchase for one album in this screenshot from my FTP software; I think the items for purchase are unchanged from the masters if you look at file sizes
The images for display are 2000 x 1500, in case that matters. If it helps, I can put some of the failing images online so you can use them to debug (assuming it’d fail in all uses, just in my setup)
the 9999x9999 size can be set in the album template in the Cart Add-on under Generate Photos for Purchase.
I’m assuming that the images you’re uploading are at least that large. I don’t really know how Backlight Publisher is resizing images or if it’s capable of enlarging.
Are any of the images you’re uploading smaller than 9999px on the long side?
Thanks for the locator on where to find the purchase size settings.
None of my images are as big (on either edge) as 9999 pixels and given the sizes match the originals, I’m fairly certain that there’s no enlarging going on.
What I want to happen is for the files I upload to be the files for purchase, but there didn’t seem to be any other way to get a “leave this as is” result.
With the exception of the handful of files that fail, I’m able to get what I’m after, even though the interface - specifying the largest possible pixel dimensions - is rather indirect.
Well this is embarrassing. My original calculation was incorrect. That figure is indeed 256MB. I had treated the number as bits, not bytes.
So I started looking at pixel dimensions instead of JPEG file size to see if that might be a reason for the ones that fail. Could that be a factor in why things fail? I have several square images 5616 x 5616 pixels and even when they are 11MB or so, they fail
I just tried to upload a test file - 5616 x 5616 pixels saved at JPEG level 4 (very low) - it was 1.9MB in size. It failed.
Not sure what the threshold is, but I think it’s not file size. Given that nothing is being enlarged to meet the 9999 x 9999 purchase size I specified (in the ones that succeed) I’m still puzzled as to why this might be.
I did two more test files at 5400 x 5400 (failed) and 5000 x 5000 (succeeded)
I really don’t want to downsize my images, so is there a possibility of a fix for this?
The memory requirement is indeed determined by the size in pixels. The resizer reads the JPEG into a single bitmap and uses that single bitmap to generate the resized images.
You said above that your images for display are 2000 x 1500. Do you have any higher images, such as for download or purchase? If that’s the highest then you shouldn’t be losing any visual quality by starting off with renditions smaller than ~5000x.
What version of PHP is your site running? If you’re still on version 5.x then upgrading to the highest available version of 7.x may alleviate some of the memory overhead.
My images available for licensing are all large and I don’t want to change their size; just to create a smaller watermarked display size for the galleries. And then to be able to license the original images as and when a buyer needs one.
If I switch over to Lightroom (not my preference but I have it) can I avoid this issue with difficulties generating the display sizes?
If you read the
give it a try with a test album. See what happens. As long as you don’t have “Master Images” set to Yes in Backlight > Settings > Publisher > Publish Master Renditions from Lightroom, then Lightroom would be generating the renditions rather than Backlight.
Ben,
I’m getting the same error trying to upload full sized images via Backlight Publisher. Out of four images, only one was uploaded. I tried it with a template that had cart renditions created at 9999 x 9999 and and also another album with the same images using template that was creating renditions closer to the actual size of the images, 7360 x 7360.
Each album uploaded only one image, and it was the same image. The only real difference was that one image was cropped to a pano rather than the full 3:2 ratio.
I had no problems publishing the same images using the template with cart renditions set at 9999 x 9999 Lightroom.
Hi @rod_barbee, can you share one of the images that failed? Also, what memory limit are you using?
I’m looking into memory usage, and I’m not getting the same results. A 4032x3024 jpeg causes PHP’s memory usage to increase by 30-40MB. This seems about a third of the memory usage being experienced by Jo Ann when taken the image dimensions into consideration, assuming there’s nothing else gobbling up the memory.
I’ll try to get a picture you tomorrow; I’ve shut things down for the day.
memory_limit is 256M
upload_max_file_size is 64M
Hi @rod_barbee, I have finally got around to trying your sample photo (which is a lovely image!).
It uploads for me without issue, even if I decrease the memory_limit to 32M. I’ve tried both with a photos-for-download size of 9999 and 7000. The former uses an exact copy of the uploaded image while the latter causes PHP to resize the image. Do you have a BL environment setup where this is failing with a memory_limit of 128M?
the php.ini file shows memory_limit at 256M
I’ll test it again once I get a chance
I tried again this morning with two of the images which failed before and they still fail (there’s been one Backlight update since I first experienced this issue).
Checked Backlight’s report on php_info and in Core, memory_limit is 256M
I have a test image that is 5616 x 5616 but saved with high JPEG compression (so it is only 2MB)
I’m sure it’ll work for you, but you’re welcome to try it.
What else could I have done in my site setup or settings that would cause this subset of images to fail?
I tried again too. Still failing uploading those images whether trying to upload singly or as a group.
When trying to upload one at a time, each of them gets to 100% but the circle just keeps on spinning and finally I get the failed upload error
When trying multiples, none of them ever make it to 100% and I get the error.
One observation: when I retry images, the upload progress often jumps quickly to high percentage, like 40% and something like 14MB. I have very slow upload speeds (nominally 0.7 Mbps) so this seems odd, unless some of the previous upload made it and it’s being held someplace??
Just to revisit this old topic: the problem is still there in Backlight 4.1. I thought I’d try it to see, but I sitll get the same error.
For a few images that failed (some that were 5616 x 5616) I made downsized versions at 5k x 5k and they worked fine. I have four examples - three that failed and one that uploaded OK that leave me very puzzled about the source of the problem. It isn’t just the total megapixels - look at the table below
Megapixels Result Dimensions File size
31,539,456 mp - fail 5616 x 5616 15.3MB
41,230,000 mp - fail 10000 x 4123 18.4MB
33,768,000 mp - succeeded 11256 × 3000 22.9MB
29,662,794 mp - fail 7281 x 4074 15.8MB