[Kwiver-users] Bounding Box Issues

[Matt Brown]

>
> I'm not sure what you mean by "properly encodes empty".  The box does
> encode empty by having at least one max point less then its min point.
> There is a function isEmpty() that checks if a box is empty.  I've used
> bound box classes in several libraries that all work this way.  It is the
> user's responsibility to check if a box is empty (call isEmpty()) before
> doing any operations that require a valid box.  I'm not sure there is a
> better approach here, except maybe that the area/volume of an empty box
> should return 0.
>

Ok, I suppose that makes sense. I'd say we should at least:

   - Return zero for area/volume of an empty box.
   - Add sufficient documentation to bounding_box to make it clear that
   inverting upper/left and lower/right represents "empty" because that wasn't
   particularly clear to me at the start.
   - Add an is_empty method to bounding_box because it is more efficient to
   set this at creation versus having someone explicitly check the different
   combos of min > max.

Optionally,

   - Does it also make sense to raise an error if you try to access
   upper_left() or lower_right() for an empty box as I can't think of a use
   case where you would want to know what that values are there other than to
   check is_empty().

If someone wants to warp bounding boxes to another coordinate system that
may have the axes inverted, do we assume it is the implementer's
responsibility to know that inverting an axis will make the bounding box
represent empty?

Best,
Matt


>
>
> On Mon, Mar 11, 2019 at 10:46 AM Matt Brown <matt.brown at 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.
>>>
>> The issue is, intersection() returns a bounding box, not an area. So
>> there isn't a clear ideal way to return a bounding box that properly
>> encodes "empty." Right now, it returns a bounding box with all properties
>> populated in an undefined manner.
>>
>>
>>> Is there a reason to utilize bounding_box class to also support boxes
>>> that are not axis aligned, which is all Eigen::AlignBox supports?
>>>
>> I think non-axis-aligned bounding boxes might have utility in the future,
>> but bounding_box is currently configured to only specify axis-aligned
>> boxes. So, we would have to completely redefine the interface to
>> bounding_box to support non-axis-aligned boxes.
>>
>> ~Matt
>>
>

-- 
Matt Brown, Ph.D.
Staff R&D Engineer
Kitware, Inc.
101 E Weaver St. Suite G4
Carrboro, NC 27510
(908) 910-3385
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/kwiver-users/attachments/20190311/78f00ad9/attachment.html>