On Fri, Jan 26, 2018 at 3:28 PM, firstname.lastname@example.org wrote:
Thanks for your advice, It's true that ImagePy is quickly hacked together and unprofessional(The main framework is build in 2 months). And that's why I didnot push it on pypi. I will so some clean up in 2018. But some different opinions：
- about the "promotion" category, I think sometimes it is needed.
Especially, I need to got more user, and some of them should be programer, when they use, they help me to do some test. I will test the interactive framework, but I have no time to test every algrithsm and function.
I think you have this backwards. Alpha-level and even pre-alpha software is absolutely fine to put on PyPI (there is even a specific tag for it, see https://pypi.python.org/pypi?%3Aaction=list_classifiers), and imho a better way to promote your software is to make it very easy for people to install it, and then invite them to try it out. Here I think it's critically important to:
a) make the installation easy, standard, and fool-proof. b) manage expectations about the state of the software.
Rather than promise that this is the successor to ImageJ (this is an enormous task), say that it's a *work-in-progress*, pluggable GUI framework *aiming* to make Python-based image processing software accessible without programming expertise.
If you *don't* say these things up-front, your software might get a reputation for over-promising. Then when ImagePy becomes more polished, people will dismiss it because they tried it when it was buggy and it didn't work for them. I've seen several people on the ImageJ list give up after they couldn't get it to run on their machine. I don't think they will be excited to try again to install from source. If you make it pip installable, they might.
Anyway, I agree with you that there is a balance between getting more users and being cautious. But in my opinion you are leaning too far in the promotion side of things. This is just my opinion and again, please don't let this be discouraging --- as I mentioned before, I think it is very impressive already!
2. ImagePy's concept is borrow and integrate, the key is the interactive ui
framework and the plugin system, not algrithsm. I wrote some in ipyalg, that's because something I must wrote:
eg: https://github.com/Image-Py/imagepy/blob/master/ imagepy/ipyalg/graph/skel2d.py I found scikit-image's medial_axis function has some bug: https://github.com/scikit-image/scikit-image/issues/2550 the scikit-image's medial_axis make holes when thin. And sometimes we donot need many branch. So I wrote the check you saw.
eg:https://github.com/Image-Py/imagepy/blob/master/ imagepy/ipyalg/graph/skel2d.py I need a skeleton analysis function, thanks for your skan, But I think a faster and a cleaner network is better, so I wrote it.
eg: scikit-image's h_minima, h_maxima, watershed function is too slow, and when I process a large image, it would run death. so I wrote some function with numba. That's just temporary, I will replace with scikit-image's function when it's OK.
Sure. We would very much welcome pull requests to scikit-image to improve speed! But, as mentioned a couple of times, they would need to be feature-complete implementations, pass all the tests, and have a clean and documented API. These things all take a lot more effort but they are worth it over time, or the project becomes impossible to maintain.
thanks for your advice, I will learn the PEP8 and numpy style.