octave-dev — GNU Octave developers' list

[OctDev] Introducing poly2mask

[Josep i T. <jm...@pu...>]

Hi,

Let me introduce you poly2mask, which creates a mask from a vertex
representation of a polygon.

I've tweaked a little bit the algorithm in
http://www.cs.rit.edu/~icss571/filling/ in order to behave in a similar
way as the only MATLAB example I found, which can be found here:=20

http://www.mathworks.com/access/helpdesk/help/toolbox/images/roipoly.html

Despite this, it is not exacly equal to MATLAB counterpart. I believe
there's some slight difference in rounding or something similar... But I
believe it's not important, really.

I attach some images from sample in documenentation of roipoly:
* poly_matlab.png (the sample generated by MATLAB)
* poly_octave.png (generated by Octave)
* poly_diff.png (the diff, in blue you can see point in MATLAB which are
not in Octave, and in red the opposite).

Since this function is a little bit tricky to get right, I'd appreciate
any testing on it, specially on MATLAB compatibility. In
http://www.cs.rit.edu/~icss571/filling/ there is info on corner cases
which are worth testing.

BTW, I hope I haven't made any mistake on meaning of m and n... they
seem out of order (actually x,y do)... What a silly argument list.


 -- Function File: BW =3D  poly2mask (X,Y,M,N)
     Convert a polygon to a region mask

     BW=3Dpoly2mask(x,y,m,n) converts a polygon, specified by a list of
     vertices in X and Y and returns in a M-by-N logical mask BW the
     filled polygon. Region inside the polygon is set to 1, values
     outside the shape are set to 0.

     X and Y should always represent a closed polygon, first and last
     points should be coincident. If they are not poly2mask will close
     it for you. If X or Y are fractional they are nearest integer.

     If all the polygon or part of it falls outside the masking area
     (1:m,1:n), it is discarded or clipped.

     This function uses scan-line polygon filling algorithm as described
     in http://www.cs.rit.edu/~icss571/filling/ with some minor
     modifications: capability of clipping and scan order, which can
     affect the results of the algorithm (algorithm is described not to
     reach ymax, xmax border when filling to avoid enlarging shapes). In
     this function we scan the image backwards (we begin at ymax and end
     at ymin), and we don't reach ymin, xmin, which we believe should be
     compatibile with MATLAB.





Regards,

--=20
Josep Mon=E9s i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] Help making padarray.m quicker

[Josep i T. <jm...@pu...>]

On dc, 2004-08-11 at 13:37, Paul Kienzle wrote:
> On Aug 11, 2004, at 4:43 AM, Per Persson wrote:
>=20
> >
> > On Aug 11, 2004, at 04:12, Paul Kienzle wrote:
> >
> >>
> >> On Aug 10, 2004, at 6:18 PM, Josep Mon=E9s i Teixidor wrote:
> >>
> >>> I've left padding with scalar values as it was in the second version
> >>> because, although in my intel box that was slower, as Paul sent
> >>> yesterday, that probably makes a real difference on MacOs X.
> >>
> >> Note the difference in version number: 2.1.55 for OS X,
> >> 2.1.57 for linux!  Octave may have changed to make the
> >> two more similar.  Does somebody have both versions
> >> available on the same system that they can compare?
> >
> > FWIW, on a 1.25MHz G4 w 512MB RAM iMac with octave 2.1.57 I get (+/- =20
> > 20% accuracy)
> >
> > octave:1> n=3D800; A=3Dones(n,n);
> > octave:2> tic; B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=3DA; toc
> > ans =3D 0.16152
> > octave:3> tic; =20
> > B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,=
50=20
> > )); toc
> > ans =3D 0.19956
> >
> > I don't have any pre-2.1.57 installs, but I'm pretty sure there =20
> > weren't any changes between 2.1.55 and 2.1.57 that could justify the =20
> > 10x diff in speed. Did you run the test on a memory starved (which for =
=20
> > OS X means <=3D256 MB) system?
>=20
> octave:12> n=3D200; A=3Dones(n,n);
> octave:13> tic; B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=3DA; toc
> ans =3D 0.045741
> octave:14> tic; =20
> B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,50=
)=20
> ); toc
> ans =3D 0.43754
>=20
> octave:31> n=3D20; A=3Dones(n,n);
> octave:32> tic; for i=3D1:10, B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=
=3DA; =20
> end; toc
> ans =3D 0.047229
> octave:33> tic; for i=3D1:10, =20
> B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,50=
)=20
> ); end; toc
> ans =3D 0.45311
>=20
> So I would say the 10x is real.  It's nice to hear that it its gone =20
> now.  I just hope that's because cat got faster rather than assignment =20
> getting slower ;-)
>=20
> Josep, don't worry about choosing an algorithm suitable for older =20
> versions of octave.
>=20
> - Paul



I this case I'll leave it as it is, which is the faster version. The
only problem now is cat not working for ND arrays in some cases.... but
this will work soon anyway... It's a pity that this last approach isn't
faster... it was sooo simple and beautiful! :)

In the future I may try to speed scripts that need it by coding them in
C++, to acquire experience with liboctave.=20

BTW, I've realised that I made a mistake with emacs, and some files have
DOS-style line endings (those mad keystrokes!), but if I correct it
locally, diff doesn't detect any difference. I don't know how to change
that remotely... affected files are padarray.m, roicolor.m and uintlut.m

This is not important, but I discovered when using shared feature of
tests. It doesn't work if line endings are DOS style. Perhaps there's a
little bug there waiting for Windows users.

Regards,

--=20
Josep Mon=E9s i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] Help making padarray.m quicker

[Paul K. <pki...@us...>]

On Aug 11, 2004, at 4:43 AM, Per Persson wrote:

>
> On Aug 11, 2004, at 04:12, Paul Kienzle wrote:
>
>>
>> On Aug 10, 2004, at 6:18 PM, Josep Mon=E9s i Teixidor wrote:
>>
>>> I've left padding with scalar values as it was in the second version
>>> because, although in my intel box that was slower, as Paul sent
>>> yesterday, that probably makes a real difference on MacOs X.
>>
>> Note the difference in version number: 2.1.55 for OS X,
>> 2.1.57 for linux!  Octave may have changed to make the
>> two more similar.  Does somebody have both versions
>> available on the same system that they can compare?
>
> FWIW, on a 1.25MHz G4 w 512MB RAM iMac with octave 2.1.57 I get (+/- =20=

> 20% accuracy)
>
> octave:1> n=3D800; A=3Dones(n,n);
> octave:2> tic; B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=3DA; toc
> ans =3D 0.16152
> octave:3> tic; =20
> =
B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,50=20=

> )); toc
> ans =3D 0.19956
>
> I don't have any pre-2.1.57 installs, but I'm pretty sure there =20
> weren't any changes between 2.1.55 and 2.1.57 that could justify the =20=

> 10x diff in speed. Did you run the test on a memory starved (which for =
=20
> OS X means <=3D256 MB) system?

octave:12> n=3D200; A=3Dones(n,n);
octave:13> tic; B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=3DA; toc
ans =3D 0.045741
octave:14> tic; =20
B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,50)=
=20
); toc
ans =3D 0.43754

octave:31> n=3D20; A=3Dones(n,n);
octave:32> tic; for i=3D1:10, B=3Dzeros(n+100,n+100); =
B(51:n+50,51:n+50)=3DA; =20
end; toc
ans =3D 0.047229
octave:33> tic; for i=3D1:10, =20
B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,50)=
=20
); end; toc
ans =3D 0.45311

So I would say the 10x is real.  It's nice to hear that it its gone =20
now.  I just hope that's because cat got faster rather than assignment =20=

getting slower ;-)

Josep, don't worry about choosing an algorithm suitable for older =20
versions of octave.

- Paul=

Re: [OctDev] Help making padarray.m quicker

[Per P. <per...@ma...>]

On Aug 11, 2004, at 04:12, Paul Kienzle wrote:

>
> On Aug 10, 2004, at 6:18 PM, Josep Mon=E9s i Teixidor wrote:
>
>> I've left padding with scalar values as it was in the second version
>> because, although in my intel box that was slower, as Paul sent
>> yesterday, that probably makes a real difference on MacOs X.
>
> Note the difference in version number: 2.1.55 for OS X,
> 2.1.57 for linux!  Octave may have changed to make the
> two more similar.  Does somebody have both versions
> available on the same system that they can compare?

FWIW, on a 1.25MHz G4 w 512MB RAM iMac with octave 2.1.57 I get (+/- =20
20% accuracy)

octave:1> n=3D800; A=3Dones(n,n);
octave:2> tic; B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=3DA; toc
ans =3D 0.16152
octave:3> tic; =20
B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,50)=
=20
); toc
ans =3D 0.19956

I don't have any pre-2.1.57 installs, but I'm pretty sure there weren't =20=

any changes between 2.1.55 and 2.1.57 that could justify the 10x diff =20=

in speed. Did you run the test on a memory starved (which for OS X =20
means <=3D256 MB) system?


/Per
--------
Per Persson, Ph.D. Applied Signal Processing
Resume, contact info and more:
http://homepage.mac.com/persquare

Re: [OctDev] Help making padarray.m quicker

[Paul K. <pki...@us...>]

On Aug 10, 2004, at 6:18 PM, Josep Mon=E9s i Teixidor wrote:

> I've left padding with scalar values as it was in the second version
> because, although in my intel box that was slower, as Paul sent
> yesterday, that probably makes a real difference on MacOs X.

Note the difference in version number: 2.1.55 for OS X,
2.1.57 for linux!  Octave may have changed to make the
two more similar.  Does somebody have both versions
available on the same system that they can compare?

- Paul

Re: [OctDev] Help making padarray.m quicker

[Josep i T. <jm...@pu...>]

Hello!

I attach another version of padarray.m which indexes A smartly to
produce directly the padded array (trick suggested by Paul) and which
improves speed on circular, replicate and symmetric paddings.

I've left padding with scalar values as it was in the second version
because, although in my intel box that was slower, as Paul sent
yesterday, that probably makes a real difference on MacOs X.

Note that tests in file only test 2D arrays and, although if tried some
3D arrays, I haven't tested exhaustively if results are correct on
high-dimensional arrays.

So, the times are now:

octave:2> A=ones(30,30,30,30); tic; for i=1:10; B=padarray(A,[2,2,2,2]);
endfor; toc
ans = 32.460
octave:3> A=ones(30,30,30,30); tic; for i=1:10;
B=padarray(A,[2,2,2,2],10); endfor; toc
ans = 35.358
octave:4> A=ones(30,30,30,30); tic; for i=1:10;
B=padarray(A,[2,2,2,2],'circular'); endfor; toc
ans = 53.527
octave:5> A=ones(30,30,30,30); tic; for i=1:10;
B=padarray(A,[2,2,2,2],'replicate'); endfor; toc
ans = 53.589
octave:6> A=ones(30,30,30,30); tic; for i=1:10;
B=padarray(A,[2,2,2,2],'symmetric'); endfor; toc
ans = 53.358



Yes... yes... my P2 is veeery slow :)


-- 
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] Help making padarray.m quicker

[Paul K. <pki...@us...>]

On Aug 9, 2004, at 10:39 PM, Josep Mon=E9s i Teixidor wrote:

> On dt, 2004-08-10 at 04:31, Josep Mon=E9s i Teixidor wrote:
>
>> Or perhaps cat is quick?
>
> If tried a little test to pad "manually" a 1000*1000 matrix with 50
> zeros (as if we used 'both').
>
> octave:10> A=3Dones(1000,1000); t=3Dtime(); for i=3D1:10;
> =
B=3Dcat(2,zeros(1100,50),cat(1,zeros(50,1000),A,zeros(50,1000)),zeros(110=20=

> 0,50)); endfor; time()-t
> ans =3D 5.5180
>
> octave:11> A=3Dones(1000,1000); t=3Dtime(); for i=3D1:10; =
B=3Dzeros(1100,1100);
> B(51:1050,51:1050)=3DA; endfor; time()-t
> ans =3D 5.4502
>
> What do you think of these times?

2.1.55 on OS X:

octave:50> n=3D800; A=3Dones(n,n);
octave:51> tic; B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=3DA; toc
ans =3D 0.29751
octave:52> tic; =20
B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,50)=
=20
); toc
ans =3D 3.0635

2.1.57 on Debian, gcc 3.3.3

octave:26> n=3D800; A=3Dones(n,n);
octave:27> tic; B=3Dzeros(n+100,n+100); B(51:n+50,51:n+50)=3DA; toc
ans =3D 0.30018
octave:28> tic; =20
B=3Dcat(2,zeros(n+100,50),cat(1,zeros(50,n),A,zeros(50,n)),zeros(n+100,50)=
=20
); toc
ans =3D 0.33685


- Paul=

Re: [OctDev] Help making padarray.m quicker

[Josep i T. <jm...@pu...>]

On dt, 2004-08-10 at 04:31, Josep Mon=E9s i Teixidor wrote:

> Or perhaps cat is quick?

If tried a little test to pad "manually" a 1000*1000 matrix with 50
zeros (as if we used 'both').

octave:10> A=3Dones(1000,1000); t=3Dtime(); for i=3D1:10;
B=3Dcat(2,zeros(1100,50),cat(1,zeros(50,1000),A,zeros(50,1000)),zeros(1100,=
50)); endfor; time()-t
ans =3D 5.5180

octave:11> A=3Dones(1000,1000); t=3Dtime(); for i=3D1:10; B=3Dzeros(1100,11=
00);
B(51:1050,51:1050)=3DA; endfor; time()-t
ans =3D 5.4502

What do you think of these times?

--=20
Josep Mon=E9s i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] Help making padarray.m quicker

[Josep i T. <jm...@pu...>]

On dt, 2004-08-10 at 04:31, Josep Monés i Teixidor wrote:

> The recoded version is attached. The results of the tests below (using a
> 4D test array) show that original version is quicker.

I forgot the attach... here it goes...
-- 
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

[OctDev] Help making padarray.m quicker

[Josep i T. <jm...@pu...>]

Hello!

I've tried to recode padarray.m to preallocate array and then assign
padding values instead of using cat everywhere expecting a speed
improvement.

The recoded version is attached. The results of the tests below (using a
4D test array) show that original version is quicker.

I didn't expect that at all, can anybody have a look at the attached
code to see if there's something very wrong that could be slowing thing
down?

Or perhaps cat is quick?

Thanks

----->%------------>%--------
Using NEW padarray.m:

octave:1> A=3Dones(30,30,30,30); t=3Dtime(); for i=3D1:10;
B=3Dpadarray(A,[2,2,2,2]); endfor; time()-t
ans =3D 32.391
octave:2> A=3Dones(30,30,30,30); t=3Dtime(); for i=3D1:10;
B=3Dpadarray(A,[2,2,2,2],10); endfor; time()-t
ans =3D 34.200
octave:3> A=3Dones(30,30,30,30); t=3Dtime(); for i=3D1:10;
B=3Dpadarray(A,[2,2,2,2],'circular'); endfor; time()-t
ans =3D 74.152
octave:4> A=3Dones(30,30,30,30); t=3Dtime(); for i=3D1:10;
B=3Dpadarray(A,[2,2,2,2],'replicate'); endfor; time()-t
ans =3D 73.749
octave:5> A=3Dones(30,30,30,30); t=3Dtime(); for i=3D1:10;
B=3Dpadarray(A,[2,2,2,2],'symmetric'); endfor; time()-t
ans =3D 74.707



Using OLD pararray.m:
octave:1> A=3Dones(30,30,30,30); t=3Dtime(); for i=3D1:10;
B=3Dpadarray(A,[2,2,2,2]); endfor; time()-t
ans =3D 13.106
octave:2> A=3Dones(30,30,30,30); t=3Dtime(); for i=3D1:10;
B=3Dpadarray(A,[2,2,2,2],10); endfor; time()-t
ans =3D 13.596
octave:3> A=3Dones(30,30,30,30); t=3Dtime(); for i=3D1:10;
B=3Dpadarray(A,[2,2,2,2],'circular'); endfor; time()-t
ans =3D 44.399

replicate segfaulted (I believe CVS Octave should be able to handle it,
I've found problems when using cat on ND arrays).

octave:1> A=3Dones(30,30,30,30); t=3Dtime(); for i=3D1:10;
B=3Dpadarray(A,[2,2,2,2],'symmetric'); endfor; time()-t
ans =3D 44.495
----->%------------>%--------


--=20
Josep Mon=E9s i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] image/padarray.m

[Josep i T. <jm...@pu...>]

On dl, 2004-08-09 at 14:15, Teemu Ikonen wrote:
> On 08/08/04 20:50, Josep Mon=E9s i Teixidor wrote:
> > Let's introduce padarray...
>=20
> Hi Josep,
>=20
> padarray.m seems to replicate and extend the functionality in impad.m, wh=
ich
> is already in octave-forge. Since padarray is more Matlab compatible, we
> should probably start using it instead.
>=20
> "rgrep -l impad *" gives:
>=20
> image/fftconv2.m
> image/impad.m
> image/imrotate.m
> image/imshear.m
> image/imtranslate.m
> image/medfilt2.m
> image/ordfilt2.m
>=20
> Would you be interested in changing the function calls to impad in these
> functions to padarray, so that impad can be deprecated?
>=20
> Teemu

Ok. I'm following a suggestion from Paul Kienze to speed up padarray,
since it uses cat extensively which is much more slower than allocating
an array and assigning everything after that. So padarray will change
soon...

After that I can change those calls if everyone agrees...

If someone can test if it's compatible with matlab counterpart please do
so (and all the others too) since I don't have it to test it (I've coded
them using their online docs).

--=20
Josep Mon=E9s i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] image/padarray.m

[Teemu I. <tpi...@pc...>]

On 08/08/04 20:50, Josep Mon=E9s i Teixidor wrote:
> Let's introduce padarray...

Hi Josep,

padarray.m seems to replicate and extend the functionality in impad.m, wh=
ich
is already in octave-forge. Since padarray is more Matlab compatible, we
should probably start using it instead.

"rgrep -l impad *" gives:

image/fftconv2.m
image/impad.m
image/imrotate.m
image/imshear.m
image/imtranslate.m
image/medfilt2.m
image/ordfilt2.m

Would you be interested in changing the function calls to impad in these
functions to padarray, so that impad can be deprecated?

Teemu



>=20
>  -- Function File: B =3D  padarray (A,PADSIZE)
>  -- Function File: B =3D  padarray (A,PADSIZE,PADVAL)
>  -- Function File: B =3D  padarray (A,PADSIZE,PADVAL,DIRECTION)
>      Pads an array in a configurable way.
>=20
>      B =3D padarray(A,padsize) pads an array A with zeros, where PADSIZ=
E
>      defines the amount of padding to add in each dimension (it must be
>      a vector of positive integers).
>=20
>      Each component of PADSIZE defines the number of elements of
>      padding that will be added in the corresponding dimension. For
>      instance, [4,5] adds 4 elements of padding in first dimension
>      (vertical) and 5 in second dimension (horizontal).
>=20
>      B =3D padarray(A,padsize,padval) pads A using the value specified =
by
>      PADVAL. PADVAL can be a scalar or a string. Possible values are:
>     `0'
>           Pads with 0 as described above. This is the default behaviour.
>=20
>     `scalar'
>           Pads using PADVAL as a padding value.
>=20
>     `'circular''
>           Pads with a circular repetition of elements in A (similar to
>           tiling A).
>=20
>     `'replicate''
>           Pads 'replicating' values of A which are at the border of the
>           array.
>=20
>     `'symmetric''
>           Pads with a mirror reflection of A.
>=20
>      B =3D padarray(A,padsize,padval,direction) pads A defining the
>      direction of the pad. Possible values are:
>     `'both''
>           For each dimension it pads before the first element the numbe=
r
>           of elements defined by PADSIZE and the same number again afte=
r
>           the last element. This is the default value.
>=20
>     `'pre''
>           For each dimension it pads before the first element the
>           number of elements defined by PADSIZE.
>=20
>     `'post''
>           For each dimension it pads after the last element the number
>           of elements defined by PADSIZE.
>=20
>=20
> --=20
> Josep Mon=E9s i Teixidor
> Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] Probit analysis functions

[Paul K. <pki...@us...>]

Add the function names to INDEX.  m-files are automatically
installed and any tests done in the %! style are automatically
run.

Thanks,

- Paul

On Aug 8, 2004, at 2:08 PM, Rafael Laboissiere wrote:

> * Paul Kienzle <pki...@us...> [2004-08-08 12:52]:
>
>> The octave-forge `packaging system' does not support subdirectories. 
>> If you
>> have a lot of functions, it will be easier to add main/probit.  If you
>> don't have a lot of functions, then do you really need a separate
>> subdirectory?
>
> There are only four files, all of them prefixed by "probit_".  I do not
> prefer one way or the other but ...
>
>> Without thinking about it a whole lot I prefer a shallower package
>> tree, especially since we have a flat namespace.
>
> ... your arguments are sound.  I will add the files to main/statistics.
> After adding the files, should I change something elsewhere (Makefile,
> INDEX, etc)?
>
> -- 
> Rafael

[OctDev] image/padarray.m

[Josep i T. <jm...@pu...>]

Let's introduce padarray...

 -- Function File: B =  padarray (A,PADSIZE)
 -- Function File: B =  padarray (A,PADSIZE,PADVAL)
 -- Function File: B =  padarray (A,PADSIZE,PADVAL,DIRECTION)
     Pads an array in a configurable way.

     B = padarray(A,padsize) pads an array A with zeros, where PADSIZE
     defines the amount of padding to add in each dimension (it must be
     a vector of positive integers).

     Each component of PADSIZE defines the number of elements of
     padding that will be added in the corresponding dimension. For
     instance, [4,5] adds 4 elements of padding in first dimension
     (vertical) and 5 in second dimension (horizontal).

     B = padarray(A,padsize,padval) pads A using the value specified by
     PADVAL. PADVAL can be a scalar or a string. Possible values are:
    `0'
          Pads with 0 as described above. This is the default behaviour.

    `scalar'
          Pads using PADVAL as a padding value.

    `'circular''
          Pads with a circular repetition of elements in A (similar to
          tiling A).

    `'replicate''
          Pads 'replicating' values of A which are at the border of the
          array.

    `'symmetric''
          Pads with a mirror reflection of A.

     B = padarray(A,padsize,padval,direction) pads A defining the
     direction of the pad. Possible values are:
    `'both''
          For each dimension it pads before the first element the number
          of elements defined by PADSIZE and the same number again after
          the last element. This is the default value.

    `'pre''
          For each dimension it pads before the first element the
          number of elements defined by PADSIZE.

    `'post''
          For each dimension it pads after the last element the number
          of elements defined by PADSIZE.


-- 
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

[OctDev] image/uintlut.m image/roicolor.m

[Josep i T. <jm...@pu...>]

Hi,

More functions... 

uintlut only works with Octave CVS because of tests, but it won't be of
any use without uint8 and uint16 anyway...


 -- Function File: BW =  roicolor (A,LOW,HIGH)
 -- Function File: BW =  roicolor (A,V)
     Select a Region Of Interest of an image based on color.

     BW = roicolor(A,low,high) selects a region of interest (ROI) of an
     image A returning a black and white image in a logical array (1 for
     pixels inside ROI and 0 outside ROI), which is formed by all pixels
     whose values lie within the colormap range specified by [LOW HIGH].

     BW = roicolor(A,v) selects a region of interest (ROI) formed by all
     pixels that match values in V.



 -- Function File: B =  uintlut (A,LUT)
     Computes matrix B by using A as an index to lookup table LUT.

     B = uintlut(A, LUT) calculates a matrix B by using LUT as a lookup
     table indexed by values in A.

     B class is the same as LUT.



-- 
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] Probit analysis functions

[Rafael L. <rla...@us...>]

* Paul Kienzle <pki...@us...> [2004-08-08 12:52]:

> The octave-forge `packaging system' does not support subdirectories. If you
> have a lot of functions, it will be easier to add main/probit.  If you
> don't have a lot of functions, then do you really need a separate
> subdirectory?

There are only four files, all of them prefixed by "probit_".  I do not
prefer one way or the other but ...

> Without thinking about it a whole lot I prefer a shallower package
> tree, especially since we have a flat namespace.

... your arguments are sound.  I will add the files to main/statistics.
After adding the files, should I change something elsewhere (Makefile,
INDEX, etc)?

-- 
Rafael

Re: [OctDev] Probit analysis functions

[Paul K. <pki...@us...>]

On Aug 7, 2004, at 10:39 AM, Rafael Laboissiere wrote:

> I am planing to contribute this package to octave-forge, but I would
> appreciate if any statisticians lurking this mailing list could give a 
> look
> at it before.  Is it okay if I add the files in a separate directory 
> under
> main/statistics, say main/statistics/probit?

The octave-forge `packaging system' does not support subdirectories.
If you have a lot of functions, it will be easier to add main/probit.  
If you
don't have a lot of functions, then do you really need a separate
subdirectory?

Without thinking about it a whole lot I prefer a shallower package
tree, especially since we have a flat namespace.

If you do decide to go deeper, please put the logic in main/Makefile
in such a way that other packages can easily support installable
subdirectories, e.g., with a file listing them in the top level of the
package.  Also, unify this with what David has done in fixed, since
it has some subdirectories.

- Paul

[OctDev] Probit analysis functions

[Rafael L. <rla...@us...>]

I wrote a set of Octave functions that implement a probit analysis, as
described in the book Finney, D.J. (1971) "Probit Analysis", Cambridge
University Press, 3rd ed.  Quantal response data for different conditions
are fitted with cumulative normal curves. The following statistical tests
are executed:

   1. Goodness of fit (chi square test)
   2. Parallelism of fitted curves (chi square test)
   3. Separation of parallel curves at P = 0.5 (Student t test)   

You will find the files at:

    http://people.debian.org/~rafael/probit/

The functions are extensively documented in texinfo (whose formatted output
appear as *.txt files in the website above) and there is a %!demo in
probit_analysis.m.  

I am planing to contribute this package to octave-forge, but I would
appreciate if any statisticians lurking this mailing list could give a look
at it before.  Is it okay if I add the files in a separate directory under
main/statistics, say main/statistics/probit?

-- 
Rafael

Re: [OctDev] Build problems on solaris 2.8 (octave-forge 2004.07.07)

[Robert R. <re...@ii...>]

Paul Kienzle wrote:

> 
> On Jul 28, 2004, at 10:55 AM, Robert Reutemann wrote:
> 
>> Hi
>>
>> Trying to build the latest octave-forge release
>> (2004.07.07) on solaris (sparc) 2.8 using gcc 3.4.1
>> with octave 2.1.57 I ran into a couple of problems.

....

>> gmake check fails (segmentation violation while in
>> main/signal). I don't know yet, what other problems
>> I still have.

(It wasn't in main/signal, but in main/sparse, sorry,
see below.)

> 
> I would be much obliged if you could split up the
> make check work so that it only checks a directory
> at a time.  At least that way it will minimize the
> consequences of a segfault.  You probably don't
> want to go down to the level of the individual file
> since that will start and restart octave too many
> times.  Alternatively, the test program could monitor
> progress and restart at the next test after a segfault.

I tried to split up the make check stuff.
All the problems seem to be in sparse/....

Up to main/signal, fntests.m works, with the following
error:

--------------------------------------------------------

 >>>>> processing main/signal/kaiserord.m
   ***** test error("extend demo to show detail at criteria box corners");
!!!!! test failed
error: extend demo to show detail at criteria box corners

--------------------------------------------------------

Then, I have to comment *all* checks in sparse, except
for pcg.m. Including any of the other sparse tests
leads to a segmentation violation.

With the sparse stuff commented out, the tests run
through, with the following error:

--------------------------------------------------------

 >>>>> processing main/statistics/princomp.m
   ***** assert(Tsq,1,10*eps);
!!!!! test failed
error: assert (Tsq,1,10 * eps) expected
1
but got
            NaN
            NaN
Dimensions don't match
shared variables {
   Tsq =

              NaN
              NaN

   m =

     -0.70711   0.70711   0.00000
      0.70711   0.70711   0.00000
     -0.00000   0.00000   1.00000

   pc =

     -0.70711   0.70711   0.00000
      0.70711   0.70711   0.00000
     -0.00000   0.00000   1.00000

   w =

     1
     0
     0

   x =

     1  2  3
     2  1  3

   z =

      0.70711   0.00000   0.00000
     -0.70711  -0.00000   0.00000

}

--------------------------------------------------------

In batch_test.m, I again have to remove the sparse stuff
("fem_test"), since I get segmentation violations other-
wise.

With sparse commented out, batch_test.m passes all tests.

>> If anybody has experience with building octave and
>> octave-forge on solaris 2.8 with gcc I'll be thankful
>> for any hints and better solutions.
> 
> 
> Please post your experiences on the octave wiki
> 
>     http://wiki.octave.org
> 
> Category Install.
> 

I'll try to summarize my experiences there next.

I still didn't work on getting the scripts to run with
standard /bin/sh -- just using /bin/bash was easier.


Robert

Re: [OctDev] image/makelut.m image/applylut.m

[Paul K. <pki...@us...>]

Added to octave-forge.

Again, thanks for the tests and demos.

	- Paul

On Aug 2, 2004, at 2:39 PM, Josep Mon=E9s i Teixidor wrote:

> Hi!
>
> 2 new functions attached: makelut & applylut
>
> Regards!
> --=20
> Josep Mon=E9s i Teixidor
> Clau GnuPG: gpg --recv-keys 80E85CC4
> <applylut.m><makelut.m>=

[OctDev] image/makelut.m image/applylut.m

[Josep i T. <jm...@pu...>]

Hi!

2 new functions attached: makelut & applylut

Regards!
-- 
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] get_authors hacker

[A. D. <al...@da...>]

On Wed, Jul 07, 2004 at 10:12:37PM -0400, Paul Kienzle wrote:
> Does anyone want to 'own' the author list?
> 
> The list is extracted automatically from the source
> by the perl program admin/get_authors.
> 
> If somebody wants to update the code and/or
> the source files so that all the authors are
> being properly attributed I would be much obliged.

As the author of the admin/get_authors script I do feel compelled to 
keep it working properly.  How about this:  if someone can define
a standard format by which an author identifies him/her self in 
contributed files, I'll make sure get_authors is able to parse that
format.

Barring an convention, author names will be all over the place and the
script will get increasingly more difficult to maintain.     -- Al

Re: [OctDev] Build problems on solaris 2.8 (octave-forge 2004.07.07)

[Paul K. <pki...@us...>]

Okay, that would be my fault.

Every system I use has bash available, so it doesn't affect
me one way or the other.  This is more of a question for
people with solaris, hpux, aix, etc.

In the meantime, please let me know of any bashisms.

Thanks,

- Paul

On Jul 31, 2004, at 1:21 PM, Andy Adler wrote:

> From: Paul Kienzle <pki...@us...>
>>
>> We are trying to be shell agnostic.  Please report
>> the sh incompatibilities rather than requiring bash
>> on the target machine.
>
> buildtests.sh in main/sparse requires bash rather than
> sh. I changed the Makefile, but this is not your prefered
> approach. Should we try to write such scripts using only
> sh functions?
>
> Andy
>

Re: [OctDev] Build problems on solaris 2.8 (octave-forge 2004.07.07)

[Andy A. <ad...@nc...>]

From: Paul Kienzle <pki...@us...>
> 
> We are trying to be shell agnostic.  Please report
> the sh incompatibilities rather than requiring bash
> on the target machine.

buildtests.sh in main/sparse requires bash rather than
sh. I changed the Makefile, but this is not your prefered
approach. Should we try to write such scripts using only
sh functions?

Andy

Re: [OctDev] image/dilate.m image/erode.m

[Josep i T. <jm...@pu...>]

On dj, 2004-07-29 at 02:10, Paul Kienzle wrote: 
> Okay, added.
> I'm surprised you couldn't use filter2(...,'same') to trim the
> array automatically.  I'm not saying it will work (I didn't look
> closely at the program logic), but I thought this would be
> a primary example of where 'same' would be used.

You are right. This is becuase of my inexperience with Octave. I was
experimenting on filters with even size (where to set central pixel in
those to be compatible with MATLAB?). Cutting borders myself let me use
both floor((size(SE)+1)/2) and ceil((size(SE)+1)/2).

But just using 'same' gives the same results as the version I sent
yesterday. And if someone tries it on MATLAB and it behaves differently,
perhaps we can just pad the filter with 0 properly. It's cleaner.

I attach a patch[1] using your suggestion.

Regards,

[1] Created by command "cvs diff -u main/image/dilate.m
main/image/erode.m"
-- 
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4