7 Aug
2019
7 Aug
'19
9:50 a.m.
Hi everyone, it seems that this discussion started somehow in the PR3983 <https://github.com/scikit-image/scikit-image/pull/3983>, thank you Mark for raising this discussion on the mailing list. As everybody seems to agree with, requiring the *API *to be nD-compatible is the right way to go. But IMHO requiring nD-support at PR stage is too hard in many cases. It is even some times confusing: do we require color image support, multi-channel image support, image sequence support, volume support, or all combination of these cases?.. +1 with the suggestion of Lars about writing a guide on nD algorithms. A clear description of the cases listed above and defining a convention for documenting if a function supports any of them (for example a section in the docstring listing the different supported cases). BTW, as I already mentioned in the aforementioned PR, what about listing all the actual skimage functions only supporting 2D and creating the corresponding issues for extending their support to nD? Riadh. Le 07/08/2019 à 07:42, Johannes Schönberger a écrit : > Agreed on pretty much everything that has been said in this thread. We should highly encourage contributors to generalize to ND, but we shouldn’t impose this as an absolute requirement. That being said, we should design the interfaces in a future proof way, as suggested earlier in this thread. Some of our old code uses x/y and r/c parameters, which caused a lot of refactoring and deprecation effort. > >> On 5 Aug 2019, at 12:39, Alexandre de Siqueira <alex.desiqueira@igdore.org> wrote: >> >> Hey everyone, >> discussing some of Mark and Lars' points. >> >>>> Personally, I think that the ND requirement is too big to impose on >>>> contributions and on reviewers. >> I agree with you here, Mark. If we always think "this code will have to >> be nD-available to be accepted", we'll lose contributions/lots of dev >> time in each contrib. >> >>>> Often, people just need 2D operations. >>>> >>>> (...) ND is actually very computationally expensive. In many >>>> >> cases, people might have an information dense "2D image" and >>>> slight >> variations on other dimensions. This means that using >>>> a full blown >> 2D algorithm is just in efficient on higher >>>> dimensions (3D or Time, >> or color). >> >> IMHO, as a scientific package, this is not a sufficient argument for us >> to get rid of nD in the algorithms. I guess there are people hoping >> that we will implement specific nD things someday. If nD is hairy in >> our minds, think that several of these algorithms won't pass 3D (+ >> color and/or time). >> >>>> I think what is important is to keep the API forward looking for >>>> ND. We can do things like accept tuples for parameters, instead of >>>> "x_center", "y_center", or "r_center", "c_center". We can also >>>> just throw errors when people pass in higher dimensions images >>>> saying that it isn't implemented and contributions are welcome. >>> I think this is critical and really like this compromise. Don't do >>> more work than is actually needed while not making future work >>> harder. Equally critical to me is that whether a function supports >>> ND or only 2D is clearly documented. Maybe after a parameter's type >>> declaration in the docstring? >> I guess these are all good solutions for us right now. I'm sure that >> we'll break, fix and clean lots of stuff/code/API until we reach 1.0 >> (and that is okay™). This problems will be tackled naturally on the >> way. >> >>>> Optimizing for the different use cases is just tricky, and won't >>>> be done correctly if contributors are asked to include something >>>> they have no immediate need for. >> We can help in some of these cases. If we (core group) can't, we can: >> 1. discuss if the algorithm is ready as-is to be included and upgraded >> from there; 2. ask for external community help. >> >>> In that vein, wasn't there a discussion about writing a guide on >>> ND-algorithms (e.g. the raveled approach used in watershed, >>> local_maxima, flood_fill)? Was there any progress on this? I think >>> this could be really useful to the community and a good resource >>> for new contributors regardless of how skimage's policy on this >>> turns out. >> +1. Or even, contributors aiming to enhance our 3D/nD possibilities, >> only :) >> >> Kind regards, and have y'all a nice week, >> >> Alex >> >> >>> On Mon, 2019-08-05 at 09:49 +0200, Lars Grueter wrote: >>>> On 04/08/2019 18:38, Mark Harfouche wrote: >>>> There has been some discussion about having requirements on new >>>> contributions being compatible with ND images. This has been >>>> discussed >>>> in a few PRs on several occasions and I think it warrants a >>>> discussion >>>> on the mailing list (though I'm the first to admit, I get too many >>>> emails and seldom check mailing lists). Feel free to copy paste >>>> this as >>>> an issue on GitHub. >>>> >>>> Personally, I think that the ND requirement is too big to impose on >>>> contributions and on reviewers. >>>> >>>> Often, people just need 2D operations. >>>> >>>> I think what is important is to keep the API forward looking for >>>> ND. We >>>> can do things like accept tuples for parameters, instead of >>>> "x_center", >>>> "y_center", or "r_center", "c_center". We can also just throw >>>> errors >>>> when people pass in higher dimensions images saying that it isn't >>>> implemented and contributions are welcome. >>> I think this is critical and really like this compromise. Don't do >>> more >>> work than is actually needed while not making future work harder. >>> Equally critical to me is that whether a function supports ND or only >>> 2D >>> is clearly documented. Maybe after a parameter's type declaration in >>> the >>> docstring? >>> >>>> The second aspect is that ND is actually very computationally >>>> expensive. >>>> In many cases, people might have an information dense "2D image" >>>> and >>>> slight variations on other dimensions. This means that using a full >>>> blown 2D algorithm is just in efficient on higher dimensions (3D or >>>> Time, or color). >>>> >>>> Optimizing for the different use cases is just tricky, and won't be >>>> done >>>> correctly if contributors are asked to include something they have >>>> no >>>> immediate need for. >>> I'm not sure I can follow you here. An ND-algorithm isn't inherently >>> slower for a 2D-problem than a 2D-algorithm. Agreed, it can be tricky >>> to >>> integrate optimizations and shortcuts for the 2D-case into an >>> ND-algorithm but it's certainly doable. I guess still a point in >>> favor >>> of allowing 2D-only. :) >>> >>> Another approach is to keep two sub-functions: a general one for the >>> ND-case and an optimized one for the 2D-case. Although having two >>> algorithms for one problem may rarely be worth the maintenance cost. >>> >>> In my limited experience the algorithmic difference between 1D and 2D >>> is >>> more significant than between 2D and ND. >>> >>> In that vein, wasn't there a discussion about writing a guide on >>> ND-algorithms (e.g. the raveled approach used in watershed, >>> local_maxima, flood_fill)? Was there any progress on this? I think >>> this >>> could be really useful to the community and a good resource for new >>> contributors regardless of how skimage's policy on this turns out. >>> >>>> Finally, ND is just weird. Have a listen to this crazy video: >>>> >>>> https://youtu.be/mceaM2_zQd8 >>> :D My favorite explanation is this one: https://youtu.be/zwAD6dRSVyI >>> >>> Lars >>> >>> _______________________________________________ >>> scikit-image mailing list -- scikit-image@python.org >>> To unsubscribe send an email to scikit-image-leave@python.org >> -- >> -------------------------------------------------- >> Dr. Alexandre de Siqueira >> Berkeley Institute for Data Science - BIDS >> 190 Doe Library >> University of California, Berkeley >> Berkeley, CA 94720 >> United States >> >> Lattes CV: 3936721630855880 >> ORCID: 0000-0003-1320-4347 >> Github: alexandrejaguar >> Skype: alexandrejaguar >> -------------------------------------------------- >> _______________________________________________ >> scikit-image mailing list -- scikit-image@python.org >> To unsubscribe send an email to scikit-image-leave@python.org > _______________________________________________ > scikit-image mailing list -- scikit-image@python.org > To unsubscribe send an email to scikit-image-leave@python.org