Mailman 3 September 2011 - scikit-image

Re: Image data types and conversions
by Andreas Mueller Sept. 26, 2011

Sept. 26, 2011

Hi Stefan. > Accuracy is definitely #1. That's why the suggestion is that > algorithms choose for themselves. Sometimes it makes sense to return > the same type as the input, sometimes it doesn't. What is important > is that images remain scaled, and can again be interpreted by the next > function in the pipeline. Where possible, we do not want to make > copies in memory. So, in rgb2gray's case, e.g., the conversion gives > floating point numbers by default. We do not need to convert those > numbers to uint for the user and, actually, we shouldn't--because that > would destroy accuracy. > Thanks. That definitely answers my question. > I'll whip up the conversion functions and offer them as a PR. This is > probably important, since it will influence the code written for 0.4 a > lot. > Thanks for tanking my concern seriously. Sounds great :) Cheers, Andy

2 1

Re: Image data types and conversions
by Andreas Mueller Sept. 26, 2011

Sept. 26, 2011

Hi Stefan. > Yes, you're right. This is an issue that came up for discussion at > SciPy2011 as well, and I've put a first draft proposal for handing > data types here: > > http://scikits-image.org/docs/dev/user_guide/data_types.html > I saw that but I felt it did not really answer my questions ;) > >> I personally believe that the library should be written in a way that a user >> can >> build a pipeline without doing any explicit type conversions. >> What do you think about that? > In an ideal world, yes. Unfortunately, there's often a cost involved > to doing the conversions, so the suggestion is to allow almost any > kind of input, but to not specify the output format. You'd therefore > be able to do something like > > result = img_as_uint(some_func(x)) There is certainly a tradeoff there. And I think the suggestion sounds reasonable. I feel there is still something missing, though. Going back to the colorspace example, given a ubyte input, the current algorithm produces a float 0.-255.. I'm not sure whether it is more expensive to divide by 255. or to round to uint. As I understand the draft, the current output is not legal, which is reasonable. But what should the output be? I think this is a very common case since often a loaded image is in ubyte and then some continous operation is applied. Personally, I think I would round which would correspond to the principle of least surprise. But maybe someone else feels the precision lost is important? So maybe the guidline I would like is either: - go for precision - go for consistency with input - go for speed an then pick one of the others? I hope I made my question clear ;) Cheers, Andy

2 1

Release progress
by Stéfan van der Walt Sept. 26, 2011

Sept. 26, 2011

Hi all, We're making good progress on the release. Here's a summary of what still needs to happen: - Pull-request review: https://github.com/scikits-image/scikits.image/pull/28 [Histogram of Gradients + draw] https://github.com/scikits-image/scikits.image/pull/27 [Radon + fast_homography] - Merge: https://github.com/scikits-image/scikits.image/pull/19 [CellProfiler morphology] [will also require minor moving around of files] https://github.com/scikits-image/scikits.image/pull/14 [New backend system] https://github.com/scikits-image/scikits.image/pull/12 [Probabilistic hough] https://github.com/scikits-image/scikits.image/pull/12 [Video IO] - PRs that can possibly still make this release, with little effort: https://github.com/scikits-image/scikits.image/pull/7 [Colour channels are currently returned in the wrong order] https://github.com/scikits-image/scikits.image/pull/13 [Needs some minor cleanup; remove default cv dependency] - PRs that will have to wait until the next release: https://github.com/scikits-image/scikits.image/pull/16 [Fast convolution; boundary modes need to be added] I'd like for 0.3 to also have Debian packaging. I was originally planning to do our own Windows binary releases, but I don't think I'll have time to setup the appropriate environment in time. >From now until release, we'll stop considering PRs other than minor updates or documentation. Regards Stéfan

1 0

Image data types and conversions
by Andreas Mueller Sept. 26, 2011

Sept. 26, 2011

Hi everybody. Since I am new to the project I am not sure whether that has been discussed before, but I think there is still some work to do concerning data types of images. As far as I can tell, most algorithms work with either uchar in the range 0-255 or float in the range 0-1. As far as I could see, no conversion was done between them and if the input to an algorithm was not in the right type, it just gave a garbage result (for example some edge detection or color space conversion). I personally believe that the library should be written in a way that a user can build a pipeline without doing any explicit type conversions. What do you think about that? That would mean that the algorithms would do automatic type conversion when needed. From the doc it seems like something similar is planned. To do automatic type conversions, there needs to be some way for the algorithms to figure out what range the data has. I would assume that float numbers should always be between 0 and 1 and ubyte is always between 0 and 255. At the moment, if you give an ubyte image to (for example) the color space transforms, you get a _float_ in the range 0-255. After that, I think it is impossible to automatically find out the range of the data. I think given ubyte data, either the algorithms should return a ubyte (loosing precision) or return a float between 0 and 1. Do you think this is a good approach? Or is there already some other concept planned? I think this is an important issue for an image library since having to do explicit type conversions really hinders usability. Cheers, Andy

2 1

Brian Holt's histogram of gradient code: ready for merging
by Stéfan van der Walt Sept. 26, 2011

Sept. 26, 2011

Hi all I'm ready to merge Brian's histogram of gradient code. In order to remove the PIL dependency, I've added a new submodule called "scikits.image.draw", with Bresenheim's algorithm (used to determine the coordinates for plotting a line [or circle--not implemented]). Please have a look and send any comments my way. I'll merge this tomorrow if I don't hear anything back. https://github.com/scikits-image/scikits.image/pull/28 Also, I think the new draw module could be a fun place for people who are new to the project to make a good contribution. For example, I'd like to see a NumPy implementation of Wu's algorithm for drawing lines and circles. Regards Stéfan

1 0

PR 26 and 27
by Stéfan van der Walt Sept. 26, 2011

Sept. 26, 2011

Hi all, The radon transform code written by Pieter works well, but currently depends on PIL. I've added "fast_homography" to scikits.image.transform: https://github.com/scikits-image/scikits.image/pull/26 The idea is to eventually replace scikits.image.transform.homography by fast_homography. With the new function in place, the radon transform code can run without using PIL: https://github.com/scikits-image/scikits.image/pull/27 As a bonus, the results are also more accurate, because we don't convert to uint8 afterwards. Please review! We're making good progress to the release; thanks to everyone who has helped out so far. Thanks Stéfan

1 0

Mahotas
by Andreas Mueller Sept. 21, 2011

Sept. 21, 2011

Hi scikits-image people. Sorry for spamming the list but I was wondering whether you know about mahotas: http://luispedro.org/software/mahotas It seems to be a project with similar goals as scikits.image. There are some very useful algorithms in there and I was wondering in how far people are replicating these in scikits.image. Cheers, Andy

2 1

Re: Link on appspot
by Andreas Mueller Sept. 21, 2011

Sept. 21, 2011

Hi Stefan. > I see that you've worked on vlfeat wrappers. I've been thinking of > the best way to provide a scikits.image.feature module, with things > like star features, FAST corner detection (wrappers already written), > etc. If you have any ideas, I'd love to hear them. I'm only roughly familiar with keypoint detection. But I thought about integrating SIFT code from vlfeat. I love vlfeat but it's to much matlab... And I'm pretty sure it's hard to beat the vlfeat SSE2 code. I guess similar things apply to corner detection. vlfeat is gpl. Is it possible to include gpl code int scikits.image and still release it under BSD license (which is the current scikits.image license, right?) ? I saw there was also a discussion about making opencv an dependency. Wouldn't it be possible to just include some of the optimized code without actually using the whole library? Or is there to much infrastructure in opencv that gets used? I'm not a big fan of opencv but I guess there is some fairly optimized code there that scikits.images might want to use. Cheers, Andy

2 1

Link on appspot
by Andreas Mueller Sept. 21, 2011

Sept. 21, 2011

Hi Everybody. First of all, let me congratulate everybody involved on this great project :) I'm writing since I noticed that when you google the project ("scikits image"), you'll get scikits.appspot.com/image as your first hit. They have a link to the old homepage, which makes you click a link to the new homepage. This seems somewhat annoying (three clicks until I'm there) which could be somewhat improved by providing the correct link at scikits.appspot.com. Another thing I was wondering: Is this the only mailing list for this project or is there also a developers list? Cheers, Andy

2 1

Please review PR21: Summed area table
by Stéfan van der Walt Sept. 17, 2011

Sept. 17, 2011

Hi all, Two of the pull requests waiting to be merged make use of summed area tables. I've proposed a Cython implementation here: https://github.com/scikits-image/scikits.image/pull/21 Please review and tell me what you think. I'd like this to be integrated fairly soon, if possible, because it is a bottleneck for the histogram of gradients and template matching PRs. Regards Stéfan

1 0