19e6f134f65bb6fa54cab6290ec31862df7ab9ee It seems to be a better solution to do the cropping on the server part. This has the advantage, that the actual code used by the virtual image worker for constructing the virtual image can be checked and aligned correctly.
This is a basic backend implementation for this
d92f35a029317e029200fb0560897558e5fbeb61 frontend shows now some cropped images from desired plant and polygon
9d6c74095d73ec194a06a1ec82d7c96690e6158b offset is not working correctly
618e9fc655d30cc94465a893d9753dcbee58b87f calculating the crops on the server and displaying them is a much easier calculation wise, as the distance between the image border and the polygon to crop are not returned.
Without those distances the scaling cannot be reversed. So just calculate everything on the server and display the results. Is better for error finding anyway
24846727f6e79c9a90dcea8427ed2320038f9fca added checks to ensure that only mats with height and width are actually written to files or used for calculation
a4078e161b499c590cd9d03addf055f61e985d92 the previous approach was not correctly calculating the width and height of the cropped images.
This approach should always work. When no mats exists with a size, a non empty size must be returned for the following calculations. Therefor 10 Pixels are the minimum requirement for height and width
14a0c67d31b30f9646a90f93b5482be9c1866143 Deleting of unnecesssary database column and renaming qr code to position, as the qr code feature is obsolete
792dc5dc3eb4c383470f5108d475e235f1f5c289 displaying the position over the name when showing the plants in the images for a fast way to check correct coordinates
d0df18ed46019236f9bf0557b2c31782ccb5ecc7 minor usability fixes
Commit messages for #147