From stefan at sun.ac.za Thu Jul 1 02:29:54 2010 From: stefan at sun.ac.za (Stefan van der Walt) Date: Wed, 30 Jun 2010 23:29:54 -0700 (PDT) Subject: Color spaces In-Reply-To: <51d89270-10a3-4674-9ad0-2fae8b62b87f@r27g2000yqb.googlegroups.com> References: <51d89270-10a3-4674-9ad0-2fae8b62b87f@r27g2000yqb.googlegroups.com> Message-ID: <16ecaa09-d71b-4d1a-9eaa-aae0c1c6f6da@k39g2000yqb.googlegroups.com> Hi Chris Sorry for the delayed response; your message was stuck in Google Groups moderation. On Jun 30, 7:00?am, Chris Ball wrote: > Some time ago, there was a thread about what color spaces to include > in scikits.image:http://groups.google.com/group/scikits-image/browse_thread/thread/4b4... > > I wonder if you would be interested in seeing more color space > conversions being added to the colorconv.py module, or if you are > deliberately keeping it simple? For instance, I would like to add > conversions to and from CIE LAB, and to allow alternative white > points. We are definitely interested in building out the colour space manipulation. Chris (Colbert) and I have been discussing the best way to improve the speed of these conversions, and it may be that we'll simply rewrite them in Cython. Regards St?fan From sccolbert at gmail.com Thu Jul 1 11:31:44 2010 From: sccolbert at gmail.com (S. Chris Colbert) Date: Thu, 01 Jul 2010 10:31:44 -0500 Subject: Color spaces In-Reply-To: <16ecaa09-d71b-4d1a-9eaa-aae0c1c6f6da@k39g2000yqb.googlegroups.com> References: <51d89270-10a3-4674-9ad0-2fae8b62b87f@r27g2000yqb.googlegroups.com> <16ecaa09-d71b-4d1a-9eaa-aae0c1c6f6da@k39g2000yqb.googlegroups.com> Message-ID: <1277998304.2258.11.camel@Nokia-N900> Yeah there are definately issues when using pure numpy for color conversions. The most salient is the inability to use a LUT to speed up the computation. This of course is trivial to do in cython and the chief reason why the fancy imshow widget is so fast when manipulating the color space. The downside is handling all the different numpy datatypes. Stefan and i are talking about the best way to do some templating with cython to avlleviate some of this. ----- Original message ----- > Hi Chris > > Sorry for the delayed response; your message was stuck in Google > Groups moderation. > > On Jun 30, 7:00?am, Chris Ball wrote: > > Some time ago, there was a thread about what color spaces to include > > in > > scikits.image:http://groups.google.com/group/scikits-image/browse_thread/thread/4b4... > > > > I wonder if you would be interested in seeing more color space > > conversions being added to the colorconv.py module, or if you are > > deliberately keeping it simple? For instance, I would like to add > > conversions to and from CIE LAB, and to allow alternative white > > points. > > We are definitely interested in building out the colour space > manipulation.? Chris (Colbert) and I have been discussing the best way > to improve the speed of these conversions, and it may be that we'll > simply rewrite them in Cython. > > Regards > St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.pinto at gmail.com Fri Jul 2 12:11:00 2010 From: nicolas.pinto at gmail.com (Nicolas Pinto) Date: Fri, 2 Jul 2010 11:11:00 -0500 Subject: Color spaces In-Reply-To: <51d89270-10a3-4674-9ad0-2fae8b62b87f@r27g2000yqb.googlegroups.com> References: <51d89270-10a3-4674-9ad0-2fae8b62b87f@r27g2000yqb.googlegroups.com> Message-ID: Hey Chris, I wonder if you would be interested in seeing more color space > conversions being added to the colorconv.py module, or if you are > deliberately keeping it simple? For instance, I would like to add > conversions to and from CIE LAB, and to allow alternative white > points. > +1 on more color conversions! > I'm also interested in seeing conversions to and from human cone LMS > spaces available somewhere for SciPy users. I'm not sure whether or > not this kind of thing would be appropriate for scikits.image. > LMS is definitely interesting. We also have some code around to reproduce other human-like color spaces (e.g. opponent space from Itti & Walther, see Walther's PhD Thesis, Appendix A.2 http://bit.ly/deN6iU), as well as all the color spaces used in Geusebroek & van de Sande (as in http://bit.ly/bKg9nBor http://bit.ly/bYLF21). Would you be interested in these? I'll be happy to add them too. Please feel free to contribute any color space you'd like, possibly using Cython if you need speed. Thanks. Cheers, N > I thought I should first post a short message about this before > starting anything. I'm aware that the SciPy image sandbox used to > contain more conversions, probably in a slightly confusing way > (e.g.http://projects.scipy.org/scipy/browser/trunk/Lib/sandbox/image/ > color.py?rev=1698). > Anyway, please let me know what you think. > > Thanks, > Chris -- Nicolas Pinto Ph.D. Candidate, Brain & Computer Sciences Massachusetts Institute of Technology, USA http://web.mit.edu/pinto -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri Jul 2 18:54:55 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 2 Jul 2010 17:54:55 -0500 Subject: Branch for review Message-ID: Refactoring of ImageCollection to allow more generalised loading (this is needed for a FITS plugin that is being written by James Turner). http://github.com/stefanv/scikits.image/tree/imagecollection From stefan at sun.ac.za Fri Jul 2 20:58:36 2010 From: stefan at sun.ac.za (Stefan van der Walt) Date: Fri, 2 Jul 2010 17:58:36 -0700 (PDT) Subject: Branch for review In-Reply-To: References: Message-ID: I also added the imread_collection slot for plugins. Feedback appreciated. On Jul 2, 5:54?pm, St?fan van der Walt wrote: > Refactoring of ImageCollection to allow more generalised loading (this > is needed for a FITS plugin that is being written by James Turner). > > http://github.com/stefanv/scikits.image/tree/imagecollection From stefan at sun.ac.za Sat Jul 3 10:47:52 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 3 Jul 2010 09:47:52 -0500 Subject: Color spaces In-Reply-To: References: <51d89270-10a3-4674-9ad0-2fae8b62b87f@r27g2000yqb.googlegroups.com> Message-ID: On 3 July 2010 07:13, Ralf Gommers wrote: > More color spaces is good, but it's important to reference everything very > well and also decide on the scaling for float/uint etc. This is a good point, one that Chris and I also discussed yesterday. Here's a proposed guideline: 1. Functions should allow the following types of input images, unless explicitly documented otherwise: float, double uint8 uint16 2. Functions should output the same type of output image, unless explicitly documented otherwise. 3. Floating point images must be [0, 1]. Uint8 images are [0, 255] and Uint16 images [0, 65535]. Does that sound reasonable? We can write a test decorator to ensure that these requirements are upheld. Regards St?fan From sccolbert at gmail.com Sat Jul 3 11:41:49 2010 From: sccolbert at gmail.com (S. Chris Colbert) Date: Sat, 03 Jul 2010 11:41:49 -0400 Subject: Color spaces In-Reply-To: References: <51d89270-10a3-4674-9ad0-2fae8b62b87f@r27g2000yqb.googlegroups.com> Message-ID: <4C2F5A3D.7090307@gmail.com> i would prefer the following types: uint8 int32 float double purely for the fact that a sobel filter must return signed values, and it doesnt make sense to upcast a uint8 to a float. On 07/03/2010 10:47 AM, St??????fan van der Walt wrote: > On 3 July 2010 07:13, Ralf Gommers wrote: > >> More color spaces is good, but it's important to reference everything very >> well and also decide on the scaling for float/uint etc. >> > This is a good point, one that Chris and I also discussed yesterday. > Here's a proposed guideline: > > > 1. Functions should allow the following types of input images, unless > explicitly documented otherwise: > > float, double > uint8 > uint16 > > 2. Functions should output the same type of output image, unless > explicitly documented otherwise. > > 3. Floating point images must be [0, 1]. Uint8 images are [0, 255] > and Uint16 images [0, 65535]. > > Does that sound reasonable? We can write a test decorator to ensure > that these requirements are upheld. > > Regards > St??????fan > From jturner at gemini.edu Sat Jul 3 16:48:48 2010 From: jturner at gemini.edu (James Turner) Date: Sat, 3 Jul 2010 13:48:48 -0700 (PDT) Subject: PyFITS plugin Message-ID: <2ddffbd6-d72d-4c7d-a1b2-9be2c83dec49@g19g2000yqc.googlegroups.com> After bothering Stefan and Chris a lot, I've added a plugin for FITS files and some tests at the sprint, implementing imread() and imread_collection(). Cheers, James. From stefan at sun.ac.za Sat Jul 3 17:35:49 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 3 Jul 2010 16:35:49 -0500 Subject: PyFITS plugin In-Reply-To: <2ddffbd6-d72d-4c7d-a1b2-9be2c83dec49@g19g2000yqc.googlegroups.com> References: <2ddffbd6-d72d-4c7d-a1b2-9be2c83dec49@g19g2000yqc.googlegroups.com> Message-ID: Have a look at James's code here: http://github.com/jehturner/scikits.image/commit/28f5b9faf7d8840b0d120705ad1ea092d1cba9db#diff-4 Cheers St?fan On 3 July 2010 15:48, James Turner wrote: > After bothering Stefan and Chris a lot, I've added a plugin for FITS > files and some tests at the sprint, implementing imread() and > imread_collection(). > > Cheers, > > James. > From ralf.gommers at googlemail.com Sat Jul 3 08:13:04 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 3 Jul 2010 20:13:04 +0800 Subject: Color spaces In-Reply-To: References: <51d89270-10a3-4674-9ad0-2fae8b62b87f@r27g2000yqb.googlegroups.com> Message-ID: On Sat, Jul 3, 2010 at 12:11 AM, Nicolas Pinto wrote: > Hey Chris, > > I wonder if you would be interested in seeing more color space >> conversions being added to the colorconv.py module, or if you are >> deliberately keeping it simple? For instance, I would like to add >> conversions to and from CIE LAB, and to allow alternative white >> points. >> > > +1 on more color conversions! > > >> I'm also interested in seeing conversions to and from human cone LMS >> spaces available somewhere for SciPy users. I'm not sure whether or >> not this kind of thing would be appropriate for scikits.image. >> > > LMS is definitely interesting. We also have some code around to reproduce > other human-like color spaces (e.g. opponent space from Itti & Walther, see > Walther's PhD Thesis, Appendix A.2 http://bit.ly/deN6iU), as well as all > the color spaces used in Geusebroek & van de Sande (as in > http://bit.ly/bKg9nB or http://bit.ly/bYLF21). Would you be interested in > these? I'll be happy to add them too. > > Please feel free to contribute any color space you'd like, possibly using > Cython if you need speed. > > Thanks. > > Cheers, > > N > > >> I thought I should first post a short message about this before >> starting anything. I'm aware that the SciPy image sandbox used to >> contain more conversions, probably in a slightly confusing way >> (e.g.http://projects.scipy.org/scipy/browser/trunk/Lib/sandbox/image/ >> color.py?rev=1698). >> Anyway, please let me know what you think. >> >> When I looked at those I reused only the conversions that were unambiguously defined and did not need to make too many assumptions. We discussed it here: http://groups.google.com/group/scikits-image/browse_thread/thread/4b4e69fd0dbce9cc/7db21c67738edeed?lnk=gst&q=color+spaces#7db21c67738edeed More color spaces is good, but it's important to reference everything very well and also decide on the scaling for float/uint etc. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Sat Jul 3 11:07:46 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 3 Jul 2010 23:07:46 +0800 Subject: Color spaces In-Reply-To: References: <51d89270-10a3-4674-9ad0-2fae8b62b87f@r27g2000yqb.googlegroups.com> Message-ID: 2010/7/3 St?fan van der Walt > On 3 July 2010 07:13, Ralf Gommers wrote: > > More color spaces is good, but it's important to reference everything > very > > well and also decide on the scaling for float/uint etc. > > This is a good point, one that Chris and I also discussed yesterday. > Here's a proposed guideline: > > > 1. Functions should allow the following types of input images, unless > explicitly documented otherwise: > > float, double > uint8 > uint16 > > 2. Functions should output the same type of output image, unless > explicitly documented otherwise. > > 3. Floating point images must be [0, 1]. Uint8 images are [0, 255] > and Uint16 images [0, 65535]. > > Does that sound reasonable? We can write a test decorator to ensure > that these requirements are upheld. > > Clear guidelines and as little magic behind the scenes sounds good to me. Some separate type conversion / scaling utilities may be useful to provide. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Thu Jul 15 01:13:54 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 15 Jul 2010 07:13:54 +0200 Subject: Fwd: OpenCV In-Reply-To: References: Message-ID: Hi Michael I'm re-posting your question to the mailing list. Hopefully Chris or someone else familiar with the OpenCV functionality will be able to answer. Kind regards St?fan ---------- Forwarded message ---------- Hi Stefan, I made it work eventually. But found a problem: cvSmooth does not work for BILATERAL filtering. If param3 and param4 are 0, just a black image is returned (even so param3 and 4 are not required for BILATERAL, and if they are set to values !=0, the source image is being returned. :( Does it work for you? On top of that I am not even able to submit a bug to OpenCV, because the ros account I had to create as mentioned here: https://code.ros.org/trac/opencv does not let me log into Trac, so I can't open a new bug. Weird... Best regards, Michael _____________________________ Universit?t Bern Physikalisches Institut Space and Planetary Sciences K.-Michael Aye, PhD BELA Assistant Project Manager From sccolbert at gmail.com Thu Jul 15 08:30:31 2010 From: sccolbert at gmail.com (S. Chris Colbert) Date: Thu, 15 Jul 2010 08:30:31 -0400 Subject: Fwd: OpenCV In-Reply-To: References: Message-ID: <4C3EFF67.7090104@gmail.com> Well, first things first. The scikits.image wrappers wrap the C interface to the OpenCV library, and there is no such thing as an optional argument in C, so param3 and 4 are required to be passed to the C layer (although they all have default kwargs at the Python layer). And the bi-lateral filter DOES require params 3 and 4 as they are the standard deviations of the filter. A look at the docs for that function describes what the parameters should be: http://stefanv.github.com/scikits.image/api/scikits.image.opencv.html#cvsmooth That said, a quick google will reveal that this is indeed an OpenCV issue: e.g. http://forum.visionopen.com/viewtopic.php?f=31&t=4243 Cheers! Chris On 07/15/2010 01:13 AM, St??????fan van der Walt wrote: > Hi Michael > > I'm re-posting your question to the mailing list. Hopefully Chris or > someone else familiar with the OpenCV functionality will be able to > answer. > > Kind regards > St??????fan > > ---------- Forwarded message ---------- > Hi Stefan, > > I made it work eventually. > But found a problem: > cvSmooth does not work for BILATERAL filtering. If param3 and param4 > are 0, just a black image is returned (even so param3 and 4 are not > required for BILATERAL, and if they are set to values !=0, the source > image is being returned. :( > > Does it work for you? > > On top of that I am not even able to submit a bug to OpenCV, because > the ros account I had to create as mentioned here: > https://code.ros.org/trac/opencv > does not let me log into Trac, so I can't open a new bug. Weird... > > Best regards, > Michael > > _____________________________ > Universit??????t Bern > Physikalisches Institut > Space and Planetary Sciences > > K.-Michael Aye, PhD > BELA Assistant Project Manager