[SciPy-User] ndimage filters overflow for default image format (uint8)
Tony Yu
tsyu80 at gmail.com
Wed Aug 5 02:47:42 EDT 2009
Gilles Rochefort <gilles.rochefort at gmail.com> wrote:
> As you may know, grayscale images are represented with uint8 because
> of
> a low memory footprint.
[Snip]
> So, now filtered datas may be stored as int8, but you loose half the
> precision (dividing by two filter coefficients). Most applications
> won't suffer from a limited precision.
Thanks for your suggestions. As I mentioned, I understand why scipy
behaves the way it does (from a programming perspective); I'm just not
sure if it makes sense from a user's perspective.
> In my opinion, as a programmer you have to know the filtered datas
> range. So, you just have to decide if precision does care or not.
> You can't expect correlate1d to guess your intent for the resulting
> range.
Actually, I didn't intend correlate1d to guess the resulting range,
but instead, certain filters to guess (those filters that return
values outside the input range). Most filters return outputs within
the range of the input, and should behave as they currently do. In any
case you're probably right: I don't think my solution was really the
appropriate one.
I agree that a programmer should know the filtered data range, but my
main complaint is that someone should be making noise if I forget that
a filter returns values outside the valid range. To me, this behavior
is similar to using a "bare except" (an except clause without an
expression): code ends up failing silently. When using edge detection
filters on uint8 images (the reason I ran into this problem), overflow
resulted in erroneous output that **looked like valid output**. If I
had known an overflowed occurred, I would have found my problem much
sooner.
Basically: I often do stupid things, and I want someone tell me I'm
being stupid rather than nod in agreement. ;)
TSY
More information about the SciPy-User
mailing list