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