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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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: [hidden email]

> Subject: Help-octave Digest, Vol 60, Issue 34
> To: [hidden email]
> Date: Tue, 15 Mar 2011 16:42:49 -0500
>
> Send Help-octave mailing list submissions to
> [hidden email]
>
> 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
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> 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 <[hidden email]>
> To: [hidden email]
> Subject: error: memory exhausted or requested size too large for range
> of Octave's index type --
> Message-ID:
> <AANLkTi=[hidden email]>
> 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=load(filename);
> 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 <[hidden email]>
> To: [hidden email]
> Subject: Re: Inflection Point Detection
> Message-ID: <[hidden email]>
> 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 <[hidden email]>
> To: [hidden email]
> Subject: Re: error: memory exhausted or requested size too large for
> range of Octave's index type --
> Message-ID: <[hidden email]>
> 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=load(filename);
> > 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 <[hidden email]>
> To: tesi t <[hidden email]>
> Cc: [hidden email], [hidden email]
> Subject: Re: [OctDev] Is this a bug?
> Message-ID: <[hidden email]>
> 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 <[hidden email]>
> To: [hidden email]
> Cc: nuncio m <[hidden email]>
> Subject: Re: error: memory exhausted or requested size too large for
> range of Octave's index type --
> Message-ID: <[hidden email]>
> 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=load(filename);
> > 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 <[hidden email]>
> To: aegreen <[hidden email]>
> Cc: [hidden email]
> Subject: Re: Inflection Point Detection
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, Mar 15, 2011 at 2:14 PM, aegreen <[hidden email]> 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
> > [hidden email]
> > 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 <[hidden email]>
> To: [hidden email]
> Subject: Re: Can't get griddata3 to work
> Message-ID: <[hidden email]>
> 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 <[hidden email]>
> To: [hidden email]
> Subject: Re: error: memory exhausted or requested size too large for
> range of Octave's index type --
> Message-ID: <[hidden email]>
> 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." <[hidden email]>
> To: Przemek Klosowski <[hidden email]>
> Cc: [hidden email]
> Subject: Re: error: memory exhausted or requested size too large for
> range of Octave's index type --
> Message-ID: <[hidden email]>
> 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
> [hidden email]
> https://mailman.cae.wisc.edu/listinfo/help-octave
>
>
> End of Help-octave Digest, Vol 60, Issue 34
> *******************************************
Reply | Threaded
Open this post in threaded view
|

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

c.-2

On 16 Mar 2011, at 04:42, Vitaly Boyko wrote:

>
> I am looking for your thoughts on a possible "adaptation" of dipimage (www.diplib.org) to the Octave platform.

I doubt it will be possible with this license:
http://www.diplib.org/license

c.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

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

Jordi Gutiérrez Hermoso
In reply to this post by Vitaly Boyko
On 15 March 2011 21:42, Vitaly Boyko <[hidden email]> wrote:

> I am looking for your thoughts on a possible "adaptation" of dipimage
> (www.diplib.org) to the Octave platform.

Doesn't look likely nor necessary.

As "c." has indicated, the license is unacceptable for Octave. It
discriminates between fields of endavour and doesn't provide source
code, thus not qualifying as free software. You may use it for
yourself if you find its licensing terms acceptable, even link it with
Octave if you figure out how, but the GPL does not allow distributing
the resulting binaries. I don't think, however, that you should
encourage the project's creators by using their software until they
are amenable to a license change.

But moreover, from a brief scan of the project's website, it doesn't
seem to do anything that Octave doesn't do (or couldn't do with a
little bit of work). Skimming its manual, it seems to be its own
graphical environment that happens to be linkable with Matlab, but I
didn't see it have any actual image processing abilities that Octave
doesn't do.

I have recently been comissioned to write some missing image
processing functions for Octave, and while I'm there, I may be able to
help implement a few more missing functions. Take a look at the image
Octave-Forge package, and if there's something that you think is
missing there, let me know, and I might also implement it:

     http://octave.sourceforge.net/image/overview.html

HTH,
- Jordi G. H.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

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

skaki
Hi Jordi, thanks for your work!! I'm trying to implement a code for colocalization analysis of microscopic images. I was wondering if there is a function to align two images that could be between 1< - 3 pixels unaligned.
Thanks again, José.
Reply | Threaded
Open this post in threaded view
|

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

Terry Duell
On Tue, 06 Sep 2011 04:17:46 +1000, skaki <[hidden email]> wrote:

> Hi Jordi, thanks for your work!! I'm trying to implement a code for
> colocalization analysis of microscopic images. I was wondering if there  
> is a
> function to align two images that could be between 1< - 3 pixels  
> unaligned.

Sorry to butt in, but I have seen Matlab code that implements the  
algorithm described in
Manuel Guizar-Sicairos, Samuel T. Thurman, and James R. Fienup,
"Efficient subpixel image registration algorithms," Opt. Lett. 33,
156-158 (2008).

The code was available for download, but I no longer have a reference to  
the URL. A search for the paper may lead you to it.

Cheers,
--
Regards,
Terry Duell
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave