[Kwiver-users] Window view of Vital image

Aaron Bray aaron.bray at kitware.com
Mon Nov 13 11:44:43 EST 2017


If you do not select the OCV arrow for whatever reason (such as fletch did
not build OCV)
You cannot have a process that uses OCV, so processes dependent on an
optional library should not be part of Core

On Mon, Nov 13, 2017 at 11:39 AM, Matt Brown <matt.brown at kitware.com> wrote:

> I had this same question myself. Others can correct me or add to, but I
> believe the idea is as follows... Arrows allow you to separate the
> implementation of a particular algorithm from the top-level code that uses
> it. Thus, you can have an OCV arrow that does image filtering or some other
> library implementing the particular algorithm. However, for some simpler
> process functionality, it isn't worth the overhead of defining a vital
> algorithm and dispatching to an arrow. For example,
> *ocv/image_viewer_process* just displays an image to the screen. Though
> conceivably, a process could start life as a library-specific
> implementation but then later be broken out into vital::algorithm and arrow
> if there is a desire to use different libraries for that functionality.
>
>
> On Mon, Nov 13, 2017 at 10:43 AM, Matt Phillips <matt.phillips at kitware.com
> > wrote:
>
>> Tbh what is the rationale for having ocv *processes*?  Obviously, ocv
>> algos, and crop_chips is one (arrows/ocv/crop_chips.cxx).  I would have
>> thought that Sprokit would abstract away from which particular vision
>> library is being used to perform some functionality.
>>
>> Matt
>>
>> On Mon, Nov 13, 2017 at 10:33 AM, Matt Brown <matt.brown at kitware.com>
>> wrote:
>>
>>> I think for now, I will just make my process an OCV process, even though
>>> it is only using OCV for the cropping aspect. Once we settle on a view/crop
>>> utility and it makes it way into master, which I think would be great, then
>>> I will move it back to a core process.
>>>
>>> Thanks,
>>> Matt
>>>
>>> On Mon, Nov 13, 2017 at 9:27 AM, Matt Phillips <
>>> matt.phillips at kitware.com> wrote:
>>>
>>>> Hi, I've signed up for kwiver-users now, but as for this post which
>>>> Aaron B. kindly forwarded, I'd say this sounds like Jon C.'s
>>>> crop_chips/crop_detector functionality.  I've written an example pipeline
>>>> for it, and it all lives in Jon's repo atm afaik.
>>>>
>>>> https://github.com/Erotemic/kwiver/tree/dev/CropChipsPipeline
>>>>
>>>> Matt
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Aaron Bray <aaron.bray at kitware.com>
>>>> Date: Mon, Nov 13, 2017 at 9:15 AM
>>>> Subject: Fwd: [Kwiver-users] Window view of Vital image
>>>> To: Matt Phillips <matt.phillips at kitware.com>
>>>>
>>>>
>>>> Are you a member of kwiver-users?
>>>> If not, you should sign up here : https://public.kitware.com/m
>>>> ailman/listinfo/kwiver-announce
>>>>
>>>> This thread sounds like your guacamole arrow...
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Linus Sherrill <linus.sherrill at kitware.com>
>>>> Date: Mon, Nov 13, 2017 at 9:08 AM
>>>> Subject: Re: [Kwiver-users] Window view of Vital image
>>>> To: Matt Brown <matt.brown at kitware.com>
>>>> Cc: kwiver-users at public.kitware.com
>>>>
>>>>
>>>> There has been some discussion about adding functionality to clip
>>>> rectangles (bounding boxes) from images to yield another image (or
>>>> image_container). If somebody is working on this, speak up :-)
>>>> In any event, this is best implemented as an operator on an image(or
>>>> image_container) and not a member.
>>>>
>>>> Thanks,
>>>> -Linus
>>>>
>>>> On Sun, Nov 12, 2017 at 9:16 PM, Matt Brown <matt.brown at kitware.com>
>>>> wrote:
>>>>
>>>>> Is there an easy way to create a view into a window of a Vital image
>>>>> akin to what you can do in OpenCV by applying a cv::Rect to a cv::Mat? I
>>>>> couldn't find any examples in the repo of this being done. I was looking
>>>>> into the 'image_of' class, and I could use that with the appropriate step
>>>>> sizes. But, it would be ideal if a vital::image or even better
>>>>> vital::image_container had this functionality built in.
>>>>>
>>>>> Thanks,
>>>>> Matt
>>>>>
>>>>> _______________________________________________
>>>>> Kwiver-users mailing list
>>>>> Kwiver-users at public.kitware.com
>>>>> http://public.kitware.com/mailman/listinfo/kwiver-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Linus Sherrill - *Staff R&D Engineer
>>>> Kitware, Inc.
>>>> 28 Corporate Drive
>>>> <https://maps.google.com/?q=28+Corporate+Drive+Clifton+Park,+NY+12065&entry=gmail&source=g>
>>>> Clifton Park, NY 12065
>>>> <https://maps.google.com/?q=28+Corporate+Drive+Clifton+Park,+NY+12065&entry=gmail&source=g>
>>>> -8662
>>>> E: linus.sherrill at kitware.com
>>>> P: 518.881.4400 <(518)%20881-4400>
>>>>
>>>> _______________________________________________
>>>> Kwiver-users mailing list
>>>> Kwiver-users at public.kitware.com
>>>> http://public.kitware.com/mailman/listinfo/kwiver-users
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Kwiver-users mailing list
> Kwiver-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/kwiver-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/kwiver-users/attachments/20171113/15cfe612/attachment.html>


More information about the Kwiver-users mailing list