[Kwiver-users] ocv-arrow histogram equalization

Fri Jan 5 15:56:42 EST 2018

Thanks for the feedback. Would be nice to funnel this advice into a style
guide at some point.

On Fri, Jan 5, 2018 at 3:46 PM, Matthew Leotta <matt.leotta at kitware.com>
wrote:

> I agree on that point when it comes to name of the algorithm (e.g. string
> name you pass when registering the algorithms).  However, when it comes to
> naming the .cxx file and the class itself, it can be useful to incorporate
> the name of the algorithm to make them easier to find in a list of files.
> Sometimes we give the class in the arrow the same name as the vital
> algorithm, just in a different namespace, and the name passed to the plugin
> is the same name as the arrow.  For example, ocv::estimate_homography is
> registered as “ocv” and derived from vital::estimate_homography.  This only
> works if you can reasonably expect there to be only one implementation of
> the algorithm provided by that arrow.  If this is not the case, another
> naming scheme we have used is to append another descriptive name to each of
> these.  For example, ocv::extract_descriptors_BRIEF is registered as
> “ocv_BRIEF” and is derived from vital::extract_descriptors.  There are
> other variations where “BRIEF” is replaced by another name.
>
> —Matt
>
>
> On Jan 5, 2018, at 3:22 PM, Linus Sherrill <linus.sherrill at kitware.com>
> wrote:
>
> With regard to naming implementations, I do not think you need to add the
> abstract algorithm name to the new algo name. It seems redundant. When
> listing the algorithms, the base algo name is listed in addition to the
> implementation name.
>
> On Fri, Jan 5, 2018 at 2:54 PM, Matthew Leotta <matt.leotta at kitware.com>
> wrote:
>
>> Matt,
>>
>> In this case I would say image equalization and contrast stretching does
>> match the semantics of “image_filter”.  Image filter should be any sort of
>> image manipulation routine that returns a variant of the image that is
>> enhanced/modified in some way.  It is not meant to be a strict definition
>> of “filter” meaning only operations that can be implemented as a
>> convolution or some other spatially local operation.  Think filter in the
>> sense of the filters menu in the GIMP image editing program.
>>
>> That said, there could be other cases where the input and output types
>> match, but the semantics are different.  In that case, I agree with Linus
>> that you should have different abstract algorithms in vital.  Imagine an
>> algorithm that take an image and uses it as a query to find and return
>> another image which is most similar in a database.  That could also have
>> image in and image out, but I would argue that is not a filter.
>>
>> Also keep in mind that not every function or algorithm needs to be an
>> abstract algorithm in Vital.  The abstract algorithms should represent
>> functional components that you can combine into an application, but where
>> you would reasonably expect to swap out different algorithms for each
>> abstract algorithm.  Algorithms best suited for vital/algo are components
>> where you might expect someone to write a paper or a new software project
>> on a better/faster way to do X, or where there are already various
>> competing software packages providing a way to do X.
>>
>> There may be a point in the future where we have so many image filters
>> that we need to organize them better or create subsets of image filters
>> with more specific applications (like blurring).  We are not at that point
>> yet.
>>
>> —Matt
>>
>>
>> On Jan 5, 2018, at 2:04 PM, Matt Brown <matt.brown at kitware.com> wrote:
>>
>> I think that makes sense. When naming the arrow, should there be an
>> attempt to indicate the vital algorithm within the name? For example, for
>> the image_filter algorithm, I called my arrows filter_gaussian_blur and
>> filter_blur, the later half reflecting the primary OCV function being
>> called.
>>
>> On Fri, Jan 5, 2018 at 1:54 PM, Linus Sherrill <
>> linus.sherrill at kitware.com> wrote:
>>
>>> If we lump all image-in, image-out implementations under one algorithm
>>> (e.g. filter_image), they will all appear in one list and it will be hard
>>> to find what you are looking for. In this case, if there will be multiple
>>> implementations for contrast enhancement, then I think it makes sense
>>> to have a base algorithm for contrast_enhancement even though the code
>>> looks the same as filter_image. This approach also constrains which
>>> algorithm can be configured if it is limited to contrast_enhancement,
>>> rather than using the broader category of filter_image.
>>>
>>> Comments welcome.
>>>
>>>
>>> On Fri, Jan 5, 2018 at 1:41 PM, Matt Brown <matt.brown at kitware.com>
>>> wrote:
>>>
>>>> A bit of a semantics question, but I'd like to make an ocv arrow that
>>>> does histogram equalization and another that stretches contrast in an
>>>> image. The vital *image_filter* prototype fits in that an image goes
>>>> in and one comes out, with the same resolution as the input as is typical
>>>> of a filter. However, semantically, I'm not sure histogram equalization is
>>>> really a filter operation. Does it make sense to:
>>>>
>>>>    1. Just call it a filter and be done with.
>>>>    2. Create an effective duplicate of the filter algorithm and call
>>>>    it something more in line with contrast enhancement.
>>>>    3. plan to rename filter_image to something more generic like
>>>>    process_image.
>>>>
>>>> Thanks,
>>>> Matt
>>>>
>>>> _______________________________________________
>>>> Kwiver-users mailing list
>>>> Kwiver-users at public.kitware.com
>>>> https://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
>> https://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+%3Chttps://maps.google.com/?q%3D28%2BCorporate%2BDrive%2BClifton%2BPark,%2BNY%2B12065%26entry%3Dgmail%26source%3Dg%3E&entry=gmail&source=g>
> Clifton Park, NY 12065
> <https://maps.google.com/?q=28+Corporate+Drive+Clifton+Park,+NY+12065+%3Chttps://maps.google.com/?q%3D28%2BCorporate%2BDrive%2BClifton%2BPark,%2BNY%2B12065%26entry%3Dgmail%26source%3Dg%3E&entry=gmail&source=g>
> -8662
> E: linus.sherrill at kitware.com
> P: 518.881.4400 <(518)%20881-4400>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/kwiver-users/attachments/20180105/669fdd17/attachment.html>