Mailman 3 September 2013 - scikit-image

Re: ndarray subclasses
by James Turner 23 Sep '13

23 Sep '13

Maybe it's worth mentioning that astropy has also done a bit of (incomplete) work on an nddata class that adds things like metadata, error and mask information to ndarray. I think it's a wrapper rather than a subclass. This might not be how you would do it for skimage but it's just FYI (not particularly astronomy specific)... http://docs.astropy.org/en/latest/nddata/index.html Just regarding "sampling" vs "resolution", IMHO the common use of resolution to describe pixel density in computing is somewhat erroneous. There isn't really a good substitute term for describing the intrinsic analogue (eg. optical) resolution of an image or waveform before it's digitized (bandwidth?) and (as someone else pointed out) the digitized sampling density/spacing doesn't necessarily tell you how much detail you have anyway. Cheers, JAmes. On 23/09/13 12:43, Thomas A Caswell wrote: > On Mon, Sep 23, 2013 at 2:24 AM, Almar Klein <almar.klein(a)gmail.com > <mailto:almar.klein@gmail.com>> wrote: > > As a skimage (very happy) user, I must say I find **very** convenient > that vanilla ndarrays are accepted throughout the libary, because image > metadata is a problem best kept away from the calculus, except in issues > of the 'sampling case' type, where I agree it is nicer to have it as a > clear function argument. > > Just to be clear, I think skimage should *always* accept vanilla ndarrays, > and I agree that functions that can deal with anisotropy should have an > explicit (and optional) "sampling" argument. > > I think my suggestion would be that such a function should check if the > array has a sampling attribute, and use that if the sampling argument is not > given. In that way, we could do "im = > imerode(imdilate(my_image_with_sampling_attr)", and things would just work > in the correct manner. > > > My concern with this proposal is now the user has two independent ways to pass > in the same information. If inconsistent information is passed in the library > has to make a decision about which one takes precedence. This adds to the > complexity of the function and can only lead to confusion on the part of the > users when they think the precedence should have the opposite order. > > If you have a function `f(array, meta_data)` then I would add a thin wrapper for > the sub-classed arrays as such: `s_f(sub_classed_array): return > f(sub_classed_array, sub_classed_array.get_metadata())`. This adds a lot more > functions, but they can probably be auto-generated and don't add much > complexity. Maybe make them class methods of the sub-array class so they do not > pollute the namespace. > > Tom > > - Almar > > >> On 22 September 2013 05:57, Juan Nunez-Iglesias <jni.soma(a)gmail.com >> <mailto:jni.soma@gmail.com>> wrote: >> >> On Sun, Sep 22, 2013 at 1:20 PM, Jaime FernÃ¯Â¿Â½ndez del RÃ¯Â¿Â½o >> <jaime.frio(a)gmail.com <mailto:jaime.frio@gmail.com>> wrote: >> >> So a pixel replicated TIFF image has twice the resolution, as per >> the above official definition, not the same resolution with twice >> the sampling. >> >> >> Even in this case, what we call sampling/spacing is the *inverse* of >> that definition of resolution. >> >> >> I think strictly speaking, the term "resolution" is a measure for >> visibility of detail. The term is used a lot to simply denote the *number* >> of pixels, e.g. 800x600, 1024x768, etc. Spacing/sampling is really just a >> a measure (usually in mm) that specifies the distance between two pixels. >> If you know the number of pixels, and the sampling, you know the image >> size in physical units. >> >> - Almar >> -- >> 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 >> <mailto:scikit-image+unsubscribe@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 > <mailto:scikit-image%2Bunsubscribe@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 > <mailto:scikit-image%2Bunsubscribe@googlegroups.com>. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > Thomas A Caswell > PhD Candidate University of Chicago > Nagel and Gardel labs > tcaswell(a)uchicago.edu <mailto:tcaswell@uchicago.edu> > jfi.uchicago.edu/~tcaswell <http://jfi.uchicago.edu/~tcaswell> > o: 773.702.7204 > > -- > 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: ndarray subclasses
by Thomas A Caswell 23 Sep '13

23 Sep '13

On Mon, Sep 23, 2013 at 2:24 AM, Almar Klein <almar.klein(a)gmail.com> wrote: > As a skimage (very happy) user, I must say I find **very** convenient that >> vanilla ndarrays are accepted throughout the libary, because image metadata >> is a problem best kept away from the calculus, except in issues of the >> 'sampling case' type, where I agree it is nicer to have it as a clear >> function argument. >> > Just to be clear, I think skimage should *always* accept vanilla ndarrays, > and I agree that functions that can deal with anisotropy should have an > explicit (and optional) "sampling" argument. > > I think my suggestion would be that such a function should check if the > array has a sampling attribute, and use that if the sampling argument is > not given. In that way, we could do "im = > imerode(imdilate(my_image_with_sampling_attr)", and things would just work > in the correct manner. > > My concern with this proposal is now the user has two independent ways to pass in the same information. If inconsistent information is passed in the library has to make a decision about which one takes precedence. This adds to the complexity of the function and can only lead to confusion on the part of the users when they think the precedence should have the opposite order. If you have a function `f(array, meta_data)` then I would add a thin wrapper for the sub-classed arrays as such: `s_f(sub_classed_array): return f(sub_classed_array, sub_classed_array.get_metadata())`. This adds a lot more functions, but they can probably be auto-generated and don't add much complexity. Maybe make them class methods of the sub-array class so they do not pollute the namespace. Tom > - Almar > > > On 22 September 2013 05:57, Juan Nunez-Iglesias <jni.soma(a)gmail.com>wrote: > >> On Sun, Sep 22, 2013 at 1:20 PM, Jaime Fernández del Río < >> jaime.frio(a)gmail.com> wrote: >> >>> So a pixel replicated TIFF image has twice the resolution, as per the >>> above official definition, not the same resolution with twice the sampling. >>> >> >> Even in this case, what we call sampling/spacing is the *inverse* of >> that definition of resolution. >> > > I think strictly speaking, the term "resolution" is a measure for > visibility of detail. The term is used a lot to simply denote the *number* > of pixels, e.g. 800x600, 1024x768, etc. Spacing/sampling is really just a > a measure (usually in mm) that specifies the distance between two pixels. > If you know the number of pixels, and the sampling, you know the image size > in physical units. > > - Almar > -- > 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. > -- Thomas A Caswell PhD Candidate University of Chicago Nagel and Gardel labs tcaswell(a)uchicago.edu jfi.uchicago.edu/~tcaswell o: 773.702.7204

1 0

Re: ndarray subclasses
by Guillaume Gay 23 Sep '13

23 Sep '13

I fully agree on the abuse of the 'resolution' term, yet that is the term used in TIFF header tags: http://www.awaresystems.be/imaging/tiff/tifftags/xresolution.html, although stupidly enough they only allow inches or centimeters as units. Open Microscopy Environment, which are the ones trying to standardize things in my field of research have tags called: PhysicalSizeX, PhysicalSizeY, PhysicalSizeZ, which I find more explicit. As a skimage (very happy) user, I must say I find **very** convenient that vanilla ndarrays are accepted throughout the libary, because image metadata is a problem best kept away from the calculus, except in issues of the 'sampling case' type, where I agree it is nicer to have it as a clear function argument. Best, Guillaume On 22/09/2013 19:48, Almar Klein wrote: > > > > On 22 September 2013 05:57, Juan Nunez-Iglesias <jni.soma(a)gmail.com > <mailto:jni.soma@gmail.com>> wrote: > > On Sun, Sep 22, 2013 at 1:20 PM, Jaime Fernández del Río > <jaime.frio(a)gmail.com <mailto:jaime.frio@gmail.com>> wrote: > > So a pixel replicated TIFF image has twice the resolution, as > per the above official definition, not the same resolution > with twice the sampling. > > > Even in this case, what we call sampling/spacing is the *inverse* > of that definition of resolution. > > > I think strictly speaking, the term "resolution" is a measure for > visibility of detail. The term is used a lot to simply denote the > *number* of pixels, e.g. 800x600, 1024x768, etc. Spacing/sampling is > really just a a measure (usually in mm) that specifies the distance > between two pixels. If you know the number of pixels, and the > sampling, you know the image size in physical units. > > - Almar > -- > 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

Re: ndarray subclasses
by Almar Klein 22 Sep '13

22 Sep '13

On 22 September 2013 05:57, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > On Sun, Sep 22, 2013 at 1:20 PM, Jaime Fernández del Río < > jaime.frio(a)gmail.com> wrote: > >> So a pixel replicated TIFF image has twice the resolution, as per the >> above official definition, not the same resolution with twice the sampling. >> > > Even in this case, what we call sampling/spacing is the *inverse* of that > definition of resolution. > I think strictly speaking, the term "resolution" is a measure for visibility of detail. The term is used a lot to simply denote the *number* of pixels, e.g. 800x600, 1024x768, etc. Spacing/sampling is really just a a measure (usually in mm) that specifies the distance between two pixels. If you know the number of pixels, and the sampling, you know the image size in physical units. - Almar

1 0

Fwd: [SciPy-Dev] Scipy 1.0 roadmap
by François Boulogne 22 Sep '13

22 Sep '13

Hi devs, FYI, I forward you this email from Ralf. In the roadmap, there is one entry for ndimage. Cheers François. -------- Message original -------- Sujet: [SciPy-Dev] Scipy 1.0 roadmap Date : Sat, 21 Sep 2013 20:54:09 +0200 De : Ralf Gommers <ralf.gommers(a)gmail.com> Répondre à : SciPy Developers List <scipy-dev(a)scipy.org> Pour : SciPy Developers List <scipy-dev(a)scipy.org> Hi all, At EuroScipy Pauli, David and I sat together and drafted a roadmap for Scipy 1.0. We then discussed this offline with some of the other currently most active core devs, to get it into a state that's ready for discussion on this list. So here it is: https://github.com/scipy/scipy/pull/2908 Our aim is for this roadmap to help guide us towards a 1.0 version, which will contain only code that we consider to be "of sufficient quality". Also, it will help to communicate to new and potential developers where their contributions are especially needed. In order to discuss/review this roadmap without generating a monster thread, I propose the following: - topics like "do we need a roadmap?" or "what does 1.0-ready really mean?" are discussed on this thread. - things in the General section (API changes, documentation/test/build guidelines, etc.), are discussed on this thread as well. - for discussion of module-specific content, start a new thread and name it "1.0 roadmap: <module_name>". - for minor things, comment on the PR. Cheers, Ralf

1 0

Re: ndarray subclasses
by Juan Nunez-Iglesias 22 Sep '13

22 Sep '13

On Sun, Sep 22, 2013 at 1:20 PM, Jaime Fernández del Río < jaime.frio(a)gmail.com> wrote: > So a pixel replicated TIFF image has twice the resolution, as per the > above official definition, not the same resolution with twice the sampling. > Even in this case, what we call sampling/spacing is the *inverse* of that definition of resolution.

1 0

Re: ndarray subclasses
by Jaime Fernández del Río 22 Sep '13

22 Sep '13

On Sat, Sep 21, 2013 at 7:37 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>wrote: > On Sat, Sep 21, 2013 at 11:55 PM, Jaime Fernández del Río < > jaime.frio(a)gmail.com> wrote: > >> I called it "spacing"... We should probably agree on a terminology >>> library-wide. Incidentally, Josh, I called it "spacing" because of your >>> SciPy talk. ;) >>> >> >> I know the real world is just a particular case we shouldn't be too >> concerned about, but isn't "sampling" or "spacing" basically what everyone >> else calls "resolution"? >> > > Not exactly. The resolution is the minimum distance at which you can > distinguish two points. If you upscale your image just by doubling up each > pixel along each dimension, your pixel spacing/sampling is half but your > resolution hasn't changed. > > Similarly, stick a crappy lens in front of a sensor with very tiny pixel > spacing, and your image resolution is limited by the lens, but your pixel > spacing is unchanged. > Ah, interesting distinction, hadn't thought of it like that. Nevertheless, the term "resolution" is very often used to have a different meaning from what you describe, virtually indistinguishable from "sampling" or "spacing", e.g. in the TIFF standard ( http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf, page 19): XResolution Tag = 282 (11A.H) Type = RATIONAL The number of pixels per ResolutionUnit in the ImageWidth (typically, horizontal - see Orientation) direction. So a pixel replicated TIFF image has twice the resolution, as per the above official definition, not the same resolution with twice the sampling.

1 0

Re: ndarray subclasses
by Juan Nunez-Iglesias 22 Sep '13

22 Sep '13

On Sat, Sep 21, 2013 at 11:55 PM, Jaime Fernández del Río < jaime.frio(a)gmail.com> wrote: > I called it "spacing"... We should probably agree on a terminology >> library-wide. Incidentally, Josh, I called it "spacing" because of your >> SciPy talk. ;) >> > > I know the real world is just a particular case we shouldn't be too > concerned about, but isn't "sampling" or "spacing" basically what everyone > else calls "resolution"? > Not exactly. The resolution is the minimum distance at which you can distinguish two points. If you upscale your image just by doubling up each pixel along each dimension, your pixel spacing/sampling is half but your resolution hasn't changed. Similarly, stick a crappy lens in front of a sensor with very tiny pixel spacing, and your image resolution is limited by the lens, but your pixel spacing is unchanged. Often, the sensor is the limiting factor, which is why we confuse the two. =)

1 0

Postprocessing Book Scans/Photos
by Danilo 21 Sep '13

21 Sep '13

Hi all Recently I stumbled upon http://www.booksorber.com/, a project that postprocesses photos taken of books, so that they can be exported as nice PDFs. It's really a great idea, and it probably works nicely using high quality photos with nice lighting, but there are some quirks (especially the UI!). And as it's not open source, I cannot improve upon it. That got me thinking on how hard it would be to implement the same thing using Python. Then I found scikit-image... Therefore, my questions: - Do you know of similar attempts to solve the book scanning problem, preferrably using Python? - Can scikit-image already do such tasks? This includes book border detection, text border detection, color balance correction, de-skewing, finger removal and other things to make the text as readable as possible. Unfortunately I don't know too much about image processing algorithms, so I'd be happy about any pointers and suggestions. Would be great if such a software could be created as an open source effort. In the end, open source always wins :) Danilo

1 0

Re: ndarray subclasses
by Jaime Fernández del Río 21 Sep '13

21 Sep '13

On Sat, Sep 21, 2013 at 1:04 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>wrote: > On Sat, Sep 21, 2013 at 11:07 AM, Josh Warner <silvertrumpet999(a)gmail.com>wrote: > >> I believe the most recent SLIC improvements also added a `sampling` >> parameter. >> > > I called it "spacing"... We should probably agree on a terminology > library-wide. Incidentally, Josh, I called it "spacing" because of your > SciPy talk. ;) > I know the real world is just a particular case we shouldn't be too concerned about, but isn't "sampling" or "spacing" basically what everyone else calls "resolution"? -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

1 0