[mrkwse]

Drawing these bounding boxes can be a fiddly thing to get right, and for some it can be troublesome, so this probably will be worthwhile for a group of people.

With that said, the dependency on OpenCV seems entirely overkill. Surely Pillow would be a much more sensible dependency (with ImageDraw), as all you're doing with this package is drawing rectangles and labels, rather than handling any CV tasks?

[joshvm]

I would guess the library uses OpenCV primitives to do things like figure out the size of the label before drawing the background fill underneath. That's normally where the complexity comes in for drawing labels. I'm not sure if you can do that easily with ImageDraw?

For users of this library, OpenCV is pretty likely to already be installed anyway.

Another couple of reasons - OpenCV in my experience handles nonstandard images much better than Pillow (eg many channels, >8 bit). It also has a uniform Python/C++ interface so this could easily be ported if desired. I maintain a C++/Qt desktop annotation app and this would definitely be something to crib from for visualisation. Although in this case image loading could be done somewhere else and the library could just take a Numpy array.

Edit: turns out it's possible with a few extra steps, but it's not trivial. You need to handle ascender/descenders, etc: https://stackoverflow.com/questions/43060479/how-to-get-the-....

OpenCV will tell you the bbox of what it just drew.

[shoumikchow]

Personally, I've always used OpenCV with all object detection and object recognition tasks I've worked on to take advantage of the many CV functions it provides. So it was only natural for me to use OpenCV since it wouldn't require an additional dependency like Pillow.

I could've definitely used Pillow, but is there any tangible advantage to using Pillow over OpenCV?

[3vidence]

Looking over the library quickly, I really like it, that being said, Pillow is a much smaller and more self contained library than OpenCV, some projects try and avoid openCV if not necessary and this would extend to this project as well.

[mrkwse]

Yeah this is the main thing, there are different approaches to computer vision problems than OpenCV, so using a smaller more specific library will make the package more portable and better suited to a wider range of projects.

Having OpenCV as a dependency means that if a project isn't already using OpenCV, this fairly minor (in terms of scale of functionality) utility library has a lot of baggage.

[shoumikchow]

Thanks for the constructive comment! I'll try and see if it is at all possible to implement it in Pillow and maybe re-implement it in a major release, unless it is terribly convoluted.

[mrkwse]

Sorry for my slow response, 3vidence has covered my main thoughts, but I've added a bit to his comment.

In terms of convolution of implementing it, there may be a little more effort in terms of figuring some offsets (e.g., path widths may extend bounds), but it shouldn't be anything excessive I don't think.

[shoumikchow]

Thanks for the comment! I'll look into it and aim for the next major point release.