The annotation dashboard makes it easy to label and work with images but the one feature I think is missing is the ability to crop images. I was struggling with how to deal with wide aspect images being preprocessed to square images (Resizing large ~16:9 (2688x1520) images for use with yolov5? - #2 by trevorhlynn). I didn’t like any of the preprocessing solutions (universal center crop or padding) and ended up cropping them all square in the windows Photos app to ensure my objects didn’t get cropped…which wasn’t terrible, but it would be so much easier as part the Annotating process.
Preferably a crop function would default to a square or stay square while holding the shift key like Photoshop. If cropping isn’t feasible/desirable, another idea would be a “crop-bounding box tool” that would designate which (square) part of the image to crop/use while generating a dataset. That would ensure the aspect ratio and proportions (size of the object to the scene) stay correct.
I’d recommend the resize with “Stretch To” option. You probably shouldn’t apply a manual crop because you won’t be able to replicate that at runtime so you’re teaching your model that images are well-cropped when in fact they won’t be in the real world. This will likely degrade its performance.
I updated my original post with some more information because I realize a feature request thread is not the place to be discussing these details.
But just quickly, I’m not talking about manually creating “well-cropped” images…just being able to crop the longer dimension off a 16:9 image so that when I do use the “Resize: Stretch to 640x640” the model is trained on an image with a correct aspect ratio. I want to keep the same “deer-size-to-full-scene” proportions because that sized video is what I’m going to be using at runtime.
Unless I would be safe using a Resize: Stretch to 640x360? I was just following the ultralytics tutorial for a yolov5 model that recommends using the strech to 640x640 option. And manually cropping each of those in photoshop is a time consuming process, much less than adding bounding boxes and labeling on roboflow lol. I just figured a crop feature there (or again a different bounding-box-crop-tool similar to the photoshop example above) would be much faster in roboflow.
I had a nice little reply that I tried to add a link to my original post to and next thing I know the bot flagged it as spam, and I guess it hasn’t been approved yet…Anyway, I’ll try to recreate it.
But just quickly, using a crop feature I’m not really looking to create “well-cropped” images for a model to train on. I just want to fix the dimensions so that when it is “Resized: Strech to 640x640,” it doesn’t screw up the aspect ratio of the labeled items. i.e. (This is what I would crop in Photoshop):
I wouldn’t consider that “well-cropped,” at least not zoomed in or anything. I don’t want to screw up the “deer-size-to-apple tree” proportions that my model will be checking at runtime, but if the model is trained on that 16:9 image squished to a 640x640 square, the model is going to be looking for squished deer, correct?
Lastly, I’m using “Resized: Strech to 640x640” because that’s what the ultralytics tutorial suggests, but maybe I’d be safe using a Strech to 640x360 instead (to keep the 16:9 aspect ratio)?
I also had this problem and wrote a script to automatically crop my images while preserving the maximum amount of the labeled object area (i.e. it calculates the best possible crop).
This is probably not a great idea to do, because you cannot replicate this process at inference time (because you won’t have the labels). That means that you will be deploying your model on a different distribution of data than you train/test on, which is a big no-no for performance
My live production camera is 800x600 and most of my training data comes from a camera that is 1920x1080. So I won’t be cropping at inference time; I’m only cropping the training images (down to an 8x6 ratio). Ideally I would have used the same camera for both training + inference, but I realized too late that my camera’s latency was too high for my use case.
If it’s best to just let it train on a different resolution, please let us know! That would be even easier
