Live data from Hacker News

Show HN: bbox-visualizer – Make drawing and labeling bounding boxes easy as cake

github.com

11–20 of 25 posts

Re: Show HN: bbox-visualizer – Make drawing and labeling bounding boxes easy as cake

#11
post #2

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?

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.

Re: Show HN: bbox-visualizer – Make drawing and labeling bounding boxes easy as cake

#12
post #10
post #5

Can someone explain to me why I would need a library to draw bounding boxes with a label? I don't understand why this is a hard problem that warrants a library. There isn't even any 'fiddly math' in there. I seriously don't get it. Have we become so incapable that we can't draw rectangles and labels anymore by our self?

It's not about capability, but efficiency. This seems handy enough for me to adopt into custom labeling tools I wrote using cv2 and PIL, etc.

No doubt that this is handy as a reference. But it's on the frontpage of HN and i don't understand why. If you look at the code it evokes memories of left-pad. Rendering a label and a box is not complicated, this library only serves the creator.

Instead of down votes, I hope someone can answer my questions.

Re: Show HN: bbox-visualizer – Make drawing and labeling bounding boxes easy as cake

#13
post #9
post #7

Earlier quoted context omitted.

Thanks for your thoughtful reply. I guess I have more of a problem with this hitting the front page of HN than with you publishing it. If you use it a lot and abstract it into a library, that's fine, we all do that. But it looks like people are interested in it and I don't understand why. Don't get me wrong, I like that you published it and I encourage it as much as I can. But if someone is capable of running complex…

Same reason I might use tippy.js for popup boxes. I know I could make it myself, and make it just as well as the tippy authors have designed it, but why waste my time doing that when I know they've already thought through all of the problems that I can't even expect until I'm already in the thick of it?

Sure it's not like I haven't used libraries in the 20 years I've been coding. If it solves the complex problem I am facing, I will use it. But have you looked at the code in question? It is not complex. It is code you write in 20 minutes.

Re: Show HN: bbox-visualizer – Make drawing and labeling bounding boxes easy as cake

#14
post #13
post #9

Earlier quoted context omitted.

Same reason I might use tippy.js for popup boxes. I know I could make it myself, and make it just as well as the tippy authors have designed it, but why waste my time doing that when I know they've already thought through all of the problems that I can't even expect until I'm already in the thick of it?

Sure it's not like I haven't used libraries in the 20 years I've been coding. If it solves the complex problem I am facing, I will use it. But have you looked at the code in question? It is not complex. It is code you write in 20 minutes.

[deleted]

Re: Show HN: bbox-visualizer – Make drawing and labeling bounding boxes easy as cake

#15
post #13
post #9

Earlier quoted context omitted.

Same reason I might use tippy.js for popup boxes. I know I could make it myself, and make it just as well as the tippy authors have designed it, but why waste my time doing that when I know they've already thought through all of the problems that I can't even expect until I'm already in the thick of it?

Sure it's not like I haven't used libraries in the 20 years I've been coding. If it solves the complex problem I am facing, I will use it. But have you looked at the code in question? It is not complex. It is code you write in 20 minutes.

I don't understand the hate. I don't have to solve P=NP to post on HN. If I did solve something complicated, I'd be publishing a paper, not posting here. I thought this is something that might help the community. If people are upvoting it, it's because they think it might help them - save 20 minutes if nothing else.

Either way, your comments might be against HN guidelines [1].

[1] https://news.ycombinator.com/showhn.html

Re: Show HN: bbox-visualizer – Make drawing and labeling bounding boxes easy as cake

#17
post #4

Earlier quoted context omitted.

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?

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.

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.

Re: Show HN: bbox-visualizer – Make drawing and labeling bounding boxes easy as cake

#18

Nice one. More useful to me would be something similar that operates on tensors on the GPU. Doing image annotations on host/CPU often becomes a bottleneck.

Interesting idea! I'll have to do some studying as to how to make that happen, so I doubt I'll be adding that option anytime soon but I'll be adding it to the icebox.

Thank you for the comment!

Re: Show HN: bbox-visualizer – Make drawing and labeling bounding boxes easy as cake

#19

Nice one. More useful to me would be something similar that operates on tensors on the GPU. Doing image annotations on host/CPU often becomes a bottleneck.

Out of curiosity, what throughput do you have that would require GPU labelling?

The most resource heavy bit is text rendering I guess, but that could be cached per class-name and reduced to a memcopy. Otherwise drawing rectangles is pretty quick on a CPU to the point where I'd imagine the memory transfer to the GPU is probably comparable to the draw ops?

I've got OpenCV down to around 10ms per image (single thread, python) without the caching idea I mentioned above.

Re: Show HN: bbox-visualizer – Make drawing and labeling bounding boxes easy as cake

#20
post #4

Earlier quoted context omitted.

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?

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.

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.

Post reply on HN