On Mon, Sep 26, 2011 at 10:41 AM, Andreas Mueller email@example.com wrote:
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.
That's wrong, obviously. If we implemented the suggestion above, the output would always have been properly scaled to [0, 1].
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.
In this case it's easy, since rgb2gray cannot produce accurate results unless using floats.
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?
Maybe I should just write the conversion functions quickly, then we have something to work from. They should definitely complain when you go from float to uint, but not the other way around.
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?
Accuracy is definitely #1. That's why the suggestion is that algorithms choose for themselves. Sometimes it makes sense to return the same type as the input, sometimes it doesn't. What is important is that images remain scaled, and can again be interpreted by the next function in the pipeline. Where possible, we do not want to make copies in memory. So, in rgb2gray's case, e.g., the conversion gives floating point numbers by default. We do not need to convert those numbers to uint for the user and, actually, we shouldn't--because that would destroy accuracy.
I'll whip up the conversion functions and offer them as a PR. This is probably important, since it will influence the code written for 0.4 a lot.