Feed coordinates into an image crop box vs. UX approach to setting crop box size and location

Hi all - Wondering if someone out there can help! Here goes:

I need a cropping tool to work “behind the scenes” instead of having an end user manually drag their mouse to set the crop box size and location. Specifically, I want to feed the cropping tool with coordinates of the crop box (i.e., width and height of box, as well as X and Y location) to set the size and location of the to-be-cropped image.

Any ideas? Thank you for your time reading this either way!

I’m not sure if you want to actually crop the imagine (reprocess), or just change the frame fit of the Image?

The refitting should be pretty easy in CSS, no?

Reprocessing sounds like a job for OpenCV in Python. I would ask ChatGPT to write it for FastAPI (REST library) and host it somewhere as an API. It should be 30 lines max

As a sidenote, i know a few out of the box APIs that would do the cropping part, but not with a XY center coordinate.

Basically when the user uploads a picture, and see the crop-box, they can only crop it down to a min amount and that there is a default crop sizing setup? That what you want?

Much appreciated feedback @davidrasner5 ! It is indeed the reprocessing I’m after. The OpenCV approach seems a little daunting (to be honest) but I’ll certainly give it a shot.

Re: the out of the box APIs/plugins, I’ve looked at almost all of them (i.e., the results of a plugin store search using the term “crop”) but can’t seem to find one that allows you to dictate where to crop outside of the user interface approach.

If anyone knows of a plugin that can do this, I am all ears! In the meantime, I’ll look into the OpenCV suggestion.


Hi @GH5T - thanks for your reply!

To answer your question: yes and no - I would like not only to tell the cropping tool (or Bubble or plugin or code etc.) the size of crop box, but also the specific location on the original image being cropped (e.g., input values for the following fictitious parameters Crop Box Height: [ ], Crop Box Width: [ ], Crop Box X Coordinate: [ ], Crop Box Y Coordinate: [ ]). I’ll be cropping images in bulk and will be getting the input values for these four parameters from another API setup in my app.

Any ideas?

We have commercial plugin with crop functionality as one of its actions.
Please see this post to find out more details: [NEW PLUGIN] Codium Image
It uses offset instead of coordinates with a bit different semantics, but if it generally is a kind of what you need, please let me know, I can provide more details or specific examples for your use case.

Sorry, just read this. The plugin operates on client-side, so this probably isn’t what you’re looking for. Your option should be some API like uploadcare, I think.

hi @vladimir.pak thank you very much! I am going to check it out nonetheless. I think I could make it work. I’ll report back.

1 Like

Thanks, Anthony!
This is new plugin, so we are open to add some functionality if needed, feel free to request it if you find it useful.

hi @vladimir.pak ! Your plugin is excellent - solved my issue. Now, on to my 2 new issues/questions:

(1) Can your plugin directly pull in the pixel width and height of the Original Image (using your lingo from your plugins documentation)? Currently, I’m using another plugin in to pull the image’s metadata but would love it if your plugin could do this so I can keep things all in one place.

(2) If possible, how would I save the Virtually Cropped Source to an existing element in my database with preset dimensions (i.e., XXX pixels by YYY pixels)?

Thanks again!

Hi, @anthony6!

If I understand your needs correctly, these values are available in Natural Width and Natural Height states of Codium Image element after Image is loaded (i.e. when either Loaded event is fired or Loaded state is yes). These are width and height of the image in pixels as it would not be virtually cropped. You can address them like Codium Image A's Natural Width. These values are valid for the current Source field value (or autobound value). I.e. if you uploaded physically cropped image and then set Source to its URL, then you will get a size of cropped image as it becomes new “original” in this case.

I’m not sure what do you mean under “Virtually Cropped Source” in this particular context. In the documentation this term refers a part of the image that user can see when dragging or zooming it inside the viewport.

  • Do you mean you want to save coordinates and size of a Virtual Cropping Region? But this is what you specify in Virtual Crop * fields, so just save these values…
  • Or you want to get coordinates of a currently visible part of the image, which might be less than Virtual Crop Width/Height? In this case use Viewport * states, e.g. Codium Image A's Viewport Width will give you width in pixels of an image area that is currently visible to the user.

P.S. just to make it clear: the original image is clipped twice before it becomes visible to the user:

  1. First it’s clipped to Virtual Crop Left/Right/Width/Height region so that user never sees what’s outside of that region when panning or zooming. But this region can still be larger than Codium Image element’s viewport.
  2. And if it is larger than the viewport, it’s then clipped again by the viewport bounds. But in this case user can be enabled to pan through Virtual Cropped Region if corresponding settings allow it (such as Move Active, Zoom Active, Single Click Action, Double Click Action or Wheel Action).
    Viewport Left/Top/Width/Height states provide coordinates of the region in the original image canvas so that if you feed them to Crop or Upload action, you will get exactly the part of the image that user currently sees in the viewport.

And yet another thing I’m emphasizing in documentation: when you set Virtual Crop * settings, the image is cropped virtually, meaning that it is not cropped physically. That particularly means that:

  • User still can have access to the full image by right clicking or by inspecting DOM tree in dev console (F12 key in chrome, edge, firefox, don’t remember, but most probably in opera too);
  • The full image is still loaded, i.e. virtual cropping does not reduce the amount of bytes browser downloads to show an image.

hi @vladimir.pak !

Re: #1, this nailed it (i.e., simply referencing Codium Image A’s Natural Width). Thank you very much!

Re: #2, First, the depth of your plugin is quite impressive and I can already think of a few more use cases that would be helpful to my app based on the information you provided above. Second, I think I confused you with my question though! Sorry about that. Here’s another go at it, hopefully this time in a more straightforward way:

I simply would like to save the “virtually cropped” image as a new image in my Bubble database - in other words, I do not want to keep the cropped out parts of the original image but rather just keep the newly created image made via cropping. Additionally, instead of saving this cropped image using the dimensions that I fed into the Virtual Crop height/width/top/left, I want to stretch the cropped image to match a preset XXX by YYY pixel image size (this is for front end aesthetic reasons).

Any thoughts here?

Thank you!

Hi, Anthony!

Suppose, you have an image of 800x600 pixels that you want to physically crop to 400x300 centered.

There are two options:

  • You can reupload it using Upload action with the new cropping region set in Crop Left/Top/Width/Height fields.

  • Or you can generate data URL to save it directly into DB using Crop action. This is not recommended but can be achieved.

Both actions are currently asynchronous. If you don’t use autobinding feature of the Codium Image element, you need to manually update database thing in Codium Image A Uploaded (for Upload action) or Codium Image A Data Ready (for Crop action) event workflow. I’m going to add an option to wait for result to Upload and Crop actions, so you won’t need to split the whole process into two different workflows, it’s coming this week.

P.S. Update has been published. Both Crop and Upload actions now have “Wait for Result” option that is checked by default. If this is the case, a workflow is paused until an action completes to ensure that resulting data (Data * fields or Upload URL) are ready when workflow proceeds to next action. The only problem is that bubble doesn’t guarantee the order workflow actions are executed. As Make changes to Thing is a server-side action, you will still need to use the trick to isolate it to invoke it after upload/crop action fully completes (see following screenshot). For client-side actions this is not necessary.

1 Like

hi @vladimir.pak - very very helpful. I am curious: would the “Attach to” field in the “Upload CodiumImage” action be of any use here? Could I just set that to the “thing” (in my case, a ‘Product’s Main Image’) in my database I want to set with the Upload URL?

Hi, Anthony!

Yeap, that’s what this field is intended for.
A couple of things to mention:

  • Documentation is a bit misleading, I updated it. I didn’t find a way to get autobound thing automatically using Bubble Plugin API. The part about autobinding is not correct, you cannot leave this field empty if Make Private is checked.
  • When you make an image private, user won’t be able to crop that image second time after upload, because AWS does not provide correct Access-Control-Allow-Origin header (that was not the case 2 months ago, I’m investigating which side has been updated - either chrome on desktop became more restrictive or AWS S3 stopped providing correct header), and CORS proxy is unable to get that image as it is now protected.

The problem

The problem has been resolved, now it is safe to check Make Private providing Attach To thing. Once you do that, the image is subject to privacy policy rules of the thing it is attached to the same way as for built-in file and picture uploader as described here: https://manual.bubble.io/help-guides/data/files

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.