[scikit-image] data types

[David Sarma]

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 <jni at 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 at python.org
> https://mail.python.org/mailman/listinfo/scikit-image
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phone        917 375 8730
Email         david at davidsarma.org
Web           http://www.davidsarma.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20180408/180944e0/attachment.html>