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
How do you feel about the inclusion of OpenCL-based algorithms in the
scikit? Should we perhaps introduce a new module, such as
scikits.image.gpu, which includes some common image processing
Of course, I have no interest in re-writing PyOpenCL from scratch;
that would become an optional dependency.
On Tue, Sep 21, 2010 at 11:10 AM, mael <mael.primet(a)gmail.com> wrote:
> I will try to gradually improve my python code style, have you
> specifics you have seen in my code that were out of the way?
I think mostly spacing issues; but those are well described in the PEP.
> I removed opencv on my laptop because this wouldn't build (I'll try to
> figure out why)
No problem; just make sure that those changes don't get committed to your repo!
> for the data types, the discussion is very interesting,
> most of the algorithms could be adapted for different data-types by
> some preprocessor-like translation,
> however, this might create some problems (floating point comparison
> etc). Plus, our feeling with the previous
> library we were using (Megawave) was that it was better not to provide
> an algorithm for each and every possible datatype,
> as it forced the end-user to ponder whether the algorithm he was
> trying to use was suited to his case etc.
> But I concur that writing float (possibly float and doubles) and
> integer (int and unsigned char?) arrays should be
> made as easy as possible.
Our thought was that two types may be manageable, but while we could
always generalise to support more types, it's very hard to go back --
so I'm happy that we're taking a conservative approach here.
> btw we're also interested in coding some powerful visualization
> function. I guess we'd rather not clutter the scikit with dependencies
> to pyQt or other libraries.
> How would you go about doing something like this? Use some library
> like chaco? Write from scratch a PyQt viewer?
You'll be glad to discover that we already have a Qt visualisation
plugin! Different "imshow" implementations are available, depending
on what is available on your system. Try this:
import scikits.image.io as sio
It should pop up a qt viewer. You may also do
for a display with tuning widgets (only supported on Qt currently).
> I'm not really that good a coder, so I'd be happy to have you guys
> refactor some of my code and tell me the best way to go about it,
> particularly to avoid
> copying arrays over and over. We want to have simple contiguous arrays
> though, because we don't want to bother with complex array iteration
> in our C code.
You'll probably find that, especially for large images, it is often
quicker to do a single copy (to get contiguous data) and then perform
your operation. Good coding comes with practise, and we're all still
learning, so you're in good company.
> Is the way I'm doing it (that was given to us by Emmanuelle) the
> proper way of getting our arrays as contiguous C arrays or are there
> some more efficient
> and/or elegant way to do this?
The clearest way is probably `numpy.ascontiguousarray`.