[Kwiver-users] ocv-arrow histogram equalization

[Linus Sherrill]

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
Clifton Park, NY 12065-8662
E: linus.sherrill at kitware.com
P: 518.881.4400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/kwiver-users/attachments/20180105/e024d331/attachment.html>