octave-dev — GNU Octave developers' list

Re: [OctDev] new imaging functions (graycomatrix, houghtf)

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

On ds, 2004-08-21 at 10:26, Stefan van der Walt wrote:
> I submitted two new functions, "graycomatrix" and "houghtf".  Please
> try the demos and let me know if you see gremlins in the code.

Demos run ok in my system, but I think that build instructions need to
be included in Makefile.


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

Re: [OctDev] New functions and a question

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

Hi Paul!

Your answer is full of good advice... This should remind me to ask
questions more often...


On dt, 2004-08-24 at 23:32, pki...@co... wrote:
> It doesn't matter what field you use.  Off hand I would suggest=20
> overriding Octave's 'class' function so that if it is given a struct=20
> as the first argument, it checks for a secret field name=20
> (e.g., __class) and prints that, or prints 'struct' if no secret
> field exists.  If given two arguments, then set s.__class to
> the second argument, which should be the class name.  That
> will make the interface similar, even if the underlying
> implementation does not yet support automatic dispatching
> into the @class directory.  You could implement that too
> if you were so inclined using find_in_loadpath([class,'.m']) to
> find the directory, then creating a dispatch off struct for every
> m-file and oct-file in that directory.

Thinking about "making an interface as similar as possible", What I
don't want to do is to waste time making a "struct" interface similar,
time that perhaps would be invested in just implementing classes in
Octave.

But it seems easy enough to be worth trying... although it would be
great classes are implemented in Octave.

>=20
> Octave supports structure arrays, at laeast in recent versions.
> What syntax are you using to index and assign them?
>=20

mmm... I was using the wrong syntax... I've found out the correct way to
do it. Whis is what i was doing (lines 4 to 6)... I still have a lot to
learn about Octave

octave:1> s1.field=3D'value';
octave:2> s2.field=3D'value';
octave:3> a(1)=3Ds1
a =3D
{
  field =3D value
}

octave:4> b=3D[s1,s2]
error: octave_base_value::array_value(): wrong type argument `struct'
error: evaluating assignment expression near line 4, column 2
octave:4> b=3D[]
b =3D [](0x0)
octave:5> b(1)=3Ds1
error: operator =3D: no conversion for assignment of `struct' to indexed
`matrix'
error: assignment failed, or no method for `matrix =3D struct'
error: evaluating assignment expression near line 5, column 5


> - Paul
>=20

Thanks for the info

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

Re: [OctDev] New functions and a question

[<pki...@co...>]

It doesn't matter what field you use.  Off hand I would suggest 
overriding Octave's 'class' function so that if it is given a struct 
as the first argument, it checks for a secret field name 
(e.g., __class) and prints that, or prints 'struct' if no secret
field exists.  If given two arguments, then set s.__class to
the second argument, which should be the class name.  That
will make the interface similar, even if the underlying
implementation does not yet support automatic dispatching
into the @class directory.  You could implement that too
if you were so inclined using find_in_loadpath([class,'.m']) to
find the directory, then creating a dispatch off struct for every
m-file and oct-file in that directory.

Octave supports structure arrays, at laeast in recent versions.
What syntax are you using to index and assign them?

- Paul


> On dj, 2004-08-19 at 04:13, pki...@co... wrote:
> > I don't think there is any point in naming them strel_xxx.  I don't think 
> these functions exist elsewhere in octave/octave-forge.
> > 
> > - Paul
> > 
> 
> Ok!
> 
> I'm just naming them as they should. BTW, I'm using a @strel directory
> to have everything in place already.
> 
> To simulate classes I just use structs which have a field "type" set to
> "strel", which helps identifying it. Do you thing this is ok?
> 
> I also have the problem that I can't use structs as elements in an
> array; so I've replaced all arrays of strel objects to cell arrays of
> strel objects, which is ugly.
> 
> BTW, in addition of decomposition of structuring elements, I'm finding
> articles of specific dilate or erode algorithms for line structuring
> elements or other types of structuring elements, which are supposed to
> be much faster that using a general-neighbourhood algorithm (even if
> decomposed smartly). So I plan to store the shape in the strel object so
> we can use these algorithms in a future and speed up things.
> 
> Regards,
> -- 
> Josep Monés i Teixidor
> Clau GnuPG: gpg --recv-keys 80E85CC4
> 

Re: [OctDev] New functions and a question

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

On dj, 2004-08-19 at 04:13, pki...@co... wrote:
> I don't think there is any point in naming them strel_xxx.  I don't think=
 these functions exist elsewhere in octave/octave-forge.
>=20
> - Paul
>=20

Ok!

I'm just naming them as they should. BTW, I'm using a @strel directory
to have everything in place already.

To simulate classes I just use structs which have a field "type" set to
"strel", which helps identifying it. Do you thing this is ok?

I also have the problem that I can't use structs as elements in an
array; so I've replaced all arrays of strel objects to cell arrays of
strel objects, which is ugly.

BTW, in addition of decomposition of structuring elements, I'm finding
articles of specific dilate or erode algorithms for line structuring
elements or other types of structuring elements, which are supposed to
be much faster that using a general-neighbourhood algorithm (even if
decomposed smartly). So I plan to store the shape in the strel object so
we can use these algorithms in a future and speed up things.

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

Re: [OctDev] New functions and a question

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

Hi,


On ds, 2004-08-21 at 09:05, Stefan van der Walt wrote:
> Unfortunately, our catalogue also only stretches back to 95.  The only
> place where I found any reference to the articles mentioned below is
> the ACM portal:
>=20
> http://portal.acm.org
>=20
> The following article describes something similar, but not in much detail=
:
>=20
> Implementation Efficiency of Binary Morphology (Bloomberg)
> http://www.leptonica.com/papers/binmorph.pdf

I had found this already... it will be useful, but it's a pity, as you
say, that it isn't more concrete...


>=20
> Regards
> Stefan

I've begun working on it... I hope to finish it soon...

Thanks

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

[OctDev] new imaging functions (graycomatrix, houghtf)

[Stefan v. d. W. <st...@su...>]

I submitted two new functions, "graycomatrix" and "houghtf".  Please
try the demos and let me know if you see gremlins in the code.

Regards
Stefan

usage: P = graycomatrix(I, levels, distances, angles)

  Calculate the gray-level co-occurrence matrix P = f(i,j,d,theta)
  of a gray-level image.

  P is a 4-dimensional matrix (histogram). The value P(i,j,d,theta)
  is the number of times that gray-level j occurs at a distance 'd'
  and at an angle 'theta' from gray-level j.

  'I' is the input image which should contain integers in [0,
  levels-1], where 'levels' indicate the number of gray-levels counted
  (typically 256 for an 8-bit image).  'distances' and 'angles' are
  vectors of the different distances and angles to use.

usage: [H, R]  = houghtf(I[, angles])

  Calculate the straight line Hough transform of an image.

  The image, I, should be a binary image in [0,1].  The angles are
  given in degrees and defaults to -90..90.

  H is the resulting transform, R the radial distances.

  See also: Digital Image Processing by Gonzales & Woods
  (2nd ed., p. 587)

Re: [OctDev] New functions and a question

[Stefan v. d. W. <st...@su...>]

Unfortunately, our catalogue also only stretches back to 95.  The only
place where I found any reference to the articles mentioned below is
the ACM portal:

http://portal.acm.org

The following article describes something similar, but not in much detail:

Implementation Efficiency of Binary Morphology (Bloomberg)
http://www.leptonica.com/papers/binmorph.pdf

Regards
Stefan

On Fri, Aug 20, 2004 at 07:00:50PM +0200, Josep Mon?s i Teixidor wrote:
> On dv, 2004-08-20 at 08:54, Stefan van der Walt wrote:
> 
> > Please go ahead, Josep.  I havn't used these functions before and
> > unfortunately do not have the time to figure them out now.
> > 
> > Regards
> > Stefan
> > 
> 
> Hi,
> 
> A (perhaps non-ethical) petition: I've been trying to find [1] and [2]
> in my university's library but it seems that they subscribed to this
> journal in 1995 and I don't know where to find previous volumes.
> 
> Does anyone have this references? I'd like to read these articles in
> order to decompose structuring elements.
> 
> 
> 
> [1] van den Boomgard, Rein, and Richard van Balen, "Methods for Fast
> Morphological Image Transforms Using Bitmapped Images," Computer Vision,
> Graphics, and Image Processing: Graphical Models and Image Processing,
> Vol. 54, No. 3, May 1992, pp. 252-254.
> 
> [2] Adams, Rolf, "Radial Decomposition of Discs and Spheres," Computer
> Vision, Graphics, and Image Processing: Graphical Models and Image
> Processing, Vol. 55, No. 5, September 1993, pp. 325-332.
> 
> 
> 
> Shouldn't scientific papers be free? ;)
> 
> TIA,
> 
> 
> -- 
> Josep Mon?s i Teixidor
> Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] New functions and a question

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

On dv, 2004-08-20 at 08:54, Stefan van der Walt wrote:

> Please go ahead, Josep.  I havn't used these functions before and
> unfortunately do not have the time to figure them out now.
>=20
> Regards
> Stefan
>=20

Hi,

A (perhaps non-ethical) petition: I've been trying to find [1] and [2]
in my university's library but it seems that they subscribed to this
journal in 1995 and I don't know where to find previous volumes.

Does anyone have this references? I'd like to read these articles in
order to decompose structuring elements.



[1] van den Boomgard, Rein, and Richard van Balen, "Methods for Fast
Morphological Image Transforms Using Bitmapped Images," Computer Vision,
Graphics, and Image Processing: Graphical Models and Image Processing,
Vol. 54, No. 3, May 1992, pp. 252-254.

[2] Adams, Rolf, "Radial Decomposition of Discs and Spheres," Computer
Vision, Graphics, and Image Processing: Graphical Models and Image
Processing, Vol. 55, No. 5, September 1993, pp. 325-332.



Shouldn't scientific papers be free? ;)

TIA,


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

Re: [OctDev] New functions and a question

[Stefan v. d. W. <st...@su...>]

On Wed, Aug 18, 2004 at 05:40:53PM +0200, Josep Mon?s i Teixidor wrote:
> Hi,
> 
> 
> On dc, 2004-08-18 at 08:27, Stefan van der Walt wrote:
> > I havn't used anything beyond the neighbourhood property of structured
> > elements, so I am not sure what other features they have.  Looks like
> > it would be possible to use a normal structure and an N-dimensional
> > matrix to imitate it until we have a proper class? (See below)
> > 
> > Regards
> > Stefan
> > 
> > Structuring element (STREL) creation and manipulation.
> > 
> >     getheight      - Get strel height.
> > 
> >     getneighbors   - Get offset location and height of strel neighbors
> > 
> >     getnhood       - Get strel neighborhood.
> > 
> >     getsequence    - Get sequence of decomposed strels.
> > 
> >     isflat         - Return true for flat strels.
> > 
> >     reflect        - Reflect strel about its center.
> > 
> >     strel          - Create morphological structuring element.
> > 
> >     translate      - Translate strel
> > 
> 
> yes... strel could be a struct and all its members could be accessed
> using functions like strel_getneighbours... This way, when we have
> classes it's only a matter of moving a few m-files to a @strel directory
> and search/replace to eliminate prefixes... So work won't be lost :)
> 
> I don't know if you are interested in coding this one. If you are, go
> ahead. If you prefer me to do it, just tell me and I'll have a try.

Please go ahead, Josep.  I havn't used these functions before and
unfortunately do not have the time to figure them out now.

Regards
Stefan

[OctDev] OpenCV in octave-forge

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

Hi!

I've been in touch with S=F8ren Hauberg. He sent a few days a go an email
to Octave Help list to ask a few questions about interfacing OpenCV to
Octave.

He has some code now: dilate and erode functions which are 3x faster
than m-files although they require conversion to 8 bit types.

We thought that perhaps it would be a good way to go to wrap OpenCV api
as it is (there's a MATLAB wrapper for it already) and then use it
internally when coding MATLAB-like image processing toolbox functions
when needed (because algorithms may not be exactly the same, or
supported types different, etc..).

Has anyone tested matwrap?

Any thoughts?

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

Re: [OctDev] New functions and a question

[<pki...@co...>]

I don't think there is any point in naming them strel_xxx.  I don't think these functions exist elsewhere in octave/octave-forge.

- Paul


> Hi,
> 
> 
> On dc, 2004-08-18 at 08:27, Stefan van der Walt wrote:
> > I havn't used anything beyond the neighbourhood property of structured
> > elements, so I am not sure what other features they have.  Looks like
> > it would be possible to use a normal structure and an N-dimensional
> > matrix to imitate it until we have a proper class? (See below)
> > 
> > Regards
> > Stefan
> > 
> > Structuring element (STREL) creation and manipulation.
> > 
> >     getheight      - Get strel height.
> > 
> >     getneighbors   - Get offset location and height of strel neighbors
> > 
> >     getnhood       - Get strel neighborhood.
> > 
> >     getsequence    - Get sequence of decomposed strels.
> > 
> >     isflat         - Return true for flat strels.
> > 
> >     reflect        - Reflect strel about its center.
> > 
> >     strel          - Create morphological structuring element.
> > 
> >     translate      - Translate strel
> > 
> 
> yes... strel could be a struct and all its members could be accessed
> using functions like strel_getneighbours... This way, when we have
> classes it's only a matter of moving a few m-files to a @strel directory
> and search/replace to eliminate prefixes... So work won't be lost :)
> 
> I don't know if you are interested in coding this one. If you are, go
> ahead. If you prefer me to do it, just tell me and I'll have a try.
> 
> Regards,
> 
> -- 
> Josep Monés i Teixidor
> Clau GnuPG: gpg --recv-keys 80E85CC4
> 

Re: [OctDev] New functions and a question

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

Hi,


On dc, 2004-08-18 at 08:27, Stefan van der Walt wrote:
> I havn't used anything beyond the neighbourhood property of structured
> elements, so I am not sure what other features they have.  Looks like
> it would be possible to use a normal structure and an N-dimensional
> matrix to imitate it until we have a proper class? (See below)
>=20
> Regards
> Stefan
>=20
> Structuring element (STREL) creation and manipulation.
>=20
>     getheight      - Get strel height.
>=20
>     getneighbors   - Get offset location and height of strel neighbors
>=20
>     getnhood       - Get strel neighborhood.
>=20
>     getsequence    - Get sequence of decomposed strels.
>=20
>     isflat         - Return true for flat strels.
>=20
>     reflect        - Reflect strel about its center.
>=20
>     strel          - Create morphological structuring element.
>=20
>     translate      - Translate strel
>=20

yes... strel could be a struct and all its members could be accessed
using functions like strel_getneighbours... This way, when we have
classes it's only a matter of moving a few m-files to a @strel directory
and search/replace to eliminate prefixes... So work won't be lost :)

I don't know if you are interested in coding this one. If you are, go
ahead. If you prefer me to do it, just tell me and I'll have a try.

Regards,

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

Re: [OctDev] New functions and a question

[Stefan v. d. W. <st...@su...>]

I havn't used anything beyond the neighbourhood property of structured
elements, so I am not sure what other features they have.  Looks like
it would be possible to use a normal structure and an N-dimensional
matrix to imitate it until we have a proper class? (See below)

Regards
Stefan

Structuring element (STREL) creation and manipulation.

    getheight      - Get strel height.

    getneighbors   - Get offset location and height of strel neighbors

    getnhood       - Get strel neighborhood.

    getsequence    - Get sequence of decomposed strels.

    isflat         - Return true for flat strels.

    reflect        - Reflect strel about its center.

    strel          - Create morphological structuring element.

    translate      - Translate strel

On Mon, Aug 16, 2004 at 04:36:50PM +0200, Josep Mon?s i Teixidor wrote:
> Hi Sefan,
> 
> On Mon, 16 Aug 2004 08:50:13 +0200, Stefan van der Walt wrote:
> 
> >  ERODE Perform erosion on binary image.
> > 
> >     Note: This function is obsolete and may be removed in future
> >     versions. Use IMERODE instead.
> > 
> >  ...
> > 
> > We could rename the function with a dispatch to the old name?  Paul?
> > 
> > Regards
> > Stefan
> > 
> > 
> 
> I used erode instead of imerode because interface is not 100%
> compatible with imreode. I plan to implement it to, but since it takes
> a STREL object, it would be great to have classes to implement this
> right.
> 
> Josep
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] imread

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

On dl, 2004-08-16 at 13:18, Stefan van der Walt wrote:
> Would anyone using 'imread' care if the output of reading
> colour images changed from
>=20
> [r,g,b] =3D imread(...)
>=20
> to
>=20
> I =3D imread(...)
>=20
> where I is a 3xNxM matrix?

Sorry, don't you mean a N*M*3 ?
>=20
> Regards
> Stefan
>=20
It's ok for me

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

Re: [OctDev] New functions and a question

[<jm...@gm...>]

Hi Sefan,

On Mon, 16 Aug 2004 08:50:13 +0200, Stefan van der Walt wrote:

>  ERODE Perform erosion on binary image.
> 
>     Note: This function is obsolete and may be removed in future
>     versions. Use IMERODE instead.
> 
>  ...
> 
> We could rename the function with a dispatch to the old name?  Paul?
> 
> Regards
> Stefan
> 
> 

I used erode instead of imerode because interface is not 100%
compatible with imreode. I plan to implement it to, but since it takes
a STREL object, it would be great to have classes to implement this
right.

Josep

Re: [OctDev] New tsearchn.m function

[Pedro T. <pt...@te...>]

Sorry for the mistake. 

I attached a non working development version. Here's the real one and a test 
for it.

Regards,
Pedro

Re: [OctDev] New functions and a question

[<jm...@gm...>]

Hi Sefan,

On Mon, 16 Aug 2004 08:50:13 +0200, Stefan van der Walt wrote:

>  ERODE Perform erosion on binary image.
> 
>     Note: This function is obsolete and may be removed in future
>     versions. Use IMERODE instead.
> 
>  ...
> 
> We could rename the function with a dispatch to the old name?  Paul?
> 
> Regards
> Stefan
> 
> 

I used erode instead of imerode because interface is not 100%
compatible with imreode. I plan to implement it to, but since it takes
a STREL object, it would be great to have classes to implement this
right.

Josep

Re: [OctDev] imread

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

How about if nargout == 1 and image is colour, then
return m x n x 3 ?  If nargout == 3 continue to return
r,g,b separately?

Hmm.. doesn't work long term since three argout imread
might want to return A,map,alpha, though personally,
A x [r,g,b,a] as m x n x 4 makes more sense to me

- Paul

On Aug 16, 2004, at 7:18 AM, Stefan van der Walt wrote:

> Would anyone using 'imread' care if the output of reading
> colour images changed from
>
> [r,g,b] = imread(...)
>
> to
>
> I = imread(...)
>
> where I is a 3xNxM matrix?
>
> Regards
> Stefan
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] imread

[Stefan v. d. W. <st...@su...>]

Would anyone using 'imread' care if the output of reading
colour images changed from

[r,g,b] = imread(...)

to

I = imread(...)

where I is a 3xNxM matrix?

Regards
Stefan

Re: [OctDev] New functions and a question

[Stefan v. d. W. <st...@su...>]

Hi Josep!

Thank you for the functions!  I took a look at the morphological
functions a few days ago -- useful to have them around!  I see MATLAB
says

>> help erode
help erode

 ERODE Perform erosion on binary image.

    Note: This function is obsolete and may be removed in future
    versions. Use IMERODE instead.

 ...

We could rename the function with a dispatch to the old name?  Paul?

Regards
Stefan

On Mon, Aug 16, 2004 at 12:22:02AM +0200, Josep Mon?s i Teixidor wrote:
> Hi!
> 
> A have committed a few more m-files: bestblk, procblk, bweuler,
> conndef, nlfilter and bwmorph. Please look into them and test if you
> are in the mood. :)
> 
> Some comments:
> * nlfilter and procblk should probably be implemented in C++. Now I
> focus on implementing as much functions as I can (I won't be able to
> dedicate much time to it from September on), and m-files are faster.
> I'll probably do it myself in the future... If someone wants to take
> it, please :)
> * bwmorph has a few glitches (see docs) and things I'm not 100% sure
> of since these functions are my first approximation to image
> processing. Specially frustrating is skel. Tests will come soon. This
> function proves that applylut probably needs to be recoded in C++
> 
> Some questions (err... actually just 1):
> * bwmorph contains some lookup tables which have been calculated using
> m-files I haven't committed (__bridge_lut_fun__.m,
> __conditional_mark_patterns_lut_fun_.m, 
> __unconditional_mark_patterns_lut_fun_.m and
> __diagonal_fill_lut_fun__.m). I think I should commit them in order to
> allow people debug bwmorph and as documentation of the algorithms, but
> they are not intended for being used directly (even indirectly ;) ).
> Where should I upload them? Is the __name__.m nomenclature correct for
> them?
> 
> 
> P.S.: If replying to me directly please use this email address instead
> of the address I used in other postings since I'm having problems with
> my main email address.
> 
> Regards,
> 
> Josep
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] New functions and a question

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

On Aug 15, 2004, at 6:22 PM, Josep Mon=E9s i Teixidor wrote:

> Some questions (err... actually just 1):
> * bwmorph contains some lookup tables which have been calculated using
> m-files I haven't committed (__bridge_lut_fun__.m,
> __conditional_mark_patterns_lut_fun_.m,
> __unconditional_mark_patterns_lut_fun_.m and
> __diagonal_fill_lut_fun__.m). I think I should commit them in order to
> allow people debug bwmorph and as documentation of the algorithms, but
> they are not intended for being used directly (even indirectly ;) ).
> Where should I upload them? Is the __name__.m nomenclature correct for
> them?

You could put them in a subdirectory.  Subdirectories are not
installed by default, except for bin and data.  The underscore
nomenclature is fine as well, especially if you want the functions
available at runtime.

- Paul

[OctDev] New functions and a question

[<jm...@gm...>]

Hi!

A have committed a few more m-files: bestblk, procblk, bweuler,
conndef, nlfilter and bwmorph. Please look into them and test if you
are in the mood. :)

Some comments:
* nlfilter and procblk should probably be implemented in C++. Now I
focus on implementing as much functions as I can (I won't be able to
dedicate much time to it from September on), and m-files are faster.
I'll probably do it myself in the future... If someone wants to take
it, please :)
* bwmorph has a few glitches (see docs) and things I'm not 100% sure
of since these functions are my first approximation to image
processing. Specially frustrating is skel. Tests will come soon. This
function proves that applylut probably needs to be recoded in C++

Some questions (err... actually just 1):
* bwmorph contains some lookup tables which have been calculated using
m-files I haven't committed (__bridge_lut_fun__.m,
__conditional_mark_patterns_lut_fun_.m, 
__unconditional_mark_patterns_lut_fun_.m and
__diagonal_fill_lut_fun__.m). I think I should commit them in order to
allow people debug bwmorph and as documentation of the algorithms, but
they are not intended for being used directly (even indirectly ;) ).
Where should I upload them? Is the __name__.m nomenclature correct for
them?


P.S.: If replying to me directly please use this email address instead
of the address I used in other postings since I'm having problems with
my main email address.

Regards,

Josep

[OctDev] New functions and a question

[<jm...@gm...>]

Hi!

A have committed a few more m-files: bestblk, procblk, bweuler,
conndef, nlfilter and bwmorph. Please look into them and test if you
are in the mood. :)

Some comments:
* nlfilter and procblk should probably be implemented in C++. Now I
focus on implementing as much functions as I can (I won't be able to
dedicate much time to it from September on), and m-files are faster.
I'll probably do it myself in the future... If someone wants to take
it, please :)
* bwmorph has a few glitches (see docs) and things I'm not 100% sure
of since these functions are my first approximation to image
processing. Specially frustrating is skel. Tests will come soon. This
function proves that applylut probably needs to be recoded in C++

Some questions (err... actually just 1):
* bwmorph contains some lookup tables which have been calculated using
m-files I haven't committed (__bridge_lut_fun__.m,
__conditional_mark_patterns_lut_fun_.m, 
__unconditional_mark_patterns_lut_fun_.m and
__diagonal_fill_lut_fun__.m). I think I should commit them in order to
allow people debug bwmorph and as documentation of the algorithms, but
they are not intended for being used directly (even indirectly ;) ).
Where should I upload them? Is the __name__.m nomenclature correct for
them?


P.S.: If replying to me directly please use this email address instead
of the address I used in other postings since I'm having problems with
my main email address.

Regards,

Josep

[OctDev] New tsearchn.m function

[Pedro T. <pt...@te...>]

Hello,

I just finished a new tsearchn.m function. It is the n-dimensional equivalent 
of tsearch.

I'm not very happy with this implementation for this two reasons:

-It's an -m- file, so it's performance is not very good. I think this should 
be implemented as an .oct function. Maybe in the future if I get desperate 
enough.

-The speed could be improved in some cases if it were possible to check if the 
points lie within the tesselation a priori. I can do that finding the convex 
hull of X along with its normals and offsets (hyperplane equations). I wrote 
time ago a qhull.oct function that allows to do that but since it's not in 
octave-forge I didn't include this procedure. This means that if many points 
don't belong to the tesselation the computing time can be long.

Anyway, here's what I wrote and what I'm using. I can't commit to CVS so if 
someone is willing to do so, please, feel free.

I attach tsearchn.m and qhull.cc just in case someone likes it.

Regards,
Pedro

Re: [OctDev] Introducing poly2mask

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

On dc, 2004-08-11 at 19:52, Josep Monés i Teixidor wrote:

> 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).

I forgot the images...

Why do I always need 2 emails when one should be enough?
-- 
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4