Float for pixels #44
-
I was playing with the code and found out that |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hi! Indeed, this choice was intentional and is designed to avoid any loss of precision during the conversion operations. For instance if you have a workflow where you resize and image and the corresponding annotation to a smaller size, you will lose precision if you keep the coordinates as integers. This can cause issues if you resize back the image/annotation further down your pipeline. This allows using sub-pixel precision in various operations such as for the computation of the bounding box center, which could result in a non-integer value if the width or height is odd. This can cause issues when using very small bounding boxes of few pixels for instance. Keeping the coordinates in float avoids dealing with the many rounding issues than can occur inside the framework, and this moves the responsibility of the rounding to the end user. If you need integer coordinates, you have to explicitly round the floats using the convention that best suits your needs (down, up, nearest, etc.). |
Beta Was this translation helpful? Give feedback.
Hi!
Indeed, this choice was intentional and is designed to avoid any loss of precision during the conversion operations. For instance if you have a workflow where you resize and image and the corresponding annotation to a smaller size, you will lose precision if you keep the coordinates as integers. This can cause issues if you resize back the image/annotation further down your pipeline.
This allows using sub-pixel precision in various operations such as for the computation of the bounding box center, which could result in a non-integer value if the width or height is odd. This can cause issues when using very small bounding boxes of few pixels for instance.
Keeping the coordinates in flo…