Re: [scikit-image] 回复： Numba on pypi

[Stefan van der Walt]

Hi Thomas

On Thu, Jul 13, 2017, at 01:04, Thomas Walter via scikit-image wrote:
>  A question to Stéfan: would this mean that you would remove all cython code 
> from scikit-image or would numba just be another option? 
I think we'd probably keep both around; one of the advantages of this approach 
is that we can gradually explore new functionality with numba, while retaining 
all existing code until there's a strong need to modify for speed/simplicity.  
Cython & numba also do not fulfill exactly the same roles.  E.g., Cython is 
great for wrapping C and C++  libraries.
Best regards
Stéfan

___
scikit-image mailing list
scikit-image@python.org
https://mail.python.org/mailman/listinfo/scikit-image

Re: [scikit-image] 回复： Numba on pypi

[Thomas Walter via scikit-image]

Hi YXDragon,

just a word on some aspect you mention:

> the local_max has not a tolerance, so the result is too massy, then 
do a watershed end with too many fragments...,


The definition that underlies this function is: "A local maximum is a 
region of constant grey level strictly greater than the grey levels of 
all pixels in direct neighborhood of the region." - There is no 
tolerance associated to this definition, and I am perfectly fine with 
this. There are definitely many cases where you want to extract all 
local maxima. Nevertheless, there are other functions for detection of 
maxima that allow one to also impose certain criteria (such as h_maxima 
or peak_local_max).


A question to Stéfan: would this mean that you would remove all cython 
code from scikit-image or would numba just be another option?


Best,

Thomas.

On 7/13/17 8:49 AM, imag...@sina.com wrote:

Hi Stéfan:

  I appreciate Numba. for sometimes, we must do a 'for' in our python 
code, but just a 'for' with a 'if', It is fussy to compile a so/dll or 
write cython. Numba is very portable, and can run anywhere, just need 
to install numba and llvmlite. (That means our package could be a 
light-weight library, undepended any native so/dll)


  As I metioned befor, many scikit-image's algrisms are not exquisite 
enough(just my own opinion),
  the mid_axi function results too many branch and sometimes with 
hols,
  the local_max has not a tolerance, so the result is too massy, 
then do a watershed end with too many fragments...,
  and how to build a graph from the skeleton, then do a network 
analysis.


I want to do a contribute to scikit-image, But after some effort, I 
give up, I prefor to write a dynamic lib rather then Cython. In the 
end, I wrote them in Numba. So I appreciate to use Numba.


Best
YXDragon

- 原始邮件 -
发件人：Stefan van der Walt 
收件人：scikit-image@python.org
主题：[scikit-image] Numba on pypi
日期：2017年07月13日 14点17分

Hi everyone,
As many of you know, speed has been a point of contention in
scikit-image for a long time. We've made a very deliberate decision to
focus on writing high-level, understandable code (via Python and
Cython): both to lower the barrier to entry for newcomers, and to lessen
the burden on maintainers. But execution time comparisons, vs OpenCV
e.g., left much to be desired.
I think we have hit a turning point in the road. Binary wheels for
Numba (actually, llvmlite) were recently uploaded to PyPi, making this
technology available to users on both pip and conda installations. The
importance of this release on pypi should not be dismissed, and I am
grateful to the numba team and Continuum for making that decision.
So, how does that impact scikit-image? Well, imagine we choose to
optimize various procedures via numba (see Juan's blog post for exactly
how impactful this can be:
https://ilovesymposia.com/2017/03/15/prettier-lowlevelcallables-with-numba-jit-and-decorators/).
The only question we have to answer (from a survival point of view)
needs to be: if, somehow, something happens to numba, will an
alternative will be available at that time? Looking at the Python JIT
landscape (which is very active), and the current state of numba
development, I think this is likely. And, if we choose to use numba, of
course we'll help to keep it healthy, as far as we can.
I'd love to hear your thoughts. I, for one, am excited about the
prospect of writing kernels as simply as:
>>> @jit_filter_function
... def fmin(values):
... result = np.inf
... for v in values:
... if v < result:
... result = v
... return result
>>> ndi.generic_filter(image, fmin, footprint=fp)
Best regards
Stéfan
___
scikit-image mailing list
scikit-image@python.org
https://mail.python.org/mailman/listinfo/scikit-image


___
scikit-image mailing list
scikit-image@python.org
https://mail.python.org/mailman/listinfo/scikit-image



--
Thomas Walter
27 rue des Acacias
75017 Paris

___
scikit-image mailing list
scikit-image@python.org
https://mail.python.org/mailman/listinfo/scikit-image

[scikit-image] 回复： Numba on pypi

[imagepy]

Hi Stéfan:
  I appreciate Numba. for sometimes, we must do a 'for' in our python code, but 
just a 'for' with a 'if', It is fussy to compile a so/dll or write cython. 
Numba is very portable, and can run anywhere, just need to install numba and 
llvmlite. (That means our package could be a light-weight library, undepended 
any native so/dll)
  As I metioned befor, many scikit-image's algrisms are not exquisite 
enough(just my own opinion),  the mid_axi function results too many branch 
and sometimes with hols,the local_max has not a tolerance, so the 
result is too massy, then do a watershed end with too many fragments...,  
and how to build a graph from the skeleton, then do a network analysis.
I want to do a contribute to scikit-image, But after some effort, I give up, I 
prefor to write a dynamic lib rather then Cython. In the end, I wrote them in 
Numba. So I appreciate to use Numba.
BestYXDragon
- 原始邮件 -
发件人：Stefan van der Walt 
收件人：scikit-image@python.org
主题：[scikit-image] Numba on pypi
日期：2017年07月13日 14点17分

Hi everyone,
As many of you know, speed has been a point of contention in
scikit-image for a long time.  We've made a very deliberate decision to
focus on writing high-level, understandable code (via Python and
Cython): both to lower the barrier to entry for newcomers, and to lessen
the burden on maintainers.  But execution time comparisons, vs OpenCV
e.g., left much to be desired.
I think we have hit a turning point in the road.  Binary wheels for
Numba (actually, llvmlite) were recently uploaded to PyPi, making this
technology available to users on both pip and conda installations.  The
importance of this release on pypi should not be dismissed, and I am
grateful to the numba team and Continuum for making that decision.
So, how does that impact scikit-image?  Well, imagine we choose to
optimize various procedures via numba (see Juan's blog post for exactly
how impactful this can be:
https://ilovesymposia.com/2017/03/15/prettier-lowlevelcallables-with-numba-jit-and-decorators/).
The only question we have to answer (from a survival point of view)
needs to be: if, somehow, something happens to numba, will an
alternative will be available at that time?  Looking at the Python JIT
landscape (which is very active), and the current state of numba
development, I think this is likely.  And, if we choose to use numba, of
course we'll help to keep it healthy, as far as we can.
I'd love to hear your thoughts.  I, for one, am excited about the
prospect of writing kernels as simply as:
>>> @jit_filter_function
... def fmin(values):
... result = np.inf
... for v in values:
... if v < result:
... result = v
... return result
>>> ndi.generic_filter(image, fmin, footprint=fp)
Best regards
Stéfan
___
scikit-image mailing list
scikit-image@python.org
https://mail.python.org/mailman/listinfo/scikit-image
___
scikit-image mailing list
scikit-image@python.org
https://mail.python.org/mailman/listinfo/scikit-image