<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 5, 2018 at 2:54 PM, Matthew Leotta <span dir="ltr"><<a href="mailto:matt.leotta@kitware.com" target="_blank">matt.leotta@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Matt,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>—Matt<div><div class="h5"><br><div><br><blockquote type="cite"><div>On Jan 5, 2018, at 2:04 PM, Matt Brown <<a href="mailto:matt.brown@kitware.com" target="_blank">matt.brown@kitware.com</a>> wrote:</div><br class="m_919357733147937263Apple-interchange-newline"><div><div dir="ltr">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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 5, 2018 at 1:54 PM, Linus Sherrill <span dir="ltr"><<a href="mailto:linus.sherrill@kitware.com" target="_blank">linus.sherrill@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 <span style="font-size:12.8px">contrast enhancement, then I think it makes sense to have a base algorithm for </span><span style="font-size:12.8px">contrast_enhancement</span><span style="font-size:12.8px"> even though the code looks the same as filter_image. This approach also constrains which algorithm can be configured if it is limited to </span><span style="font-size:12.8px">contrast_enhancement, rather than using the broader category of filter_image.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Comments welcome.</span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_919357733147937263h5">On Fri, Jan 5, 2018 at 1:41 PM, Matt Brown <span dir="ltr"><<a href="mailto:matt.brown@kitware.com" target="_blank">matt.brown@kitware.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_919357733147937263h5"><div dir="ltr">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 <b>image_filter</b> 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:<br><ol><li>Just call it a filter and be done with.</li><li>Create an effective duplicate of the filter algorithm and call it something more in line with contrast enhancement.</li><li>plan to rename filter_image to something more generic like process_image.</li></ol><p>Thanks,<br>Matt<br></p></div>
<br></div></div>______________________________<wbr>_________________<br>
Kwiver-users mailing list<br>
<a href="mailto:Kwiver-users@public.kitware.com" target="_blank">Kwiver-users@public.kitware.co<wbr>m</a><br>
<a href="https://public.kitware.com/mailman/listinfo/kwiver-users" rel="noreferrer" target="_blank">https://public.kitware.com/mai<wbr>lman/listinfo/kwiver-users</a><br>
<br></blockquote></div><span class="m_919357733147937263HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_919357733147937263m_-8341557515863495981gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font color="#888888"><b>Linus Sherrill - </b></font><font color="#888888">Staff R&D Engineer<br></font><font color="#888888">Kitware, Inc.<br><a href="https://maps.google.com/?q=28+Corporate+Drive+Clifton+Park,+NY+12065&entry=gmail&source=g" target="_blank">28 Corporate Drive</a><br><a href="https://maps.google.com/?q=28+Corporate+Drive+Clifton+Park,+NY+12065&entry=gmail&source=g" target="_blank">Clifton Park, NY 12065</a>-8662<br>E: <a href="mailto:linus.sherrill@kitware.com" target="_blank">linus.sherrill@kitware.com</a><br>P: <a href="tel:(518)%20881-4400" value="+15188814400" target="_blank">518.881.4400</a><br></font></div></div></div></div></div>
</font></span></div>
</blockquote></div><br></div>
______________________________<wbr>_________________<br>Kwiver-users mailing list<br><a href="mailto:Kwiver-users@public.kitware.com" target="_blank">Kwiver-users@public.kitware.<wbr>com</a><br><a href="https://public.kitware.com/mailman/listinfo/kwiver-users" target="_blank">https://public.kitware.com/<wbr>mailman/listinfo/kwiver-users</a><br></div></blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font color="#888888"><b>Linus Sherrill - </b></font><font color="#888888">Staff R&D Engineer<br></font><font color="#888888">Kitware, Inc.<br>28 Corporate Drive<br>Clifton Park, NY 12065-8662<br>E: <a href="mailto:linus.sherrill@kitware.com" target="_blank">linus.sherrill@kitware.com</a><br>P: 518.881.4400<br></font></div></div></div></div></div>
</div>