Mailman 3 November 2017 - scikit-image

Python 3 transition
by Stefan van der Walt 11 Nov '17

11 Nov '17

Hi, everyone I'd like to make a 4th attempt to determine our transition pathway to Python 3. The last thread is here: https://mail.python.org/pipermail/scikit-image/2017-July/005304.html I would like to propose that the next version, 0.14 (scheduled for March of next year), becomes the last targeted for Python 2. It will also be an LTS (Long Time Support), which means we will backport serious fixes for a period of one year. 0.15 will then target Python >= 3.5 only (sorry, no f-strings yet!). Let me know your thoughts. Stéfan

1 0

Install scikit image
by ahmed barbouche 07 Nov '17

07 Nov '17

Hello , I'm adressing to have some help about how to install scikit image library correctly. I installed python 2.7.14 , with the compiler vs c++ for python. I also make pip install scikit image, it work , it installed setuptools , spy ... but at the end ,it show error in c++ code ... then when i runed my program it showed " your install of scikit image seems to be broken ... ". I tryed to fix some hide c++ file in folder named 'c++ for python' but just the code of error change .i tried also to change version of python to python 3 but the same things appear. Can you help me please . Enclosed some image shown the issue Best regards , Barbouche ahmed

1 0

回复： peak_local_max
by imagepy＠sina.com 07 Nov '17

07 Nov '17

Hi Dzung Nguyen: Does you want to mark every 'circle like' parts in the region? peak_local_max will result too many points, may be you should use h_maxima, unfortunatly, h_maximu is also slow. I had mailed befor. if you want to get the local_max without any other limit, you can use a scipy.ndimage.maximum_filter: # python code maximg = maximum_filter(img, 3) local_max = maximg == img And you may be intresting in my Project, ImagePy: https://github.com/Image-Py, Which is a imagej of python. or a photoshop with scikit-image core. you can do many things interactively. I use my spare time in the last year, Now it has did a A small effect. (In the imagepy.ipyalg.hydrology I had implemented a fast findmax function), two snapshots in the attachment. YXDragonBest ----- 原始邮件 ----- 发件人：Dzung Nguyen <dzungng89(a)gmail.com> 收件人：scikit-image(a)python.org 主题：[scikit-image] peak_local_max 日期：2017年11月07日 07点37分 Hi all, I might take the issue #2758 for my 2nd PR to scikit-image. Could someone point out the potential problems? It does take >20 second on my computer. I looked at the code briefly, and it seems that the bottleneck is _get_high_intensity_peaks? Thanks, --Dzung Nguyen PhD StudentElectrical Engineering and Computer Science,Northwestern University, IL, USA http://users.eecs.northwestern.edu/~dtn419/ _______________________________________________ scikit-image mailing list scikit-image(a)python.org https://mail.python.org/mailman/listinfo/scikit-image

1 0

peak_local_max
by Dzung Nguyen 06 Nov '17

06 Nov '17

Hi all, I might take the issue #2758 <https://github.com/scikit-image/scikit-image/issues/2758> for my 2nd PR to scikit-image. Could someone point out the potential problems? It does take >20 second on my computer. I looked at the code briefly, and it seems that the bottleneck is _get_high_intensity_peaks? Thanks, -- *Dzung Nguyen* PhD Student Electrical Engineering and Computer Science, Northwestern University, IL, USA http://users.eecs.northwestern.edu/~dtn419/

1 0

Re: [scikit-image] linking to GPL code from BSD code (was: BM3D)
by Juan Nunez-Iglesias 06 Nov '17

06 Nov '17

Ok here’s my suggested course of action, inspired in part by the movie The Life of David Gale: 1) Apply for a grant to fund steps 2-5. 2) Make a BSD-licensed library that imports fftw 2b) (optional) sell the library for $500/license. 3) Convince the makers of FFTW to sue. We would pay all legal costs from (1) 4) Put *most* of the funds from (1) towards the defense legal costs, though. 5) Win the lawsuit, thereby creating the required legal precedent and providing a massive boost to the BSD-licensed SciPy ecosystem. Any takers? ;) Juan. On 2 Nov 2017, 6:51 PM +1100, Stefan van der Walt <stefanv(a)berkeley.edu>, wrote: > On Thu, Nov 2, 2017, at 00:26, Nathaniel Smith wrote: > > The FSF is definitely guilty of oversimplifying this, but it's > > probably best to think of their position as a simple bright-line rule > > of thumb, like... if you follow this rule you're definitely safe, and > > if you don't follow this rule... well, it's complicated and ultimately > > it might depend on what the jury had for lunch that day, so good luck. > > Or at least you should ask an actual lawyer :-) > > Should we not also ask: if we got sued, would an argument along the > lines of "yes, I know you've explicitly stated publicly that you meant > *this* with your license, but we prefer interpreting it like *that*" > fly? I have no idea how courts interpret these things, but if a > reasonable expectation was set, I can't see how ignoring it would > benefit us. > > Until there's absolute clarity, or a confirmation from the authors or > the FSF that importing FFTW is OK, I wouldn't go there. > > Stéfan > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image

2 1

Re: [scikit-image] Observed difference between skimage.filters.rank.mean and scipy.signal.convolve2d
by Juan Nunez-Iglesias 03 Nov '17

03 Nov '17

Hi Victor, The biggest problem is that you’re getting bitten by datatypes. Please read the following document: http://scikit-image.org/docs/dev/user_guide/data_types.html Specifically, rank_mean is a uint8 image, so only contains integers between 0 and 255. naive_convolve is a float image, with continuous values between 0 and 255. Try this: In [17]: naive_convolve_float = naive_convolve / 255 In [18]: rank_mean_float = rank_mean / 255 In [19]: plt.imshow(np.abs(naive_convolve_float - rank_mean_float), cmap='magma') Out[19]: <matplotlib.image.AxesImage at 0x10d098fd0> Result: There is a smaller difference also. Internally, filters.rank uses a fancy rolling histogram algorithm with integer data values. This means that the result of the rank_mean is only approximately accurate, essentially to within integer rounding (good enough for most real-world uses), while the convolve2d code gives you an exact value (to within floating point error). Hope this helps! Juan. On 2 Nov 2017, 7:54 PM +1100, Poughon Victor <Victor.Poughon(a)cnes.fr>, wrote: > Hello, > > I looks like skimage.filters.rank.mean and scipy.signal.convolve2d don't output exactly the same images. When doing: > > image = data.coins() > K = np.ones((11, 11)) > > rank_mean = rank.mean(image, selem=K) > naive_convolve = convolve2d(image, K, mode="same") / K.sum() > > All output pixel are different, with an absolute difference varying randomly between 0 and 1. Of course there's also a massive difference at the border, but that's expected because convolve2d treats image boundaries differently. But even in the center of the image all pixels are different. I've made a test script with an illustrated output image, you can check it out in this gist: > > https://gist.github.com/vpoughon/b4afc76ce5dc681fda9d0550d41359d3 > > Am I doing something wrong? > > Thanks, > > Victor Poughon > > > > > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image

2 1

Observed difference between skimage.filters.rank.mean and scipy.signal.convolve2d
by Poughon Victor 02 Nov '17

02 Nov '17

Hello, I looks like skimage.filters.rank.mean and scipy.signal.convolve2d don't output exactly the same images. When doing: image = data.coins() K = np.ones((11, 11)) rank_mean = rank.mean(image, selem=K) naive_convolve = convolve2d(image, K, mode="same") / K.sum() All output pixel are different, with an absolute difference varying randomly between 0 and 1. Of course there's also a massive difference at the border, but that's expected because convolve2d treats image boundaries differently. But even in the center of the image all pixels are different. I've made a test script with an illustrated output image, you can check it out in this gist: https://gist.github.com/vpoughon/b4afc76ce5dc681fda9d0550d41359d3 Am I doing something wrong? Thanks, Victor Poughon

1 0

Re: [scikit-image] linking to GPL code from BSD code (was: BM3D)
by Stefan van der Walt 02 Nov '17

02 Nov '17

On Thu, Nov 2, 2017, at 00:26, Nathaniel Smith wrote: > The FSF is definitely guilty of oversimplifying this, but it's > probably best to think of their position as a simple bright-line rule > of thumb, like... if you follow this rule you're definitely safe, and > if you don't follow this rule... well, it's complicated and ultimately > it might depend on what the jury had for lunch that day, so good luck. > Or at least you should ask an actual lawyer :-) Should we not also ask: if we got sued, would an argument along the lines of "yes, I know you've explicitly stated publicly that you meant *this* with your license, but we prefer interpreting it like *that*" fly? I have no idea how courts interpret these things, but if a reasonable expectation was set, I can't see how ignoring it would benefit us. Until there's absolute clarity, or a confirmation from the authors or the FSF that importing FFTW is OK, I wouldn't go there. Stéfan

1 0

Re: [scikit-image] linking to GPL code from BSD code (was: BM3D)
by Nathaniel Smith 02 Nov '17

02 Nov '17

On Wed, Nov 1, 2017 at 8:24 PM, Josh Warner <silvertrumpet999(a)gmail.com> wrote: > I'm not a lawyer, but I believe there is a longstanding misunderstanding on > this matter and the FSF is in the wrong. The FSF, in the GPL FAQ, says that > maintained dynamic linking, as exhibited in Python, infects any package that > imports. However, to trigger this clause the 'linked' package must > constitute a derivative work, which has a definite legal meaning. The FSF's > justification in the case of static linking is relatively sound. However, > legal rulings on the matter of dynamic linking, as in Python (Galoob v. > Nintendo) disagree. > > For those interested, the actual ruling for Galoob v. Nintendo: > https://law.justia.com/cases/federal/appellate-courts/F2/964/965/341457/ > > The relevant portion of the ruling, which stands today and was affirmed in > Micro Star v. FormGen Inc., states rather concretely > >> A derivative work must incorporate a protected work in some concrete or >> permanent "form." >> > > > Ergo, despite what the FSF states, on the basis of current law dynamic > linking - linking without creating a file in any way, simply asking another > library to do something - does not constitute creation of a derivative work, > and thus does not infringe the GPL. Linking as a matter of current law > involves actually combining the linked code with the code from the linking > package into a concrete form, generally a file, which can then be executed. > Thus, static linking infects, but dynamic linking does not. Again, this > isn't what the FSF says, but ultimately the GPL means what it actually says, > not what the FSF wants it to. Consider this the same way that the US > Constitution exists separately from the Federalist papers and other writings > of the founding fathers. > > Despite this being relatively clearly settled law, very few people call the > FSF out on it, and fewer have the guts to act appropriately as permitted > under the law. Most It's actually harming communities, though, and PyFFTW > is a great example. > > If anyone can actually refute this, I'm all ears. I'm not a lawyer either, but this strikes me as extraordinarily overconfident armchair lawyering. You can't take one sentence out of one ruling and base a whole legal analysis on it. In this case, I guess you're arguing that because dynamic linking only combines the works temporarily in memory at runtime, this isn't a "concrete or permanent form", just like the Game Genie only modified Nintendo games dynamically in memory, so no derivative work is created. But... this is refuting a straw man. Even the FSF doesn't think that you combining two works at runtime in the privacy of your home is a license violation; I've never even heard that argument. The usual argument for dynamic linking creating derivative works is that in order to write the program that calls PyFFTW or whatever, you had to incorporate various creative ideas encoded in the PyFFTW API into the structure of your program. A crude example would be that your program's text probably contains a bunch of function names that the PyFFTW developers invented, but it's more than just that -- look up the Abstraction-Filtration-Comparison test, and consider that if you write a book that's just like Harry Potter but with every word replaced by a synonym, or even a piece of fan-fic that uses the same characters but none of the same language, then those can still be derivative works of J. K. Rowling's texts. The FSF is definitely guilty of oversimplifying this, but it's probably best to think of their position as a simple bright-line rule of thumb, like... if you follow this rule you're definitely safe, and if you don't follow this rule... well, it's complicated and ultimately it might depend on what the jury had for lunch that day, so good luck. Or at least you should ask an actual lawyer :-) -n -- Nathaniel J. Smith -- https://vorpus.org

1 0

Re: [scikit-image] linking to GPL code from BSD code (was: BM3D)
by Juan Nunez-Iglesias 02 Nov '17

02 Nov '17

Thanks Josh. That was a very informative click-hole, and I now fully agree with your assessment that a Python import in a BSD package would not violate the GPL clause. I would caution two things: - If scikit-image required GPL-licensed code to function, then any downstream distribution would need to bundle both together, and might thus fall foul of GPL restrictions. Therefore I would argue that if we include GPL dependencies, we should make them optional. - If we were to vendor GPL code with scikit-image, I believe that would also violate the GPL if we did not license the resulting library as GPL. Having said that, if we stick to optional dependencies, e.g. on PyFFTW to speed up our FFT code if it is present, then I think we would be in the clear. And this is a very attractive proposition. Thanks, Juan.

1 0