Image data types and conversions

[Andreas Mueller]

Hi Stefan.
> Yes, you're right.  This is an issue that came up for discussion at
> SciPy2011 as well, and I've put a first draft proposal for handing
> data types here:
>
> http://scikits-image.org/docs/dev/user_guide/data_types.html
>
I saw that but I felt it did not really answer my questions ;)


>
>> I personally believe that the library should be written in a way that a user
>> can
>> build a pipeline without doing any explicit type conversions.
>> What do you think about that?
> In an ideal world, yes.  Unfortunately, there's often a cost involved
> to doing the conversions, so the suggestion is to allow almost any
> kind of input, but to not specify the output format.  You'd therefore
> be able to do something like
>
> result = img_as_uint(some_func(x))

There is certainly a tradeoff there.
And I think the suggestion sounds reasonable.

I feel there is still something missing, though.

Going back to the colorspace example, given a ubyte input,
the current algorithm produces a float 0.-255..
I'm not sure whether it is more expensive to divide by 255.
or to round to uint.

As I understand the draft, the current output is not legal, which
is reasonable.
But what should the output be? I think this is a very common case
since often a loaded image is in ubyte and then some continous
operation is applied.

Personally, I think I would round which would correspond to
the principle of least surprise. But maybe someone else
feels the precision lost is important?

So maybe the guidline I would like is either:
- go for precision
- go for consistency with input
- go for speed an then pick one of the others?


I hope I made my question clear ;)

Cheers,
Andy