Thanks everyone! I've made a "master issue" to track progress on this: https://github.com/scikit-image/scikit-image/issues/3009
Let's continue the discussion there. If anyone wants to tackle anything in the to-do list, we would be very grateful! skimage will be a much nicer package when all those tick-boxes are ticked. =) Juan. On Sun, Apr 8, 2018, at 9:48 PM, David Sarma wrote: > In compositing in visual effects, dealing with many widely varying > image and data formats used to be a common problematic issue, but for > the most part it is not much of an issue anymore. Maybe the > resolution in that domain can give you some ideas for how to deal > with this issue:> > Guessing about the intent of the user was common at one point, but > generally led to a lot of frustration, particularly so when the > operation that the user needs to perform is different from what s/he > needs to view in order to judge the correctness of the outcome. "Data > images" need to remain untouched, and it is very frustrating to have > any mysterious conversions taking place behind the scenes (automatic > gamma correction in particular was the key issue that caused so many > problems). On the other hand, it is also frustrating to get black > images, and not know what is happening.> > The resolution of this issue took the form of the split of viewer from > operation. If you have a clear separation of operations that are > intended to assist the user in making visual judgement, then you are > at liberty to guess at "magic" transformations. Meanwhile, you lend > clarity to the idea that, wrt the actual image data, nothing will > happen unless the user explicitly asks for it. It's easy to lose trust > in tools when magic operations start taking place behind the scenes, > even if they are well-documented.> > It may also be worth considering that, presenting things as error > messages or warnings when they are just information that's necessary > to do legitimate work, can wind up being somewhat off-putting. It is > common, for example, to drastically exaggerate a correction that will > later be brought back into range at a different stage in the > computation. In compositing packages (like Nuke for example), there's > a lot of information that's persistently displayed to you, that you > need available to do the basic work of building up a computation. I > tried a while ago to see if it might be possible to use the Orange > Data Mining interface to get something resembling an image processing > setup. I set it aside, but it did at least seem to have the right mix > of components such that a working setup would be imaginable with some > effort. Having immediate feedback on what are not actually errors but > rather necessary steps in understanding and building up a computation > might reduce the need to rely on documentation, which in this case > might be standing in for the information that you would get from a > tighter feedback loop.> > -David > > On Fri, Apr 6, 2018 at 9:44 PM, Juan Nunez-Iglesias > <j...@fastmail.com> wrote:>> On Sat, Apr 7, 2018, at 10:36 AM, Stefan van der > Walt wrote: >> > Agreed, I don't think anyone ever uses uint32 for images. >> > Typically 16, but perhaps also 64? >> >> What I'm arguing is that if anyone takes a 64-bit image and converts >> it to float, they are *not* after their image divided by 2**64.>> >> _______________________________________________ >> scikit-image mailing list >> scikit-image@python.org >> https://mail.python.org/mailman/listinfo/scikit-image > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Phone 917 375 8730 > Email da...@davidsarma.org > Web http://www.davidsarma.org > _________________________________________________ > 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
