Computer Vision - send next largest image when full is too big #110
Conversation
| /** | ||
| * Retrieves the URL of the largest version of an attachment image accepted by the ComputerVision service. | ||
| * | ||
| * @param string $full_image The path to the full-sized image source file. |
There was a problem hiding this comment.
please keep these @param descriptions aligned
|
@johnwatkins0 Overall the code looks good here. Testing on a temporary public site however, I never saw images above 4m working. I set the threshold at 50% and small images always worked, large images never worked. Am I missing some step to testing, are you always getting tags for larger images after your PR? Spin up a site and test: http://poopy.life/create?plugins=https://github.com/10up/classifai/zipball/feature/handle-overlarge-images |
|
Thanks, @adamsilverstein . I'll see if I can reproduce the issue you're having. |
|
@adamsilverstein This is fixed now. Seems like I introduced a last-minute bug involving a function parameter. Thanks for testing! Feel free to use this environment if you get to it in the next 22 hours -- it has the latest on this branch: http://adaptable-wren.w6.poopy.life/ I removed my image processing credentials. Tested with 23MB image:
|
|
@johnwatkins0 Thanks for fixing that up, I'll give it another test (this link should install from this branch: http://poopy.life/create?plugins=https://github.com/10up/classifai/zipball/feature/handle-overlarge-images). Looks like some merge conflicts have cropped up, can you take a look at those? |
|
Generally this is working much better. I received some tagging results on both small and large images. Yea! I still see an issue that I think is coming from this PR: when I drag and drop an image to upload it (vs clicking 'Select Image' I regularly see an HTTP error message. Oddly the same image uploads fine with the button select method, or sometimes when dragging and dropping, maybe if other uploads are already in progress? Have you seen this?
|
|
Thanks, @adamsilverstein . I will look into that. |
|
@johnwatkins0 Thanks! once you resolve the merge conflicts I can re-test; the issue may have been fixed elsewhere. |
|
@adamsilverstein I've fixed the merged conflicts. I'm not able to reproduce that issue so far, but I might not be following the right steps. Let me know if you still see it. |
There was a problem hiding this comment.
@johnwatkins0 can you test on this test site link? i still see the issue when dragging and dropping images to upload them: http://poopy.life/create?plugins=https://github.com/10up/classifai/zipball/feature/handle-overlarge-images
|
Steps to reproduce the HTTP error issue:
Note you get an HTTP error:
I see this notice in the logs: also see:
Also testing on my personal site I don't ever see large images getting captioned |
…10up/classifai into feature/handle-overlarge-images
| * | ||
| * @param int Default 4MB. | ||
| */ | ||
| return apply_filters( 'classifai_computervision_max_filesize', 4000000 ); // 4MB default. |
There was a problem hiding this comment.
WordPress has some fun built-in constants for file sizes and time units, like MB_IN_BYTES. Would advise using that here for legibility and technical accuracy.
There was a problem hiding this comment.
Thanks! Didn't know about MB_IN_BYTES. Updated.
This would resolve #101 by providing backup behavior when the full-sized version of an uploaded image is greater than the maximum size accepted by Computer Vision.
Note: This does not intentionally address the "Additional Context" comment on #101 about this update potentially giving time for external image-hosting services to receive the image before the request is sent to Computer Vision. I suggest a separate issue for that. Maybe this work could be done with
wp_schedule_single_eventinstead of in the same pageload as the image upload.Description of the Change
In the
ComputerVisionclass, this adds a method to provide the URL of a newly uploaded attachment's largest acceptable version.In most cases -- assuming most WP users don't routinely upload images greater than 4MB -- we would expect the full-size image to work, in which case this update doesn't substantively change any existing plugin behavior. When an uploaded image is greater than 4MB, however, we make a copy of the image's
sizemetadata, sort the sizes from largest to smallest, and use the first size whose file is less than 4MB.Alternate Designs
A simpler approach would be to rely on the built-in core file sizes ('large', 'medium', etc.), but we don't actually know whether 'large' will be a given site's largest file size below 'full' -- and it is possible to disable core intermediate image sizes entirely -- so this approach uses a simple algorithm to sort images from largest to smallest regardless of how the sizes are named.
Benefits
Within any site that does not have some radically altered way of handling images, Computer Vision will be able to provide data for any uploaded image.
Possible Drawbacks
Calls to the PHP
filesizefunction become expensive when images are hosted externally, so the behavior implemented here should be a fallback and should not run routinely.Verification Process
Using a site that is reachable over the web -- which is required because Computer Vision accesses the images via a public URL -- upload an image that is larger than 4MB. After the upload is complete, the expected image metadata should have been generated.
Checklist:
Applicable Issues
#101