RE: Help-octave Digest, Vol 60, Issue 34

[Vitaly Boyko]

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
> *******************************************