|
From: | Vitaly Boyko |
Subject: | RE: Help-octave Digest, Vol 60, Issue 34 |
Date: | Tue, 15 Mar 2011 23:42:31 -0400 |
Dear List, I am new to Octave and image processing. I am looking for your thoughts on a possible "adaptation" of dipimage (www.diplib.org) to the Octave platform. Also, I would like to know who would be a prime contact on quantitative image analysis with subpixel/subvoxel accuracy. Your feedback would be greatly appreciated. Many thanks in advance, Vitaly Vitaly P. Boyko, Ph.D. Germantown, MD 20874 301-515-7833 > From: address@hidden > Subject: Help-octave Digest, Vol 60, Issue 34 > To: address@hidden > Date: Tue, 15 Mar 2011 16:42:49 -0500 > > Send Help-octave mailing list submissions to > address@hidden > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.cae.wisc.edu/listinfo/help-octave > or, via email, send a message with subject or body 'help' to > address@hidden > > You can reach the person managing the list at > address@hidden > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Help-octave digest..." > > > Today's Topics: > > 1. error: memory exhausted or requested size too large for range > of Octave's index type -- (nuncio m) > 2. Re: Inflection Point Detection (aegreen) > 3. Re: error: memory exhausted or requested size too large for > range of Octave's index type -- (Przemek Klosowski) > 4. Re: [OctDev] Is this a bug? (Philip Nienhuis) > 5. Re: error: memory exhausted or requested size too large for > range of Octave's index type -- (Martin Helm) > 6. Re: Inflection Point Detection (Doug Stewart) > 7. Re: Can't get griddata3 to work (mph2) > 8. Re: error: memory exhausted or requested size too large for > range of Octave's index type -- (Przemek Klosowski) > 9. Re: error: memory exhausted or requested size too large for > range of Octave's index type -- (c.) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 15 Mar 2011 22:35:44 +0530 > From: nuncio m <address@hidden> > To: address@hidden > Subject: error: memory exhausted or requested size too large for range > of Octave's index type -- > Message-ID: > <address@hidden> > Content-Type: text/plain; charset="iso-8859-1" > > Hi list, > Here is the code I am trying to do a PCA analysis > > filename='test_eof.txt'; > oufile='pc.txt'; > data="">> data1=reshape(data,25200,132); > data2=data1'; > f=detrend(data2,0); > R=f'*f; > [C,L]=eig(R); > pc1=f*C(:,1); > pc2=f*C(:,2); > fid=fopen(oufile,"wt"); > fprintf(fid,'%10.3f \n',pc1); > fclose(fid); > The code never completes the computation, it shows an error "error: > memory exhausted or requested size too large for range of Octave's index > type -- trying to return to prompt" > Can anyone suggest where it goes wrong. > Thanks > Nuncio > > > > > -- > Nuncio.M > Research Scientist > National Center for Antarctic and Ocean research > Head land Sada > Vasco da Gamma > Goa-403804 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://mailman.cae.wisc.edu/pipermail/help-octave/attachments/20110315/2387e991/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Tue, 15 Mar 2011 11:14:04 -0700 (PDT) > From: aegreen <address@hidden> > To: address@hidden > Subject: Re: Inflection Point Detection > Message-ID: <address@hidden> > Content-Type: text/plain; charset=us-ascii > > > bpabbott wrote: > > > > pp = spline (x,y); > > pp2 = ppder (ppder (pp)); > > d2y_by_dx2 = ppval (pp2, x); > > n = find (abs (d2y_by_dx2) == max (abs (d2y_by_dx2))); > > x_inflection = x(n) > > > > Thanks Ben that works great! > > I apologize though, typically my data though doesn't have such a discrete > inflection point as I had indicated in the above graph. Is there some way to > use a least squared approach with a piecewise function? > > I have inserted an image of the data that I am trying to find an inflection > point in (blue) and the data after it's been filtered with a third order > butterworth filter with a cut off frequency of 0.1Hz, so that you can get an > idea of what I am trying to do. > > This problem has been stumping me for months so any thoughts or suggestions > even would be really appreciated, since I understand this is a little > outside the realm of this forum. > > http://octave.1599824.n4.nabble.com/file/n3357323/VE.jpeg > > -- > View this message in context: http://octave.1599824.n4.nabble.com/Inflection-Point-Detection-tp3355507p3357323.html > Sent from the Octave - General mailing list archive at Nabble.com. > > > ------------------------------ > > Message: 3 > Date: Tue, 15 Mar 2011 14:22:59 -0400 > From: Przemek Klosowski <address@hidden> > To: address@hidden > Subject: Re: error: memory exhausted or requested size too large for > range of Octave's index type -- > Message-ID: <address@hidden> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 03/15/2011 01:05 PM, nuncio m wrote: > > Hi list, > > Here is the code I am trying to do a PCA analysis > > > > filename='test_eof.txt'; > > oufile='pc.txt'; > > data="">> > data1=reshape(data,25200,132); > > data2=data1'; > > f=detrend(data2,0); > > R=f'*f; > > Your data seems to be of the size 132x25200, and you are essentially > building an array 25200x25200, which would be 5GB in size. If that's > what you really need, you have to get a 64-bit octave and enough > physical memory to match. > > > ------------------------------ > > Message: 4 > Date: Tue, 15 Mar 2011 19:44:19 +0100 > From: Philip Nienhuis <address@hidden> > To: tesi t <address@hidden> > Cc: address@hidden, address@hidden > Subject: Re: [OctDev] Is this a bug? > Message-ID: <address@hidden> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > tesi t wrote: > > > Please post these general Octave questions to the appropriate forum, > i.e., help-octave ML rather than octave-forge ML. > Octave-forge has nothing to do with this particular issue, other than > hosting a Windows octave-3.2.4 binary. > > Read on.... > > > In Octave Forge (i.e. Octave 3.2.4) I type: > > > > > vector = [1 2 3 4 5] > > > [vector; zeros(1,8-8)] > > > > Then I get this answer: > > *error: number of columns must match (0 != 5)* > > > > Now, if I type: > > > zeros(1,8-8) > > > [vector; []] > > > > I got the correct answer: > > *ans = 1 2 3 4 5* > > > > Matlab doesn't complains about the first two lines and gives the correct > > answer. > > ...correct? > > octave-3.3.91.exe:7> vector = [1 2 3 4 5] > vector = > > 1 2 3 4 5 > > octave-3.3.91.exe:8> [vector; zeros(1,8-8)] > ans = > > 1 2 3 4 5 > > So yes, newer Octave versions do what you apparently want. > > But whether this was a bug or not, I can't say for sure. > Either way, the dimensions of the upper and lower row you want to create > don't match, no matter if the lower row is essentially void or not. > > IMO it isn't very "clean" code but I can imagine that similar code can > be generated in scripts. > > P. > > > ------------------------------ > > Message: 5 > Date: Tue, 15 Mar 2011 19:43:16 +0100 > From: Martin Helm <address@hidden> > To: address@hidden > Cc: nuncio m <address@hidden> > Subject: Re: error: memory exhausted or requested size too large for > range of Octave's index type -- > Message-ID: <address@hidden> > Content-Type: Text/Plain; charset="iso-8859-15" > > Am Dienstag, 15. M?rz 2011, 18:05:44 schrieb nuncio m: > > Hi list, > > Here is the code I am trying to do a PCA analysis > > > > filename='test_eof.txt'; > > oufile='pc.txt'; > > data="">> > data1=reshape(data,25200,132); > > data2=data1'; > > f=detrend(data2,0); > > R=f'*f; > > [C,L]=eig(R); > > pc1=f*C(:,1); > > pc2=f*C(:,2); > > fid=fopen(oufile,"wt"); > > fprintf(fid,'%10.3f \n',pc1); > > fclose(fid); > > The code never completes the computation, it shows an error "error: > > memory exhausted or requested size too large for range of Octave's index > > type -- trying to return to prompt" > > Can anyone suggest where it goes wrong. > > Thanks > > Nuncio > > Not a problem at all with 32 bit octave if you use version 3.4 since only the > index is limited to 2e9 not the bytesize of the array. An array can have up to > 16 GB (if you have enough RAM + Swap). > With version 3.2 of course this does not work for the 32 bit version. > > Which version of octave is that what you are using and which operating system? > It is probably easy to update. > > > ------------------------------ > > Message: 6 > Date: Tue, 15 Mar 2011 14:51:38 -0400 > From: Doug Stewart <address@hidden> > To: aegreen <address@hidden> > Cc: address@hidden > Subject: Re: Inflection Point Detection > Message-ID: > <address@hidden> > Content-Type: text/plain; charset="iso-8859-1" > > On Tue, Mar 15, 2011 at 2:14 PM, aegreen <address@hidden> wrote: > > > > > bpabbott wrote: > > > > > > pp = spline (x,y); > > > pp2 = ppder (ppder (pp)); > > > d2y_by_dx2 = ppval (pp2, x); > > > n = find (abs (d2y_by_dx2) == max (abs (d2y_by_dx2))); > > > x_inflection = x(n) > > > > > > > Thanks Ben that works great! > > > > I apologize though, typically my data though doesn't have such a discrete > > inflection point as I had indicated in the above graph. Is there some way > > to > > use a least squared approach with a piecewise function? > > > > I have inserted an image of the data that I am trying to find an inflection > > point in (blue) and the data after it's been filtered with a third order > > butterworth filter with a cut off frequency of 0.1Hz, so that you can get > > an > > idea of what I am trying to do. > > > > This problem has been stumping me for months so any thoughts or suggestions > > even would be really appreciated, since I understand this is a little > > outside the realm of this forum. > > > > http://octave.1599824.n4.nabble.com/file/n3357323/VE.jpeg > > > > -- > > View this message in context: > > http://octave.1599824.n4.nabble.com/Inflection-Point-Detection-tp3355507p3357323.html > > Sent from the Octave - General mailing list archive at Nabble.com. > > _______________________________________________ > > Help-octave mailing list > > address@hidden > > https://mailman.cae.wisc.edu/listinfo/help-octave > > > > > > This is just some ideas that might help. Maybe you have tried it. > > If you take the filtered data and curve fit a quadratic to each set of 3 > points starting at one end, and then look at the coefficients of each > quadratic formula then you should see the points where the quadratic changes > from being "open up to open down". This change would be an inflection point. > > I hope this is helpful. > > Doug > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://mailman.cae.wisc.edu/pipermail/help-octave/attachments/20110315/9e5707b3/attachment-0001.html> > > ------------------------------ > > Message: 7 > Date: Tue, 15 Mar 2011 13:00:54 -0700 (PDT) > From: mph2 <address@hidden> > To: address@hidden > Subject: Re: Can't get griddata3 to work > Message-ID: <address@hidden> > Content-Type: text/plain; charset=us-ascii > > Great answer, thanks a lot! > A silly error, obvious in retrospect, but I couldn't visualize what was > going on. The trigraph really helped. > > In effect I didn't make my x,y,z grid correctly: sorting made all the x,y,z > points almost arrange on a line, so the values at almost all the xi,yi,zi > would require extrapolation. > > > > -- > View this message in context: http://octave.1599824.n4.nabble.com/Can-t-get-griddata3-to-work-tp3355554p3357623.html > Sent from the Octave - General mailing list archive at Nabble.com. > > > ------------------------------ > > Message: 8 > Date: Tue, 15 Mar 2011 17:04:15 -0400 > From: Przemek Klosowski <address@hidden> > To: address@hidden > Subject: Re: error: memory exhausted or requested size too large for > range of Octave's index type -- > Message-ID: <address@hidden> > Content-Type: text/plain; charset=ISO-8859-15; format=flowed > > On 03/15/2011 02:43 PM, Martin Helm wrote: > > > Not a problem at all with 32 bit octave if you use version 3.4 since only the > > index is limited to 2e9 not the bytesize of the array. An array can have up to > > 16 GB (if you have enough RAM + Swap). > > I don't understand that---in a 32-bit environment, the virtual address > of each process is limited to 32 bits i.e. 4GB. It's true that you can > have multiple processes, each with 32-bit address space, that span > 36-bit (64GB) physical memory, but that doesn't help octave. > > p.klosowski > > > ------------------------------ > > Message: 9 > Date: Tue, 15 Mar 2011 22:42:33 +0100 > From: "c." <address@hidden> > To: Przemek Klosowski <address@hidden> > Cc: address@hidden > Subject: Re: error: memory exhausted or requested size too large for > range of Octave's index type -- > Message-ID: <address@hidden> > Content-Type: text/plain; charset=us-ascii > > > On 15 Mar 2011, at 22:04, Przemek Klosowski wrote: > > > On 03/15/2011 02:43 PM, Martin Helm wrote: > > > >> Not a problem at all with 32 bit octave if you use version 3.4 since only the > >> index is limited to 2e9 not the bytesize of the array. An array can have up to > >> 16 GB (if you have enough RAM + Swap). > > > > I don't understand that---in a 32-bit environment, the virtual address of each process is limited to 32 bits i.e. 4GB. It's true that you can have multiple processes, each with 32-bit address space, that span 36-bit (64GB) physical memory, but that doesn't help octave. > > I think what Martin meant is that you can compile a 64bit version of octave whithout enabling 64bit integer indices > so the process will be able to allocate more than 4GB even though the maximum size of any single array will still be limited. > > > p.klosowski > c. > > ------------------------------ > > _______________________________________________ > Help-octave mailing list > address@hidden > https://mailman.cae.wisc.edu/listinfo/help-octave > > > End of Help-octave Digest, Vol 60, Issue 34 > ******************************************* |
[Prev in Thread] | Current Thread | [Next in Thread] |