yes Dr Dalitz,
yes it helps a lot thank you! i didn't see that before it really helps a lot.
I also saw an article where the extract the skeleton directly from the
image:Skeletonization by Gradient Regularization and diffusion

but thank you so much for your help like always.

Sincerely,

--- In gamera-devel@yahoogroups.com, Christoph Dalitz <christoph.dalitz@...>
wrote:
>
> Am Wed, 25 Nov 2009 15:03:25 -0000
> schrieb "st_ilige" <st_ilige@...>:
> >
> > can we do medial axis following? or maybe we can call centerline following?
> >
> I do not exactly understand what your question is.
>
> The term "thinning" is used in the literature in different ways
> and generally stands for any way to compute some kind of "skeleton",
> be it the medial axis, or the center line, or something similar.
>
> To see which thinning algorithms in gamera produce which type of
> skeleton, simply create an image with a black 10x20 rectangle
> and see whether the result is the medial axis or the center line.
>
> IIRC, thin_zs is the fastest algorithm and computes the center line,
> and thin_hs is significantly slower and computes the medial axis, but
> to be sure, make the experiment yourself!
>
> Note that the medial axis results in forking at the edges, which
> in most cases is unwanted and needs to be cleaned (again the distance
> transform can help in that case); actually I had once written a plugin
> for the MusicStaves toolkit for exactly this purpose:
>
http://lionel.kr.hs-niederrhein.de/~dalitz/data/projekte/stafflines/doc/musicsta\
ves.html#remove-spurs-from-skeleton
>
> Does this answer help?
>
> Christoph
>

Am Wed, 25 Nov 2009 15:03:25 -0000
schrieb "st_ilige" <st_ilige@...>:
>
> can we do medial axis following? or maybe we can call centerline following?
>
I do not exactly understand what your question is.

The term "thinning" is used in the literature in different ways
and generally stands for any way to compute some kind of "skeleton",
be it the medial axis, or the center line, or something similar.

To see which thinning algorithms in gamera produce which type of
skeleton, simply create an image with a black 10x20 rectangle
and see whether the result is the medial axis or the center line.

IIRC, thin_zs is the fastest algorithm and computes the center line,
and thin_hs is significantly slower and computes the medial axis, but
to be sure, make the experiment yourself!

Note that the medial axis results in forking at the edges, which
in most cases is unwanted and needs to be cleaned (again the distance
transform can help in that case); actually I had once written a plugin
for the MusicStaves toolkit for exactly this purpose:
http://lionel.kr.hs-niederrhein.de/~dalitz/data/projekte/stafflines/doc/musicsta\
ves.html#remove-spurs-from-skeleton

Does this answer help?

Christoph

Yes thank you so much, that's what i needed to do, it' much much simpler. I also
have a question concercing the skeleton in Gamera.
can we do medial axis following? or maybe we can call centerline following?

Thank you!!!!
Hani.

--- In gamera-devel@yahoogroups.com, Christoph Dalitz <christoph.dalitz@...>
wrote:
>
> Am Wed, 25 Nov 2009 13:22:34 -0000
> schrieb "st_ilige" <st_ilige@...>:
>
> > Hi all,
> > I was trying to compute the radius of a stroke at every point of a skeleton
and i wrote a function for that can you please check it?
> > What u need is the binary image,the direction of the gradient at each point
arctan(Iy,Ix) and the skeleton image. Do u have a better idea maybe you can
share it too.
> >
> Why don't you simply use the distance transform?
> http://gamera.sourceforge.net/doc/html/morphology.html#distance-transform
>
> Create the distance transform d and the skeleton s
> from your image f. Then the stroke thickness at each skeleton point (x,y)
> is d(x,y).
>
> Does this waht you need?
>
> Christoph
>

Am Wed, 25 Nov 2009 13:22:34 -0000
schrieb "st_ilige" <st_ilige@...>:

> Hi all,
> I was trying to compute the radius of a stroke at every point of a skeleton
and i wrote a function for that can you please check it?
> What u need is the binary image,the direction of the gradient at each point
arctan(Iy,Ix) and the skeleton image. Do u have a better idea maybe you can
share it too.
>
Why don't you simply use the distance transform?
http://gamera.sourceforge.net/doc/html/morphology.html#distance-transform

Create the distance transform d and the skeleton s
from your image f. Then the stroke thickness at each skeleton point (x,y)
is d(x,y).

Does this waht you need?

Christoph

Hi all,
I was trying to compute the radius of a stroke at every point of a skeleton and
i wrote a function for that can you please check it?
What u need is the binary image,the direction of the gradient at each point
arctan(Iy,Ix) and the skeleton image. Do u have a better idea maybe you can
share it too.
what i do is i take a segment that is perpendicular to the direction of the
gradient and i start moving in both directions when i find that the value is 0.0
i stop the count and move to the opposite direction and i do the same thing.
for example: if i move 4 pixels up and i find a black pixel i stop
if i move 4 pixels down and i find a black pixel i stop. in total i will have 8
pixels and i will have a radius = 4 pixels
If the thickness is 1 then the radius = 0.5 and so on...

Thank you!



def radius(self,binary,angles,skel):
         for i in range(0,skel.shape[0]):
             for j in range(0,skel.shape[1]):
                 r = 1.0
                 if float(skel[i,j]) == 1.0:
                     angle = math.pi/2.0 + (angles[i,j] * 180.0/math.pi)
                     x = i
                     y = j

                     x1 = self.indx(x + 1.0*cos(angle),binary.shape[0])
                     y1 = self.indx(y + 1.0*sin(angle),binary.shape[1])
                     step = 1
                     while float(binary[x1,y1]) != 0.0:
                         r = r + 1
                         x1 = self.indx(x + step*cos(angle),binary.shape[0])
                         y1 = self.indx(y + step*sin(angle),binary.shape[1])
                         step = step + 1

                     x2 = self.indx(x - 1.0*cos(angle),binary.shape[0])
                     y2 = self.indx(y - 1.0*sin(angle),binary.shape[1])
                     step = 1
                     while float(binary[x1,y1]) != 0.0:
                         r = r + 1
                         x2 = self.indx(x - step*cos(angle),binary.shape[0])
                         y2 = self.indx(y - step*sin(angle),binary.shape[1])
                         step = step + 1
                     if r == 1.0:
                         radius = 0.5
                     else:
                         radius = r/2.0
                     print radius

         return radius

* Jakub Wilk <ubanus@...>, 2009-10-20, 08:55:
>I am happy to announce that Gamera is now available in the Debian's
>development distribution:
>
>http://packages.debian.org/source/unstable/gamera

And now in Ubuntu, too:

https://launchpad.net/ubuntu/+source/gamera

--
Jakub Wilk

* Christoph Dalitz <christoph.dalitz@...>, 2009-11-18, 14:05:
>Hello Jakub,
>
>what would you think about adding the gamera tutorial and its sample
>images into the package gamera-doc:
>
>http://gamera.informatik.hsnr.de/docs/gamera-tutorial.pdf
>http://gamera.informatik.hsnr.de/docs/tutorial-images.tar.gz
>
>I have updated the tutorial to also include a license notice (CC-BY-SA 3.0)
>so that it is compatible with Debian's copyright policy.

It would be nice to have these files in Debian. However, if the
documentation were generated from another format, the original format
needs to be included in the source package (alongside or instead of the
generated files).

--
Jakub Wilk

Wrong call sorry i didn't see that it has no return value. Problem solved

Hello, I have a problem using the function despeckle.
I do the following steps:
from gamera.gui import gui
from gamera.core import *
from gamera.plugins.morphology import *

Image = Image.to_onebit()
Image = Image.despeckle(3)

then when i want to convert it to a nested list:
I = array(Image.to_nested_list())

I get the following error:
AttributeError: 'NoneType' object has no attribute 'to_nested_list'

What am i doing wrong?

Thank you.

Hello Jakub,

what would you think about adding the gamera tutorial and its sample
images into the package gamera-doc:

http://gamera.informatik.hsnr.de/docs/gamera-tutorial.pdf
http://gamera.informatik.hsnr.de/docs/tutorial-images.tar.gz

I have updated the tutorial to also include a license notice (CC-BY-SA 3.0)
so that it is compatible with Debian's copyright policy.

Christoph

Am Tue, 20 Oct 2009 08:55:42 +0200
schrieb Jakub Wilk <ubanus@...>:

> I am happy to announce that Gamera is now available in the Debian's
> development distribution:
>
> http://packages.debian.org/source/unstable/gamera
>

Am Thu, 12 Nov 2009 12:18:10 -0500
schrieb Michael Droettboom <mike@...>:

> Related to the speed of loading a large classifier database, if sorting is
> to blame, does the included patch help?  (I don't have a large database
> sitting around to test with at the moment.)
>
I have done some more tests on a database with 24 000 glyphs. Sorting when
adding a glyph only takes about 10 seconds. Nevertheless, loading the database
into the classifier takes (without file reading and feature generation) several
minutes, so there must be some different bottleneck.

I have activated your change again, because resorting on adding glyphs can
easily be suppressed by not showing the classifier glyphs (which is pointless
anyway for such a large database).

Thanks,

Christoph

* christofero2002 <christoph.dalitz@...>, 2009-11-15, 06:45:
>>>> Gamera crashes with segmentation fault while trying to open an invalid
>>>> PNG file; see the attachment.
>>>>
>>>Can someone with a Linux system please check whether adding the
>>>following code at the beginning of all other functions that call
>>>functions with the prefix "png_" (lower case) solves the issue?
>>
>>That still wouldn't be correct: there is at least one function that
>>calls both png_* functions and PNG_* functions. Worse still, some png_*
>>functions are called inside try blocks.
>>
>I understand that there are some issues with the libpng use in Gamera.
>
>I could however track down where the exception (i.e. longjmp) is thrown
>in libpng when your sample image is loaded. I have checked a patch into
>SVN that should resolve this issue.
>
>Tomorrow, I will have again access to a Linux system and will try to
>verfiy my conjecture. If you currently are on a Linux system, you might
>also do an "svn update" and check whether loading the problemtic PNG
>file still causes a crash.

Crash is no longer triggered, thanks.

--
Jakub Wilk

--- In gamera-devel@yahoogroups.com, Jakub Wilk <ubanus@...> wrote:
>
> * christofero2002 <christoph.dalitz@...>, 2009-11-13, 21:02:
> >> Gamera crashes with segmentation fault while trying to open an invalid
> >> PNG file; see the attachment.
> >>
> >Can someone with a Linux system please check whether adding the
> >following code at the beginning of all other functions that call
> >functions with the prefix "png_" (lower case) solves the issue?
>
> That still wouldn't be correct: there is at least one function that
> calls both png_* functions and PNG_* functions. Worse still, some png_*
> functions are called inside try blocks.
>
I understand that there are some issues with the libpng use in Gamera.

I could however track down where the exception (i.e. longjmp) is thrown in
libpng when your sample image is loaded. I have checked a patch into SVN that
should resolve this issue.

Tomorrow, I will have again access to a Linux system and will try to verfiy my
conjecture. If you currently are on a Linux system, you might also do an "svn
update" and check whether loading the problemtic PNG file still causes a crash.

Thanks,

Christoph

* christofero2002 <christoph.dalitz@...>, 2009-11-13, 21:02:
>> Gamera crashes with segmentation fault while trying to open an invalid
>> PNG file; see the attachment.
>>
>I cannot reproduce this error on MacOS X (neither on PPC, nor on
>Intel). It seems to me however that the use of setjmp() in
>include/plugins/png_support.hpp is errenous:
>
>It is only called in *one* function (PNG_info_specific), but png_*
>functions are also called in other functions. This means that when an
>error occurs in a different function calling something form libpng, the
>exception will jump to PNG_info_specific with the wrong stack context,
>making a crash very likely.
>
>Can someone with a Linux system please check whether adding the
>following code at the beginning of all other functions that call
>functions with the prefix "png_" (lower case) solves the issue?

That still wouldn't be correct: there is at least one function that
calls both png_* functions and PNG_* functions. Worse still, some png_*
functions are called inside try blocks.

--
Jakub Wilk

--- In gamera-devel@yahoogroups.com, Jakub Wilk <ubanus@...> wrote:
>
> Gamera crashes with segmentation fault while trying to open an invalid
> PNG file; see the attachment.
>
I cannot reproduce this error on MacOS X (neither on PPC, nor on Intel).
It seems to me however that the use of setjmp() in
include/plugins/png_support.hpp
is errenous:

It is only called in *one* function (PNG_info_specific), but png_* functions are
also called in other functions. This means that when an error occurs in a
different function calling something form libpng, the exception will jump to
PNG_info_specific with the wrong stack context, making a crash very likely.

Can someone with a Linux system please check whether adding the following code
at the beginning of all other functions that call functions with the prefix
"png_" (lower case) solves the issue?

   if (setjmp(png_jmpbuf(png_ptr))) {
     png_destroy_read_struct(&png_ptr, &info_ptr, &end_info);
     fclose(fp);
     throw std::runtime_error("Unknown PNG error");
   }

Thanks,

Christoph

Am Thu, 12 Nov 2009 12:18:10 -0500
schrieb Michael Droettboom <mike@...>:

> Related to the speed of loading a large classifier database, if sorting is
> to blame, does the included patch help?  (I don't have a large database
> sitting around to test with at the moment.)
>
It is not such an issue while loading the database (feature generation takes
much longer than sorting). It becomes however problematic when adding glyphs
to that database. Though simply hiding the classifier glyphs (which in your
suggested solution suppressed the sorting) is a usable workaround.

> On Thu, Nov 12, 2009 at 12:05 PM, Michael Droettboom
<mike@...>wrote:
>
> > Ok.  I've reverted my change, but left the new sort-on-add code in there as
> > a comment in case we want to make this a user-settable option down the
> > road.  I could imagine having an "auto-sort" toggle button or some such.
> >
Sounds like a good idea with toggled "on" by default.

I wonder however, whether sorting on each newly added glyph is the
appropriate action. What should be done instead, is to look whether
the label already exists and add it to this row or add a new row when
it not exists.

If that is too much trouble, simply calling the sort function (which does
this implicitly) might be a programmatically simple workaround.

Christoph

Am Thu, 12 Nov 2009 12:12:47 -0500
schrieb Michael Droettboom <mike@...>:
>
> Creating a dummy file in tests/tmp called ".empty_dir" and adding the
> following works for me:
>
> recursive-include tests *.py README
> recursive-include tests/data *
> include tests/tmp/.empty_dir
>
Thanks!

> On a slightly off-topic note, I am getting one test failure:
>
>     def test_mlcc():
>        mlcc1 = MlCc(img, 2, Rect((0,0),(8,8)))
> E      assert round(mlcc1.black_area()[0]) ==  9.0
> >      assert 12.0 == 9.0
>
I cannot reproduce this error on my system. I suspect that this
is due to black_area() using the wrong image type specialization
because gamera/plugins/_features.cpp has not been recreated during
the build process (this caused us considerable time to figure out
why no plugin worked with the new image type...).

Can you please remove all temporary files with

	 rm gamera/plugins/_*.cpp
	 python setup.py clean --all

rebuild Gamera and let me know whether the error still occurs?

Thanks,

Christoph

On Thu, 12 Nov 2009  jsbien@... wrote:


[...]

>> I think it is no problem to resort the glyphs by pressing on the sort
>> button when it is necessary.
>
> You are right that this is not a problem. The problem is misleading
> display of unsorted glyphs.

The simplest (?) solution: put unsorted glyphs into separate row(s),
do not add them to the rows dedicated to specific characters.

Best regards

Janusz

--
                      ,
dr hab. Janusz S. Bien, prof. UW -  Uniwersytet Warszawski (Katedra Lingwistyki
Formalnej)
Prof. Janusz S. Bien - Warsaw University (Department of Formal Linguistics)
jsbien@..., jsbien@..., http://fleksem.klf.uw.edu.pl/~jsbien/

On Thu, 12 Nov 2009  Jakub Wilk <ubanus@...> wrote:

> Hello,
>
> I classified two glyphs: first one as "n", second one as "w". The
> "Classifier glyphs" pane shows that they are both classified as "w" (see
> the attached screenshot).

[...]


On Thu, 12 Nov 2009  Christoph Dalitz <christoph.dalitz@...>
wrote:

> Am Thu, 12 Nov 2009 11:30:30 -0500
> schrieb Michael Droettboom <mike@...>:
>
>> For performance reasons, the classifier glyph pane does not re-sort upon
>> adding.

Please note that this make the pane, as pointed in the subject of
Jakub's posting, simply plain wrong! Looks like you are already
accustomed to it, but for new users it is terribly confusing.

>>
>> On newer hardware, this doesn't appear to be as much of a problem, though I
>> suspect with a really large classifier database, one would still run into
>> problems.  I've updated the code (r1178) to re-sort upon adding, but only if
>> the classifier pane is visible.
>>
> I would rather not sort upon adding: I have a number of classifier databases
> containing about 4000 glyphs which take already forever on loading.

I'm not sure I understand. Do you have to load them with the pane
visible?

>
> I think it is no problem to resort the glyphs by pressing on the sort
> button when it is necessary.

You are right that this is not a problem. The problem is misleading
display of unsorted glyphs.

Best regards

Janusz
(not yet a real user of Gamera, just experimenting a little...)

--
                      ,
dr hab. Janusz S. Bien, prof. UW -  Uniwersytet Warszawski (Katedra Lingwistyki
Formalnej)
Prof. Janusz S. Bien - Warsaw University (Department of Formal Linguistics)
jsbien@..., jsbien@..., http://fleksem.klf.uw.edu.pl/~jsbien/

* Christoph Dalitz <christoph.dalitz@...>, 2009-11-12, 17:44:
>> Unfortunately, the tests directory is not currently included in the
>> tarballs.
>>
>This seems to be harder than it should. The problem is that the
>subdirectory "tests/tmp" must be included in the tarball, but without
>its contents. I have tried in MANIFEST.in
>
> recursive-include tests *.py README *.png *.tiff

The above would include files in tests/tmp/*.png as well...

> recursive-include tests/data *
> recursive-include tests/tmp
>
>but this includes everything under tests/tmp as well.
>Using
>
> prune tests/tmp
>
>removes the directory itself as well. Any hints how to
>accomplish this with MANIFEST.in are welcome.

I don't think there's an easy way to make distutils include an empty
directory. An obvious work-around would be to create a dummy file in
tests/tmp/ and add it to MANIFEST.in (which won't help if the directory
really needs to empty, but I think it's not the case.)

--
Jakub Wilk

Am Thu, 12 Nov 2009 17:22:28 +0100
schrieb Jakub Wilk <ubanus@...>:
>
> Unfortunately, the tests directory is not currently included in the
> tarballs.
>
This seems to be harder than it should. The problem is that the
subdirectory "tests/tmp" must be included in the tarball, but without
its contents. I have tried in MANIFEST.in

	 recursive-include tests *.py README *.png *.tiff
	 recursive-include tests/data *
	 recursive-include tests/tmp

but this includes everything under tests/tmp as well.
Using

	 prune tests/tmp

removes the directory itself as well. Any hints how to
accomplish this with MANIFEST.in are welcome.

Christoph

Am Thu, 12 Nov 2009 11:30:30 -0500
schrieb Michael Droettboom <mike@...>:

> For performance reasons, the classifier glyph pane does not re-sort upon
> adding.
>
> On newer hardware, this doesn't appear to be as much of a problem, though I
> suspect with a really large classifier database, one would still run into
> problems.  I've updated the code (r1178) to re-sort upon adding, but only if
> the classifier pane is visible.
>
I would rather not sort upon adding: I have a number of classifier databases
containing about 4000 glyphs which take already forever on loading.

I think it is no problem to resort the glyphs by pressing on the sort
button when it is necessary.

Christoph

Hello,

Gamera has been successfully built on 15 different architectures[1][2].
Unfortunately we don't known if Gamera actually *works* on all of them.
Therefore, it would be beneficial if Debian package run unit tests at
build time.

Unfortunately, the tests directory is not currently included in the
tarballs. Could that be fixed in future releases? Thanks in advance.

[1] http://buildd.debian.org/~luk/status/package.php?p=gamera
[2] http://buildd.debian-ports.org/status/package.php?p=gamera

--
Jakub Wilk

Hello,

I classified two glyphs: first one as "n", second one as "w". The
"Classifier glyphs" pane shows that they are both classified as "w" (see
the attached screenshot).

The problem goes away if I hide the pane and then show it again.

--
Jakub Wilk