[SciPy-User] ndimage filters overflow for default image format (uint8)

[Gilles Rochefort]

Tony Yu a écrit :
> 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. ;)
>   
I understand your point of view.
Well, I imagine that raising an exception on a edge detection filter is
easy to do. You just have to check once if output type is
compatible (meaning twice the input maximum number and not unsigned type).
But doing such a validation in a general filtering is either painfull 
or either overkilling.

Reading docs for exception in python, stands for :

/exception /OverflowError¶
<http://docs.python.org/library/exceptions.html#exceptions.OverflowError>
    Raised when the result of an arithmetic operation is too large to be
    represented. This cannot occur for long integers (which would rather
    raise MemoryError
    <http://docs.python.org/library/exceptions.html#exceptions.MemoryError>
    than give up) and for most operations with plain integers, which
    return a long integer instead. Because of the lack of
    standardization of floating point exception handling in C, most
    floating point operations also aren't checked.
/exception /FloatingPointError¶
<http://docs.python.org/library/exceptions.html#exceptions.FloatingPointError>
    Raised when a floating point operation fails. This exception is
    always defined, but can only be raised when Python is configured
    with the /--with-fpectl/ option, or the WANT_SIGFPE_HANDLER symbol
    is defined in the pyconfig.h file.

Regards,
Gilles Rochefort
> TSY
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20090806/4cd26dd7/attachment.html>