You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(8) 
_{Nov}
(8) 
_{Dec}
(4) 

2002 
_{Jan}
(53) 
_{Feb}
(15) 
_{Mar}
(51) 
_{Apr}
(54) 
_{May}
(41) 
_{Jun}
(48) 
_{Jul}
(32) 
_{Aug}
(22) 
_{Sep}
(61) 
_{Oct}
(31) 
_{Nov}
(31) 
_{Dec}
(27) 
2003 
_{Jan}
(45) 
_{Feb}
(18) 
_{Mar}
(25) 
_{Apr}
(39) 
_{May}
(34) 
_{Jun}
(20) 
_{Jul}
(13) 
_{Aug}
(16) 
_{Sep}
(18) 
_{Oct}
(14) 
_{Nov}
(17) 
_{Dec}
(13) 
2004 
_{Jan}
(53) 
_{Feb}
(12) 
_{Mar}
(38) 
_{Apr}
(29) 
_{May}
(72) 
_{Jun}
(38) 
_{Jul}
(41) 
_{Aug}
(11) 
_{Sep}
(21) 
_{Oct}
(30) 
_{Nov}
(35) 
_{Dec}
(14) 
2005 
_{Jan}
(66) 
_{Feb}
(14) 
_{Mar}
(24) 
_{Apr}
(50) 
_{May}
(40) 
_{Jun}
(29) 
_{Jul}
(37) 
_{Aug}
(27) 
_{Sep}
(26) 
_{Oct}
(58) 
_{Nov}
(43) 
_{Dec}
(23) 
2006 
_{Jan}
(84) 
_{Feb}
(36) 
_{Mar}
(24) 
_{Apr}
(42) 
_{May}
(20) 
_{Jun}
(41) 
_{Jul}
(40) 
_{Aug}
(42) 
_{Sep}
(23) 
_{Oct}
(38) 
_{Nov}
(31) 
_{Dec}
(28) 
2007 
_{Jan}
(11) 
_{Feb}
(34) 
_{Mar}
(14) 
_{Apr}
(29) 
_{May}
(45) 
_{Jun}
(5) 
_{Jul}
(10) 
_{Aug}
(6) 
_{Sep}
(38) 
_{Oct}
(44) 
_{Nov}
(19) 
_{Dec}
(22) 
2008 
_{Jan}
(37) 
_{Feb}
(24) 
_{Mar}
(29) 
_{Apr}
(14) 
_{May}
(24) 
_{Jun}
(47) 
_{Jul}
(26) 
_{Aug}
(4) 
_{Sep}
(14) 
_{Oct}
(45) 
_{Nov}
(25) 
_{Dec}
(16) 
2009 
_{Jan}
(33) 
_{Feb}
(34) 
_{Mar}
(45) 
_{Apr}
(45) 
_{May}
(30) 
_{Jun}
(47) 
_{Jul}
(37) 
_{Aug}
(19) 
_{Sep}
(15) 
_{Oct}
(16) 
_{Nov}
(24) 
_{Dec}
(31) 
2010 
_{Jan}
(32) 
_{Feb}
(25) 
_{Mar}
(12) 
_{Apr}
(5) 
_{May}
(2) 
_{Jun}
(9) 
_{Jul}
(31) 
_{Aug}
(10) 
_{Sep}
(12) 
_{Oct}
(20) 
_{Nov}
(6) 
_{Dec}
(41) 
2011 
_{Jan}
(23) 
_{Feb}
(8) 
_{Mar}
(41) 
_{Apr}
(8) 
_{May}
(15) 
_{Jun}
(10) 
_{Jul}
(8) 
_{Aug}
(14) 
_{Sep}
(16) 
_{Oct}
(13) 
_{Nov}
(15) 
_{Dec}
(8) 
2012 
_{Jan}
(6) 
_{Feb}
(14) 
_{Mar}
(22) 
_{Apr}
(40) 
_{May}
(27) 
_{Jun}
(18) 
_{Jul}
(2) 
_{Aug}
(6) 
_{Sep}
(10) 
_{Oct}
(32) 
_{Nov}
(5) 
_{Dec}
(2) 
2013 
_{Jan}
(14) 
_{Feb}
(2) 
_{Mar}
(15) 
_{Apr}
(2) 
_{May}
(6) 
_{Jun}
(7) 
_{Jul}
(25) 
_{Aug}
(6) 
_{Sep}
(3) 
_{Oct}

_{Nov}
(8) 
_{Dec}

2014 
_{Jan}
(3) 
_{Feb}
(3) 
_{Mar}
(3) 
_{Apr}

_{May}
(19) 
_{Jun}
(6) 
_{Jul}
(1) 
_{Aug}
(4) 
_{Sep}
(18) 
_{Oct}
(5) 
_{Nov}
(1) 
_{Dec}

2015 
_{Jan}
(2) 
_{Feb}
(4) 
_{Mar}
(2) 
_{Apr}
(1) 
_{May}
(17) 
_{Jun}
(1) 
_{Jul}

_{Aug}
(2) 
_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}
(11) 
2016 
_{Jan}
(10) 
_{Feb}
(6) 
_{Mar}
(14) 
_{Apr}

_{May}
(2) 
_{Jun}
(5) 
_{Jul}

_{Aug}

_{Sep}
(3) 
_{Oct}
(1) 
_{Nov}
(1) 
_{Dec}

S  M  T  W  T  F  S 




1

2

3
(2) 
4

5

6
(2) 
7

8

9

10

11

12

13

14

15

16

17
(3) 
18

19
(1) 
20

21
(2) 
22
(10) 
23

24

25
(2) 
26
(1) 
27
(2) 
28
(1) 
29
(3) 
30
(2) 


From: Ian Scott <ian.m.scott@st...>  20061117 09:57:26

Tamir Yedidya wrote: > > Hi, > > I'm trying to use vnl_levenberg_marquardt in order to fit a circle to an > image. So, I'm having 3 parameters (x,y,r). > My initial guess is usually quite good. For example , my estimation can > be (157,157,100) and the best fit is (150,150,100). > > However, I found out that when using the default settings the algorithm > will converge to the initial guess. > I've tried setting the epsilon_function to 0.005 or higher values and > then the estimates start moving, the algorithm converges, > but not always to the correct answer. Then, on different settings I > might have to set the epsilon_function > to a different value for the algorithm to converge to the right value. > > My question is whether this is the right thing to do  setting epsilon? > or maybe the default parameters should > be good enough and the problem is with the cost function? If you have problems with a standard optimiser, the first place to look is always the cost function. In this case it is (the residual sum of squares) along all three axes. It is also worth plotting 2D surfaces from the response due to pairs of parameters. Since you are using a residualsbased optimiser, it is also worth checking that your residual behave correctly. Pick a residual vector r_1 at some position x_1, and then plot the projection of the residual onto r_1, for different parameter values. This way you get to see if your residual is behaving vaguely linearly around the minimum. Repeat for several different x_1. You may also need to look at the cost function at various scales of changes in the parameters. A function that looks smooth at x_0=[3:0.1:3] might start to look very noisy and noncontinuous at much smaller scales x_0=[3e4:1e5:3e4]. A useful compromise is to have a bilog scale in x. x=3; while (x < 1e5) { x=x/1.2; plot f(x); } x=1e5; while (x < 3) { x=x*1.2; plot f(x); } Whether you are explicitly calculating the Jacobian (rather than letting the cost function calculate it using finite differences), you may also need to check that your gradients behave correctly. Again, pick a gradient g_1 at a given x_1, and plot the magnitude of gradient for different x, projected onto g_1. Again repeat for different x_1. Finally (although it should have been first)  try the amoeba first. The amoeba is the most robust, hasslefree, reliable optimiser about. After it works, you can worry about using a faster optimiser (if speed turns out to be a problem.) By this time you will understand a lot more about your optimisation problem, allowing you to make more intelligent choices. Ian. 
From: Tamir Yedidya <ty7777@gm...>  20061117 02:44:04

Hi, I'm trying to use vnl_levenberg_marquardt in order to fit a circle to an image. So, I'm having 3 parameters (x,y,r). My initial guess is usually quite good. For example , my estimation can be (157,157,100) and the best fit is (150,150,100). However, I found out that when using the default settings the algorithm will converge to the initial guess. I've tried setting the epsilon_function to 0.005 or higher values and then the estimates start moving, the algorithm converges, but not always to the correct answer. Then, on different settings I might have to set the epsilon_function to a different value for the algorithm to converge to the right value. My question is whether this is the right thing to do  setting epsilon? or maybe the default parameters should be good enough and the problem is with the cost function? Thanks, Tamir 
From: Ian Scott <ian.m.scott@st...>  20061106 09:13:58

Alois Komenda wrote: > Hi > > Maybe my question 1) can be misunderstood easily. > In generally I want to know how to access an amount of pixels of an image in the fastest way. Is vil_image_view img(i, j) designed to use it in a loop to get the values of a big amount of pixels? Or is there any way to read a line/block/... and put the values in an array? The answer is no. However, whilst your question makes sense in itself, it is hard to answer meaningfully. If you are used to a language like Matlab, you may be used to vectorising all your code. But generally it doesn't make sense in C++. Operator(i,j) is not slow. On an optimising compiler, it will be inlined  making it the fasted possible way to randomlyaccess pixel locations in your image. There is no faster way to read a arbitrary randomaccess list of pixel locations, than writing the loop yourself. This is the nature of C++ (and libraries such as VXL which exploit C++'s main paradigms.) To reiterate my previous email, you can work a little faster if you are accessing the image in a structured fashion, by directly using the underlying pointer arithmetic which accesses an image. But since the structure of accesses depends on your application, there is no point in writing a library function to speed up such accesses. Ian. > > So, maybe this says it best: > How to read out more than one pixel with only one library call? > > Best regards > > Alois > >  OriginalNachricht  > Datum: Fri, 03 Nov 2006 14:39:33 +0000 > Von: Ian Scott <ian.m.scott@...> > An: Alois Komenda <AluKomenda@...> > Betreff: Re: [Vxlusers] Access an image in blocks > >> Alois Komenda wrote: >>> Hello >>> >>> I've got some questions: >>> >>> 1) I have to calculate a value for each pixel of an picture using the >> values of its environment (at least a 3x3environment, more likely 5x5). Is >> there a way to access the required pixels in a block mode to speed up the >> calculation? >> >> >> you can precalculate the offsets to a regular neighbourhood of pixels. >> In vil_image_view im1 >> ........... >> .....ABC... >> .....DEF... >> .....GHI... >> ........... >> >> where the pixel at A is at memory address ptr_a, >> then the memory addresses of positions of the other labelled pixels are >> ptr_b = ptr_a + ( im1.istep()); >> ptr_c = ptr_a + (2*im1.istep()); >> ptr_d = ptr_a + ( im1.jstep()); >> ptr_e = ptr_a + ( im1.istep() + im1.jstep()); >> ptr_f = ptr_a + (2*im1.istep() + im1.jstep()); >> ptr_g = ptr_a + ( 2*im1.jstep()); >> ptr_h = ptr_a + ( im1.istep() + 2*im1.jstep()); >> ptr_i = ptr_a + (2*im1.istep() + 2*im1.jstep()); >> >> The terms in the brackets can be precalculated for any given image (or >> indeed for any image with identical memory layout.) >> >> >>> 2) Is there a function to build a quadtree of an image available? >> A simple search at http://www.isbe.man.ac.uk/search_vxl.html fails to >> find any. >> >>> 3) Are there methods for classification like minimum distance in vxl? >> You may have some specific meaning of classification in mind other than >> "statistical classification", since I am not aware of any standard >> technique called "minimum distance". >> >> However, you can find a range of statistical classifiers in the >> contrib/mul/clsfy library, described in >> http://paine.wiau.man.ac.uk/pub/doc_vxl/contrib/mul/clsfy/html/hierarchy.html >> >> Ian. > 
From: Alois Komenda <AluKomenda@gm...>  20061106 08:56:45

Hi Maybe my question 1) can be misunderstood easily. In generally I want to know how to access an amount of pixels of an image in the fastest way. Is vil_image_view img(i, j) designed to use it in a loop to get the values of a big amount of pixels? Or is there any way to read a line/block/... and put the values in an array? So, maybe this says it best: How to read out more than one pixel with only one library call? Best regards Alois  OriginalNachricht  Datum: Fri, 03 Nov 2006 14:39:33 +0000 Von: Ian Scott <ian.m.scott@...> An: Alois Komenda <AluKomenda@...> Betreff: Re: [Vxlusers] Access an image in blocks > Alois Komenda wrote: > > Hello > > > > I've got some questions: > > > > 1) I have to calculate a value for each pixel of an picture using the > values of its environment (at least a 3x3environment, more likely 5x5). Is > there a way to access the required pixels in a block mode to speed up the > calculation? > > > you can precalculate the offsets to a regular neighbourhood of pixels. > In vil_image_view im1 > ........... > .....ABC... > .....DEF... > .....GHI... > ........... > > where the pixel at A is at memory address ptr_a, > then the memory addresses of positions of the other labelled pixels are > ptr_b = ptr_a + ( im1.istep()); > ptr_c = ptr_a + (2*im1.istep()); > ptr_d = ptr_a + ( im1.jstep()); > ptr_e = ptr_a + ( im1.istep() + im1.jstep()); > ptr_f = ptr_a + (2*im1.istep() + im1.jstep()); > ptr_g = ptr_a + ( 2*im1.jstep()); > ptr_h = ptr_a + ( im1.istep() + 2*im1.jstep()); > ptr_i = ptr_a + (2*im1.istep() + 2*im1.jstep()); > > The terms in the brackets can be precalculated for any given image (or > indeed for any image with identical memory layout.) > > > > > > 2) Is there a function to build a quadtree of an image available? > > A simple search at http://www.isbe.man.ac.uk/search_vxl.html fails to > find any. > > > > > 3) Are there methods for classification like minimum distance in vxl? > > You may have some specific meaning of classification in mind other than > "statistical classification", since I am not aware of any standard > technique called "minimum distance". > > However, you can find a range of statistical classifiers in the > contrib/mul/clsfy library, described in > http://paine.wiau.man.ac.uk/pub/doc_vxl/contrib/mul/clsfy/html/hierarchy.html > > Ian.  Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer 
From: Ian Scott <ian.m.scott@st...>  20061103 14:39:48

Alois Komenda wrote: > Hello > > I've got some questions: > > 1) I have to calculate a value for each pixel of an picture using the values of its environment (at least a 3x3environment, more likely 5x5). Is there a way to access the required pixels in a block mode to speed up the calculation? you can precalculate the offsets to a regular neighbourhood of pixels. In vil_image_view im1 ........... .....ABC... .....DEF... .....GHI... ........... where the pixel at A is at memory address ptr_a, then the memory addresses of positions of the other labelled pixels are ptr_b = ptr_a + ( im1.istep()); ptr_c = ptr_a + (2*im1.istep()); ptr_d = ptr_a + ( im1.jstep()); ptr_e = ptr_a + ( im1.istep() + im1.jstep()); ptr_f = ptr_a + (2*im1.istep() + im1.jstep()); ptr_g = ptr_a + ( 2*im1.jstep()); ptr_h = ptr_a + ( im1.istep() + 2*im1.jstep()); ptr_i = ptr_a + (2*im1.istep() + 2*im1.jstep()); The terms in the brackets can be precalculated for any given image (or indeed for any image with identical memory layout.) > > 2) Is there a function to build a quadtree of an image available? A simple search at http://www.isbe.man.ac.uk/search_vxl.html fails to find any. > > 3) Are there methods for classification like minimum distance in vxl? You may have some specific meaning of classification in mind other than "statistical classification", since I am not aware of any standard technique called "minimum distance". However, you can find a range of statistical classifiers in the contrib/mul/clsfy library, described in http://paine.wiau.man.ac.uk/pub/doc_vxl/contrib/mul/clsfy/html/hierarchy.html Ian. 
From: Alois Komenda <AluKomenda@gm...>  20061103 14:13:52

Hello I've got some questions: 1) I have to calculate a value for each pixel of an picture using the values of its environment (at least a 3x3environment, more likely 5x5). Is there a way to access the required pixels in a block mode to speed up the calculation? 2) Is there a function to build a quadtree of an image available? 3) Are there methods for classification like minimum distance in vxl?  GMX DSLFlatrate 0, Euro*  Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl 