[Kwiver-users] ocv-arrow histogram equalization

Fri Jan 5 16:04:38 EST 2018

Agreed.  I’m mostly just highlighting the patterns we have used so far, which I guess is "how it should be done” for now, just for consistency sake, but there may be a better approach.  If we can agree that this approach makes sense and handles the cases we care about then we should document it and make it official.

… actually, I suppose it is more practical to document it and make it official anyway and then consider revising when someone complains.

—Matt

> On Jan 5, 2018, at 3:56 PM, Matt Brown <matt.brown at kitware.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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:
>>> Just call it a filter and be done with.
>>> Create an effective duplicate of the filter algorithm and call it something more in line with contrast enhancement.
>>> plan to rename filter_image to something more generic like process_image.
>>> Thanks,
>>> Matt
>>> 
>>> 
>>> _______________________________________________
>>> Kwiver-users mailing list
>>> Kwiver-users at public.kitware.com <mailto:Kwiver-users at public.kitware.com>
>>> https://public.kitware.com/mailman/listinfo/kwiver-users <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 <mailto:linus.sherrill at kitware.com>
>>> P: 518.881.4400 <tel:(518)%20881-4400>
>>> 
>>> _______________________________________________
>>> Kwiver-users mailing list
>>> Kwiver-users at public.kitware.com <mailto:Kwiver-users at public.kitware.com>
>>> https://public.kitware.com/mailman/listinfo/kwiver-users <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 <mailto:linus.sherrill at kitware.com>
>> P: 518.881.4400 <tel:(518)%20881-4400>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/kwiver-users/attachments/20180105/3510ebbd/attachment-0001.html>