Hallo!
To read uncompressed TIFF files I use the freeimage plugin. The reading
works great but since last week I need to save a summed Image. I used the
io.imsave() with the freeimage plugin but by default it writs a compressed
TIFF file. The freeimage documentation provides Flags to use for different
compressions or for a non compressed type (TIFF_NONE). Can someone tell me
how to pass theses Flags to the plugin?
I saw that Christophs 'tifffile' plugin does the job but still I would like
to know how to use the freeimage plug-n for it.
Thanks!
Siggi
On Wed, May 30, 2012 at 1:25 AM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote:
> On Tue, May 29, 2012 at 8:18 PM, Tony Yu <tsyu80(a)gmail.com> wrote:
> > Hmm, I don't think so. It looks like `skimage.io._plugins.plugin.call`
> looks
> > in `skimage.io.plugin_store`. But `plugin_store` is populated by the
> first
> > installed plugin in a list of preferred plugins. Whatever matches, takes
> > over all io operations (more or less). If that plugin doesn't provide
> > `imread_collection`, then that entry in `plugin_store` remains empty. (In
> > other words, after accepting a plugin, there's no additional check
> > afterwards to fill in the functions not provided by that plugin.)
>
> That's not the way it should behave; we should fix it to transparently
> fall back to whatever is available.
>
I've addressed this specific issue in PR
196<https://github.com/scikits-image/scikits-image/pull/196>.
Note: It still doesn't fix the original test error (but if the tifffile
plugin gained an `imread_collection` function, then that would fix it).
>
> > Is there any reason why there's no default `imread_collection` which just
> > passes arguments to `ImageCollection`?
>
> No, that would probably make sense. And I think ImageCollection uses
> the plugin version of imread.
>
Yup: any plugin that provides `imread` should be able to provide an
`imread_collection`. I can take care of this at a later date. (It'd be
great if someone beat me to it, though ;)
-Tony
On Tue, May 29, 2012 at 6:04 PM, Tony Yu <tsyu80(a)gmail.com> wrote:
> I ran all of the scikits-image examples through valgrind (following
> instructions from the scikits-learn website) and didn't see any leaks. Not
> all Cython functions are tested in the examples, though (for example
> functions in morphology and io) so this isn't a thorough test.
Thanks a lot, Tony--that's very helpful.
Stéfan
On Tue, May 29, 2012 at 8:18 PM, Tony Yu <tsyu80(a)gmail.com> wrote:
> Hmm, I don't think so. It looks like `skimage.io._plugins.plugin.call` looks
> in `skimage.io.plugin_store`. But `plugin_store` is populated by the first
> installed plugin in a list of preferred plugins. Whatever matches, takes
> over all io operations (more or less). If that plugin doesn't provide
> `imread_collection`, then that entry in `plugin_store` remains empty. (In
> other words, after accepting a plugin, there's no additional check
> afterwards to fill in the functions not provided by that plugin.)
That's not the way it should behave; we should fix it to transparently
fall back to whatever is available.
> Is there any reason why there's no default `imread_collection` which just
> passes arguments to `ImageCollection`?
No, that would probably make sense. And I think ImageCollection uses
the plugin version of imread.
Stéfan
On Tue, May 29, 2012 at 9:40 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote:
> On Tue, May 29, 2012 at 5:51 PM, Tony Yu <tsyu80(a)gmail.com> wrote:
> > Are there any other plugins that should explicitly state that they
> provide
> > 'imread_collection'? I can run `skimage.io.ImageCollection` but not
> > `skimage.io.imread_collection` so presumably some other plugin(s) can
> read
> > image collections.
>
> Would it help to modify the test plugin to handle image collections?
> I'm not sure if that is loaded by default in the test suite. The idea
> was to eventually have the tiff loader handle multiple layers as an
> ImageCollection as well (and the video loading routines, too).
>
> Stéfan
Hmm, I don't think so. It looks like `skimage.io._plugins.plugin.call`
looks in `skimage.io.plugin_store`. But `plugin_store` is populated by the
first installed plugin in a list of preferred
plugins<https://github.com/scikits-image/scikits-image/blob/master/skimage/io/__ini…>.
Whatever matches, takes over all io operations (more or less). If that
plugin doesn't provide `imread_collection`, then that entry in
`plugin_store` remains empty. (In other words, after accepting a
plugin, there's no additional check afterwards to fill in the functions not
provided by that plugin.)
Is there any reason why there's no default `imread_collection` which just
passes arguments to `ImageCollection`?
-Tony
On Tue, May 29, 2012 at 5:51 PM, Tony Yu <tsyu80(a)gmail.com> wrote:
> Are there any other plugins that should explicitly state that they provide
> 'imread_collection'? I can run `skimage.io.ImageCollection` but not
> `skimage.io.imread_collection` so presumably some other plugin(s) can read
> image collections.
Would it help to modify the test plugin to handle image collections?
I'm not sure if that is loaded by default in the test suite. The idea
was to eventually have the tiff loader handle multiple layers as an
ImageCollection as well (and the video loading routines, too).
Stéfan
> Does anyone have time to run the current version of scikits-image
> through Valgrind? We're getting a segfault on the SPARC platform (via
> the Debian builders), and I wanted to make sure there are no strange
> allocations going on that we're missing.
>
> Thanks
> St�fan
>
>
> I ran all of the scikits-image examples through valgrind (following instructions
> from the scikits-learn website
> <http://scikit-learn.org/dev/developers/debugging.html>) and didn't see any
> leaks. Not all Cython functions are tested in the examples, though (for example
> functions in morphology and io) so this isn't a thorough test.
>
> -Tony
Isn't a segfault likely to be in SciPy (especially if it's calling
something like ATLAS)? That's where I've seen most problems in the
past, though I'm not really familiar with the extensions in
scikits.image itself. Just an idea.
Cheers,
James.
On Tue, May 29, 2012 at 12:03 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote:
> Hi,
>
> Does anyone have time to run the current version of scikits-image
> through Valgrind? We're getting a segfault on the SPARC platform (via
> the Debian builders), and I wanted to make sure there are no strange
> allocations going on that we're missing.
>
> Thanks
> Stéfan
>
I ran all of the scikits-image examples through valgrind (following
instructions
from the scikits-learn
website<http://scikit-learn.org/dev/developers/debugging.html>)
and didn't see any leaks. Not all Cython functions are tested in the
examples, though (for example functions in morphology and io) so this isn't
a thorough test.
-Tony
I'm getting an error for one of the tifffile plugin tests. Basically,
the teardown
function<https://github.com/scikits-image/scikits-image/blob/master/skimage/io/tests…>of
the test is trying to reset all the io functions to their defaults.
But,
it turns out that the default for 'imread_collection' is empty on my
system. I'm not sure if 'imread_collection' should be empty (the fits
plugin seems to be the only one that explicitly states that it reads
collections and I don't have pyfits installed), but the teardown function
should be able to handle that case. I've fixed the test error in PR
195<https://github.com/scikits-image/scikits-image/pull/195>
.
Are there any other plugins that should explicitly state that they provide
'imread_collection'? I can run `skimage.io.ImageCollection` but not
`skimage.io.imread_collection` so presumably some other plugin(s) can read
image collections.
-Tony
Hi,
Does anyone have time to run the current version of scikits-image
through Valgrind? We're getting a segfault on the SPARC platform (via
the Debian builders), and I wanted to make sure there are no strange
allocations going on that we're missing.
Thanks
Stéfan
