scikit-image May 2013

scikit-image@python.org

18 participants
65 discussions

Cython / c++ help
by Marc de Klerk 27 May '13

27 May '13

Hi Guys, I'm hoping that I could get some help and advice on c++ and Cython. I've written an OpenCL implementation for the prefix-sum algorithm which I use for generating a compacted lookup table for sparse binary array (called stream compacting) The algorithm isn't really important right now, but just to show what it does here's an example… <https://lh3.googleusercontent.com/-RgftPXLsAkg/UaPGuDqDcgI/AAAAAAAAADc/Qtoa…> In the end, the result is a nice compact array of the indices that were flagged… I'm mainly using it to know which tiles to process for grow cut of graph cut on the gpu like this: <https://lh5.googleusercontent.com/-WBzEmrGga-M/UaPHDOPFzVI/AAAAAAAAADk/7vky…> This operation has to happen a lot… so I really need it to be fast. The problem I'm having is that the when I isolate and measure the execution time of the gpu code it's much faster than that of the c++ or Cython wrapper - which I cannot really do without. So I'm kinda hoping someone can help me to really squash the additional execution time from the overhead of the wrapper. Originally I wrote a Python then Cython wrapper and when looking at the difference between the execution time of just the gnu code vs the total time, I thought it must be from the overhead of the Python/Cython. But I've just written a c++ wrapper and it's not a whole lot faster than Python/Cython, but I'm still hoping there's a lot that can be done… Here are two graphs that might help explain… The one below is measuring the execution time of just the gpu code in the 3 implementations. They should be exactly the same and they are more or less. <https://lh6.googleusercontent.com/-CkzsR0Fx5cI/UaPHWDh-evI/AAAAAAAAADs/pnWs…> The problem is this next graph…. Besides the difference between the c++ and the other two, there's still a large difference between the c++ plot and the plots in the graph above... <https://lh3.googleusercontent.com/--dfWc8dngo8/UaPH8bCaceI/AAAAAAAAAD4/kJDh…> The code is all on https://github.com/mdeklerk/cl-util The files of interest are pyPrefixSum.py, PrefixSum.pyx, which can be tested with test_PrefixSum and PrefixSum.cpp which just needs to be compiled ran… If you've gotten this far, thanks for reading it, I hope it's clear :) I'll greatly appreciate any help, even pointing me more or less in the right direction etc… Cheers, Marc

3 4

Re: Mini Project
by Stéfan van der Walt 27 May '13

27 May '13

Oh, and if that's not enough here's a whole slew of interesting topics to study: https://www.ceremade.dauphine.fr/~peyre/numerical-tour/tours/

1 0

Re: Mini Project
by Stéfan van der Walt 27 May '13

27 May '13

Hi Ronnie Here's a little warm up project I ran into today that might be fun: http://encompass.gsfc.nasa.gov/caseStudies/CiSE-PIV.pdf Or you can try the deconvolution challenge: https://groups.google.com/d/msg/scikit-image/qW52uGjBhWc/tdk8Av4wDLEJ Or, if you want something more challenging, help this guy find a thief using super-resolution: http://www.reddit.com/r/AskReddit/comments/ch3t7/reddit_last_week_you_helpe… Data set here: http://dl.dropbox.com/u/380268/stolen_car_subset.tar Stéfan

1 0

Mini Project
by Ronnie Ghose 27 May '13

27 May '13

Scikit-img, Would you guys per chance have any ideas for a mini project that would/could demonstrate some of the capabilities of both the library/image processing in general? Ideally with regard to a real world application? Thanks, Ronnie

1 0

Re: Weird imsave inverting behaviour
by Stéfan van der Walt 27 May '13

27 May '13

On Mon, May 27, 2013 at 3:08 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > I think you have the right approach, ie imread() should just work. However, > what started this post is that it doesn't. =) Yes, that's a bug and should be fixed. Stéfan

1 0

Re: Weird imsave inverting behaviour
by Juan Nunez-Iglesias 27 May '13

27 May '13

@stefanv On Mon, May 27, 2013 at 7:35 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > > Unfortunately, there's a trade-off between having things "just work" > and the amount of magic that happens behind the scene. I think you have the right approach, ie imread() should just work. However, what started this post is that it doesn't. =)

1 0

Re: Weird imsave inverting behaviour
by Stéfan van der Walt 27 May '13

27 May '13

On Mon, May 27, 2013 at 9:03 AM, Ronnie Ghose <ronnie.ghose(a)gmail.com> wrote: > Can I add that in the docs somewhere? hmm... the question is where should > general guidelines go.... http://scikit-image.org/docs/dev/user_guide/data_types.html Our policy is: anything in, whatever the algorithm prefers out. The data type determines the range: float : [-1, 1] or [0, 1] uint8: [0, 255] Stéfan

1 0

Re: Weird imsave inverting behaviour
by Johannes Schönberger 27 May '13

27 May '13

To be honest I agree, right now it is a mess, which is also the reason why I have not touched this package yet. Things I noticed: - depending on the plugin, the code and comment / doc string quality should be improved - what's the purpose of _colormixer.pyx, _histogram.pyx, q_histogram.py, q_color_mixer.py etc. and why are they in the io plugin directory? - the way plugins are managed should be overhauled and we should discuss it together before implementation My ideas: - rather than having .ini files I would opt for `register(plugin, desc, funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. This enables also users to add new plugins at runtime. - `setup_func` should check whether the plugin is available on this system. - what is indicated as `args` and `kwargs` above should definitely contain two more things: an explicit whitelist of supported file formats, extensions and dtypes or an explicit blacklist of file formats, extensions and dtypes. This could be represented as a dictionary: {['png']: ['uint8', 'float', '…'], ['tif', 'tiff']: … } It allows us to automatically select an available plugin for the given data or raise an error. - Explicitly selecting a plugin should be possible through an extra argument to `imread`, `imsave`. E.g. `imsave(file, data, plugin='freeimage')`. Johannes Schönberger Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias <jni.soma(a)gmail.com>: > OH. Right. That's what's happening, it's not inverted, it's looping around with the overflow! (I was wondering why the correlation was not closer to -1.) > > Guh. imho: > > - This really shouldn't happen. The plugin selection should be aware of the data type, and use only a plugin that can handle it (if available) > - PIL can definitely do 16bit PNG, so either it is being used incorrectly, or the imsave docstring stating that PIL is the first selection is wrong. I just tested this on my PIL-based Gala library, which is 3D so it required a bit of modification: > > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], '~/Desktop/im%02i.png', axis=0 > ) > > In [ > 67]: srg = imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' > ) > > In [ > 68 > ]: srg.shape > Out[ > 68]: (1040, 1392 > ) > > In [ > 69 > ]: (s == srg).all() > Out[ > 69]: True > > - The IO module is a mess! I know Stefan mentioned overhauling it briefly, but I didn't quite realise how urgent that was. In particular: > - is `from blah import *` used as a matter of policy or is it a remnant of an earlier age? Took me ages to find the `call` function. > - `plugin_store`? I have no idea where this gets updated. > > So, to the core skimage devs: what is the scope for updating this? Am I allowed to break some functionality in a PR? Or are we sticking with this API? > > > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke <cjgohlke(a)gmail.com> wrote: > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > Hey all, > > I noticed that some of my microscopy images appeared inverted after > saving them with skimage.io.imsave. After some testing, here's some of > the weirdness. My image is called s: > > ```python > In [37]: np.min(s) > Out[37]: 119 > > In [38]: np.max(s) > Out[38]: 4095 > > In [39]: s.shape > Out[39]: (1040, 1392) > > In [40]: s.dtype > Out[40]: dtype('uint16') > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > In [43]: (s == sr).all() > Out[43]: Image(False, dtype=bool) > > In [44]: sr.min() > Out[44]: Image(0, dtype=uint8) > > In [45]: sr.max() > Out[45]: Image(255, dtype=uint8) > ``` > > Ok, already this is not desirable... One would hope than an imsave > followed by an imread would be a no-op, but whatever, let's accept for > argument's sake that we want to limit ourselves to uint8. Here's the > real downer: > > ```python > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > Out[46]: > array([[ 1. , -0.29849602], > [-0.29849602, 1. ]]) > ``` > > This is simply unacceptable. I haven't explored any more than this yet > but maybe someone has an idea about what is going on here? If it helps, > the problem is with imsave — opening the images in Apple Preview shows > the inversion. I just wanted to know if it was some weird > incompatibility between skimage and Preview, rather than skimage acting > stupid. Sadly, it appears to be the latter. > > PS: I just tested with png and get the exact same result. > > > Not many skimage.io plugins are capable of handling 16 bit data. Use gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. `io.use_plugin('freeimage')` > > Christoph > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > >

3 2

Re: Weird imsave inverting behaviour
by Johannes Schönberger 27 May '13

27 May '13

I was just talking of functions… io should always preserve the input data type and range. Johannes Schönberger Am 27.05.2013 um 09:36 schrieb Juan Nunez-Iglesias <jni.soma(a)gmail.com>: > Well, [0, 1] is great for working, but useless for saving. So what should the convention be for saving? And should we use single or double precision floats? I think in general it's hard to choose for users, and the best thing is to try to preserve user input type unless there's a good reason not to do so. > > Note that 16 bit grayscale images are fairly common, so assuming uint8 for the output is a no-no. > > > On Mon, May 27, 2013 at 5:29 PM, Johannes Schönberger <jschoenberger(a)demuc.de> wrote: > `CONTRIBUTING.txt` > > Johannes Schönberger > > Am 27.05.2013 um 09:03 schrieb Ronnie Ghose <ronnie.ghose(a)gmail.com>: > > > Can I add that in the docs somewhere? hmm... the question is where should general guidelines go.... > > > > > > On Mon, May 27, 2013 at 3:02 AM, Johannes Schönberger <jschoenberger(a)demuc.de> wrote: > > IMO the convention is to use double ([0, 1]) everywhere, except in rare cases…? > > > > Johannes Schönberger > > > > Am 27.05.2013 um 08:56 schrieb Ronnie Ghose <ronnie.ghose(a)gmail.com>: > > > > > can we just standardize it so that _everything_ uses one of the two representations? If an algorithm needs it differently, it can do the 256*array or array/256 and then again output this standard format > > > > > > > > > On Mon, May 27, 2013 at 2:55 AM, Ronnie Ghose <ronnie.ghose(a)gmail.com> wrote: > > > while we're on the subject, it seems algorithms / arrays are mixing using / wanting as input, [0,1] and [0,256] for grayscale, which leads to unexpected results > > > > > > > > > On Mon, May 27, 2013 at 2:51 AM, Johannes Schönberger <jschoenberger(a)demuc.de> wrote: > > > To be honest I agree, right now it is a mess, which is also the reason why I have not touched this package yet. Things I noticed: > > > > > > - depending on the plugin, the code and comment / doc string quality should be improved > > > - what's the purpose of _colormixer.pyx, _histogram.pyx, q_histogram.py, q_color_mixer.py etc. and why are they in the io plugin directory? > > > - the way plugins are managed should be overhauled and we should discuss it together before implementation > > > > > > My ideas: > > > > > > - rather than having .ini files I would opt for `register(plugin, desc, funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. This enables also users to add new plugins at runtime. > > > > > > - `setup_func` should check whether the plugin is available on this system. > > > > > > - what is indicated as `args` and `kwargs` above should definitely contain two more things: an explicit whitelist of supported file formats, extensions and dtypes or an explicit blacklist of file formats, extensions and dtypes. This could be represented as a dictionary: > > > > > > {['png']: ['uint8', 'float', '…'], ['tif', 'tiff']: … } > > > > > > It allows us to automatically select an available plugin for the given data or raise an error. > > > > > > - Explicitly selecting a plugin should be possible through an extra argument to `imread`, `imsave`. E.g. `imsave(file, data, plugin='freeimage')`. > > > > > > > > > > > > > > > Johannes Schönberger > > > > > > Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias <jni.soma(a)gmail.com>: > > > > > > > OH. Right. That's what's happening, it's not inverted, it's looping around with the overflow! (I was wondering why the correlation was not closer to -1.) > > > > > > > > Guh. imho: > > > > > > > > - This really shouldn't happen. The plugin selection should be aware of the data type, and use only a plugin that can handle it (if available) > > > > - PIL can definitely do 16bit PNG, so either it is being used incorrectly, or the imsave docstring stating that PIL is the first selection is wrong. I just tested this on my PIL-based Gala library, which is 3D so it required a bit of modification: > > > > > > > > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], '~/Desktop/im%02i.png', axis=0 > > > > ) > > > > > > > > In [ > > > > 67]: srg = imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' > > > > ) > > > > > > > > In [ > > > > 68 > > > > ]: srg.shape > > > > Out[ > > > > 68]: (1040, 1392 > > > > ) > > > > > > > > In [ > > > > 69 > > > > ]: (s == srg).all() > > > > Out[ > > > > 69]: True > > > > > > > > - The IO module is a mess! I know Stefan mentioned overhauling it briefly, but I didn't quite realise how urgent that was. In particular: > > > > - is `from blah import *` used as a matter of policy or is it a remnant of an earlier age? Took me ages to find the `call` function. > > > > - `plugin_store`? I have no idea where this gets updated. > > > > > > > > So, to the core skimage devs: what is the scope for updating this? Am I allowed to break some functionality in a PR? Or are we sticking with this API? > > > > > > > > > > > > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke <cjgohlke(a)gmail.com> wrote: > > > > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > > > > Hey all, > > > > > > > > I noticed that some of my microscopy images appeared inverted after > > > > saving them with skimage.io.imsave. After some testing, here's some of > > > > the weirdness. My image is called s: > > > > > > > > ```python > > > > In [37]: np.min(s) > > > > Out[37]: 119 > > > > > > > > In [38]: np.max(s) > > > > Out[38]: 4095 > > > > > > > > In [39]: s.shape > > > > Out[39]: (1040, 1392) > > > > > > > > In [40]: s.dtype > > > > Out[40]: dtype('uint16') > > > > > > > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > > > > > > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > > > > > > > In [43]: (s == sr).all() > > > > Out[43]: Image(False, dtype=bool) > > > > > > > > In [44]: sr.min() > > > > Out[44]: Image(0, dtype=uint8) > > > > > > > > In [45]: sr.max() > > > > Out[45]: Image(255, dtype=uint8) > > > > ``` > > > > > > > > Ok, already this is not desirable... One would hope than an imsave > > > > followed by an imread would be a no-op, but whatever, let's accept for > > > > argument's sake that we want to limit ourselves to uint8. Here's the > > > > real downer: > > > > > > > > ```python > > > > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > > > > Out[46]: > > > > array([[ 1. , -0.29849602], > > > > [-0.29849602, 1. ]]) > > > > ``` > > > > > > > > This is simply unacceptable. I haven't explored any more than this yet > > > > but maybe someone has an idea about what is going on here? If it helps, > > > > the problem is with imsave — opening the images in Apple Preview shows > > > > the inversion. I just wanted to know if it was some weird > > > > incompatibility between skimage and Preview, rather than skimage acting > > > > stupid. Sadly, it appears to be the latter. > > > > > > > > PS: I just tested with png and get the exact same result. > > > > > > > > > > > > Not many skimage.io plugins are capable of handling 16 bit data. Use gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. `io.use_plugin('freeimage')` > > > > > > > > Christoph > > > > > > > > -- > > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > >

1 0

Re: Weird imsave inverting behaviour
by Johannes Schönberger 27 May '13

27 May '13

`CONTRIBUTING.txt` Johannes Schönberger Am 27.05.2013 um 09:03 schrieb Ronnie Ghose <ronnie.ghose(a)gmail.com>: > Can I add that in the docs somewhere? hmm... the question is where should general guidelines go.... > > > On Mon, May 27, 2013 at 3:02 AM, Johannes Schönberger <jschoenberger(a)demuc.de> wrote: > IMO the convention is to use double ([0, 1]) everywhere, except in rare cases…? > > Johannes Schönberger > > Am 27.05.2013 um 08:56 schrieb Ronnie Ghose <ronnie.ghose(a)gmail.com>: > > > can we just standardize it so that _everything_ uses one of the two representations? If an algorithm needs it differently, it can do the 256*array or array/256 and then again output this standard format > > > > > > On Mon, May 27, 2013 at 2:55 AM, Ronnie Ghose <ronnie.ghose(a)gmail.com> wrote: > > while we're on the subject, it seems algorithms / arrays are mixing using / wanting as input, [0,1] and [0,256] for grayscale, which leads to unexpected results > > > > > > On Mon, May 27, 2013 at 2:51 AM, Johannes Schönberger <jschoenberger(a)demuc.de> wrote: > > To be honest I agree, right now it is a mess, which is also the reason why I have not touched this package yet. Things I noticed: > > > > - depending on the plugin, the code and comment / doc string quality should be improved > > - what's the purpose of _colormixer.pyx, _histogram.pyx, q_histogram.py, q_color_mixer.py etc. and why are they in the io plugin directory? > > - the way plugins are managed should be overhauled and we should discuss it together before implementation > > > > My ideas: > > > > - rather than having .ini files I would opt for `register(plugin, desc, funcs, setup_func, *args, **kwargs)` and `unregister(plugin)` functions. This enables also users to add new plugins at runtime. > > > > - `setup_func` should check whether the plugin is available on this system. > > > > - what is indicated as `args` and `kwargs` above should definitely contain two more things: an explicit whitelist of supported file formats, extensions and dtypes or an explicit blacklist of file formats, extensions and dtypes. This could be represented as a dictionary: > > > > {['png']: ['uint8', 'float', '…'], ['tif', 'tiff']: … } > > > > It allows us to automatically select an available plugin for the given data or raise an error. > > > > - Explicitly selecting a plugin should be possible through an extra argument to `imread`, `imsave`. E.g. `imsave(file, data, plugin='freeimage')`. > > > > > > > > > > Johannes Schönberger > > > > Am 27.05.2013 um 07:27 schrieb Juan Nunez-Iglesias <jni.soma(a)gmail.com>: > > > > > OH. Right. That's what's happening, it's not inverted, it's looping around with the overflow! (I was wondering why the correlation was not closer to -1.) > > > > > > Guh. imho: > > > > > > - This really shouldn't happen. The plugin selection should be aware of the data type, and use only a plugin that can handle it (if available) > > > - PIL can definitely do 16bit PNG, so either it is being used incorrectly, or the imsave docstring stating that PIL is the first selection is wrong. I just tested this on my PIL-based Gala library, which is 3D so it required a bit of modification: > > > > > > In [66]: imio.write_png_image_stack(s[np.newaxis, ...], '~/Desktop/im%02i.png', axis=0 > > > ) > > > > > > In [ > > > 67]: srg = imio.read_image_stack('/Users/nuneziglesiasj/Desktop/im0*.png' > > > ) > > > > > > In [ > > > 68 > > > ]: srg.shape > > > Out[ > > > 68]: (1040, 1392 > > > ) > > > > > > In [ > > > 69 > > > ]: (s == srg).all() > > > Out[ > > > 69]: True > > > > > > - The IO module is a mess! I know Stefan mentioned overhauling it briefly, but I didn't quite realise how urgent that was. In particular: > > > - is `from blah import *` used as a matter of policy or is it a remnant of an earlier age? Took me ages to find the `call` function. > > > - `plugin_store`? I have no idea where this gets updated. > > > > > > So, to the core skimage devs: what is the scope for updating this? Am I allowed to break some functionality in a PR? Or are we sticking with this API? > > > > > > > > > On Mon, May 27, 2013 at 2:32 PM, Christoph Gohlke <cjgohlke(a)gmail.com> wrote: > > > On 5/26/2013 8:31 PM, Juan Nunez-Iglesias wrote: > > > Hey all, > > > > > > I noticed that some of my microscopy images appeared inverted after > > > saving them with skimage.io.imsave. After some testing, here's some of > > > the weirdness. My image is called s: > > > > > > ```python > > > In [37]: np.min(s) > > > Out[37]: 119 > > > > > > In [38]: np.max(s) > > > Out[38]: 4095 > > > > > > In [39]: s.shape > > > Out[39]: (1040, 1392) > > > > > > In [40]: s.dtype > > > Out[40]: dtype('uint16') > > > > > > In [41]: io.imsave('/Users/nuneziglesiasj/Desktop/im.tif', s) > > > > > > In [42]: sr = io.imread('/Users/nuneziglesiasj/Desktop/im.tif') > > > > > > In [43]: (s == sr).all() > > > Out[43]: Image(False, dtype=bool) > > > > > > In [44]: sr.min() > > > Out[44]: Image(0, dtype=uint8) > > > > > > In [45]: sr.max() > > > Out[45]: Image(255, dtype=uint8) > > > ``` > > > > > > Ok, already this is not desirable... One would hope than an imsave > > > followed by an imread would be a no-op, but whatever, let's accept for > > > argument's sake that we want to limit ourselves to uint8. Here's the > > > real downer: > > > > > > ```python > > > In [46]: np.corrcoef(s.ravel(), sr.ravel()) > > > Out[46]: > > > array([[ 1. , -0.29849602], > > > [-0.29849602, 1. ]]) > > > ``` > > > > > > This is simply unacceptable. I haven't explored any more than this yet > > > but maybe someone has an idea about what is going on here? If it helps, > > > the problem is with imsave — opening the images in Apple Preview shows > > > the inversion. I just wanted to know if it was some weird > > > incompatibility between skimage and Preview, rather than skimage acting > > > stupid. Sadly, it appears to be the latter. > > > > > > PS: I just tested with png and get the exact same result. > > > > > > > > > Not many skimage.io plugins are capable of handling 16 bit data. Use gdal (read only), tifffile (uncompressed tiff only), or freeimage, e.g. `io.use_plugin('freeimage')` > > > > > > Christoph > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups "scikit-image" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > >

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

scikit-image May 2013