RFR: IO cleanup

Chris Colbert sccolbert at gmail.com
Fri Nov 5 13:33:17 EDT 2010


In fact mael, I plan on coverting most of your C code to Cython before
pushing it.

On Fri, Nov 5, 2010 at 1:32 PM, Chris Colbert <sccolbert at gmail.com> wrote:

> I think we should be aiming for as little C-code as possible in preference
> for Cython, escpecially when you start talking about raising exceptions. By
> using Cython, all of those questions you have are solved.
>
>
> On Fri, Nov 5, 2010 at 1:27 PM, Maël Primet <mael.primet at gmail.com> wrote:
>
>> Yes, and also it would be good if we'd specify clearly
>> the correct way to treat image arrays:
>> eg. how to load properly an array in the good type?
>> should the algorithms automatically convert an array to  the  algorithm's
>> required type, or should the algorithm fail if the data is not of the
>> correct type (some algorithms have no reason to be run on integers / or real
>> -valued  data, for instance).
>> there should be an utility  function that do the transfer with as little
>> copying as possible, yet it should be possible to force copy when the
>> algorithms request it
>> how do we transfer the arrays to C code ? should we transfer the array
>> directly ? only the memory pointer and the size as is done now ? (but then
>> we cannot call python code from C code, to do for instance an  FFT ) How do
>> we  ensure the array is contiguous with as few copies as necessary ? How do
>> we force a copy to be contiguous ?  etc
>>
>> and also: what is the  proper  way to raise an exception from C code,
>>  etc.
>>
>> if you have any idea,
>> it'd  be  welcome!
>>
>>
>> On Fri, Nov 5, 2010 at 14:38, Chris Colbert <sccolbert at gmail.com> wrote:
>>
>>> btw, all your changes look good.
>>>
>>>
>>> On Fri, Nov 5, 2010 at 9:29 AM, Chris Colbert <sccolbert at gmail.com>wrote:
>>>
>>>> Did we decided on a standard for which dtypes we will support?
>>>>
>>>> Some of the color conversions can be sped up in Cython with a lut (ala
>>>> scivi), but we would need to write one func for each dtype.
>>>>
>>>> I am working on a webinar for image processing and am getting back into
>>>> using th scikit, so there are some things I'm seeing during use that I would
>>>> like to improve, but would require knowledge of what dtypes to support.
>>>>
>>>> Chris
>>>>
>>>> 2010/11/5 Stéfan van der Walt <stefan at sun.ac.za>
>>>>
>>>> Hi all,
>>>>>
>>>>> At the SciPy sprint (ages ago), Chris suggested that we clean up the
>>>>> image loading API.  The following changes simplify `imread` by
>>>>> removing the `dtype` argument.  This allows for simpler plugins.
>>>>> Because `as_grey` is such a commonly used parameter, it is left in
>>>>> place, but now works differently: after the image is loaded, the (new)
>>>>> rgb2grey is simply performed on it.
>>>>>
>>>>> Please have a look at
>>>>>
>>>>> https://github.com/stefanv/scikits.image/compare/master...io_cleanup
>>>>>
>>>>> Regards
>>>>> Stéfan
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20101105/3899b937/attachment.html>


More information about the scikit-image mailing list