[Kwiver-users] Bounding Box Issues

[Paul Tunison]

On Mon, Mar 11, 2019 at 10:27 AM Arslan Basharat via Kwiver-users <
kwiver-users at public.kitware.com> wrote:

> intersection() could throw a warning that one of the boxes is empty, but
> it should still return 0 intersection area, I would think.
>
> Is there a reason to utilize bounding_box class to also support boxes that
> are not axis aligned, which is all Eigen::AlignBox supports?
>

Good point.  We've had issues before with prematurely locking things to
integers (may have been bounding boxes in vidtk, actually, maybe something
else like image coordinates?).  Unless the purpose of the bounding box
concept in this case is a purposeful optimization we may want to have
floating-point bounding boxes otherwise stacked transformations will also
have stacked integer-casting errors.


>
> -Arslan
>
> On Mon, Mar 11, 2019 at 10:19 AM Matt Brown via Kwiver-users <
> kwiver-users at public.kitware.com> wrote:
>
>> It sounds like maybe we need to check "isEmpty()" on the box before
>>> computing the area, and return 0 for empty boxes.
>>>
>> Yeah, I was thinking that would be part of the solution, but every aspect
>> of the bounding box (e.g., top-left/bottom-right coordinates) is invalid
>> when it is empty. When empty, AlignBox still populates those elements but
>> with undefined values, and these get passed on to the Vital bounding_box,
>> allowing the user to query lower_right() and receive undefined values. So,
>> we should either define an empty bounding box subclass, perhaps that
>> returns an error when you ask for lower_right() and forces the programmer
>> to first check isEmpty(), or the intersection function should return a
>> special value when there is no intersection.
>>
>>
>>> By the way, I'm not a fan of having this bounding box class in KWIVER
>>> that simply wraps Eigen::AlignBox, but only exposes a subset of its
>>> functions.  I think we should just use Eigen::AlignBox and possibly some
>>> typedefs for it if we want to call it "bounding_box".  Or we could derive a
>>> subclass if we need to add some additional methods.  There is no reason to
>>> hide all the other functionality of AlignBox.  This is a separate
>>> discussion to have some time.
>>>
>> Yes, I see your point. Would like to have this discussion some time in
>> the near future.
>>
>> Best,
>> Matt
>> _______________________________________________
>> Kwiver-users mailing list
>> Kwiver-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/kwiver-users
>>
> _______________________________________________
> Kwiver-users mailing list
> Kwiver-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/kwiver-users
>


-- 
Paul Tunison
Senior R&D Engineer, Computer Vision
Kitware, Inc.
1712 Route 9, Suite 300
Clifton Park, NY 12065 USA

Phone: (518) 371-3971 Ext.1164
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/kwiver-users/attachments/20190311/789c158d/attachment-0001.html>