[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