Hi Masatake,

please add this to cvs.

Martin

--- In autotrace@y..., Bernhard Herzog <bh@i...> wrote:
> Jerritt Collord <collord@c...> writes:
>
> > When saving centerlines in .sk format, I don't think there should
be a
> > bC() at the end of the bezier... this makes them closed curves.
Oddly,
> > this doesn't show in Sketch itself, but only when the file is
exported to
> > postscript (e.g. printed).
> >
> > Changing output-sk.c line 48 like so fixes this:
> >
> > if(!at_centerline){ fputs("bC()\n", file); }
> >
> > Unless there's something I'm missing here???  I wonder if this
crept in as
> > the .sk format has supposedly changed a bit in the last bit?
>
> No, it's probably due to me being too lazy to update the sk-output
> filter of AutoTrace when the centerline tracing was introduced :) .
I
> haven't looked at the code yet, but the bC() should only be present
at
> the end of closed curves. Before the centerline tracing was
implemented,
> all curves AutoTrace produced were closed.
>
>    Bernhard
>
> --
> Intevation GmbH
http://intevation.de/
> Sketch
http://sketch.sourceforge.net/
> MapIt!
http://mapit.de/

I'm sorry to be late.
I've just commited.

> Hi Masatake,
>
> please add this to cvs.

Hi all,
I've commited some code.

New options:

--despeckle-level
--despeckle-tightness
	 I've commited to the repository despeckle function forwarded
	 by Martin.

I wrote:
> I'd like to add "progress bar" that shows how image tracing
> is progressed to my Frontline, a GUI frontend for autotrace.
>
> Is it easy to add a callback that notifies tracing progress
> to autotrace?

--report-progress
	 I've added a function that notifies the tracing progress
         in real time. C API is also added.

at_splines_type * at_splines_new_with_progress (at_bitmap_type * bitmap,
						 at_fitting_opts_type * opts,
						 at_progress_func notify_progress,
						 address client_data);

Masatake YAMATO

Dear Wladimir,

sorry also next version will contain this bug. I'll try to fix the problem with
the gaps but it will take a long time because large parts of the code have to be
rearranged. It is also my aim to remove this since a long time but I wasn't able
yet. I also send this message to the AutoTrace mailing list, because it would be
possible that someone who has currently more time will fix this.

Martin

Vladimir Voskresensky schrieb:

> Dear Martin,
>
> I'm very glad to see your wonderful application.
> I'm student of St-Petersburg State University, Russia, and AutoTrace is very
> useful for my Ph.D. thesis...
> Could you help me?
>
> Attached you find original bmp file and some screenshots with problem
> places:
> - SFXX200_24b.bmp - original file to trace
> - Screenshot of one place of raster file - OriginalWOGaps.bmp (no problem
> before tracing)
> - Screenshot of result *.emf file - BadResult.bmp (created with version
> 0.27a and option -error-threshold= 10e-5):
> o As you can see originally neighbor domains now a not connected with common
> edges (white gaps between them).
> o I understand that question "Why?" is strange, because it gives a lot of
> trouble while describing, but, please, help me how to prevent such
> situations, if it is possible to prevent.
>
> Best regards, Vladimir.
>
>   ------------------------------------------------------------------------
>                Name: Pics.zip
>    Pics.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>            Encoding: base64

I think it is nice for interactive application if we can cancel
running autotrace thread safely from another thread
How do you think?

I'll try to put "canncel point" into autotrace code in the
future.

Masatake

Good idea!

Masatake YAMATO schrieb:

> I think it is nice for interactive application if we can cancel
> running autotrace thread safely from another thread
> How do you think?
>
> I'll try to put "canncel point" into autotrace code in the
> future.
>
> Masatake
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

I've put `cancel point' mechanism.

=========================
/* notify_progress is called repeatedly inside at_splines_new_full
    to notify the progress of the execution. This might be useful for
    interactive applications. notify_progress is called following
    format:

    notify_progress (percentage, progress_data);

    test_cancel is called repeatedly inside at_splines_new_full
    to test whether the execution is canceled or not.
    If test_cancel returns TRUE, execution of at_splines_new_full
    is stopped as soon as possible and returns NULL. If test_cancel
    returns FALSE, nothing happens. test_cancel  is called following
    format:

    test_cancel (testcancel_data);

    NULL is valid value for notify_progress and/or test_cancel if
    you don't need to know the progress of the execution and/or
    cancel the execution */
at_splines_type * at_splines_new_full (at_bitmap_type * bitmap,
				        at_fitting_opts_type * opts,
				        at_progress_func notify_progress,
				        address progress_data,
				        at_testcancel_func test_cancel,
				        address testcancel_data);
=========================

`cancel point' is useful only for applications using multithread.
But I don't introduce any dependency for thread libs.

pseudo code for pthread:

struct testcancel_t
{
	 pthread_mutex_t * lock;
	 bool cancel; 	 /* default value: FALSE */
};

bool
test_cancel_for_pthread (struct testcancel_t * testcancel_data)
{
	 bool tmp;
	 pthread_mutex_lock(testcancel_data->lock);
	 tmp = testcancel_data->cancel;
	 pthread_mutex_unlock(testcancel_data->lock);
	 return tmp;
}

void
cancel_autotrace(struct testcancel_t * testcancel_data)
{
	 pthread_mutex_lock(testcancel_data->lock);
	 testcancel_data->cancel = TRUE;
	 pthread_mutex_unlock(testcancel_data->lock);
}

I don't test codes. But there is no effect on `autotrace' commands.
The commands is a single thread program and it is nothing to do
with `cancel point' mechanism.

thin_image takes long time. Putting `progress notify' mechanism and
`cancel point' mechanism are the future work.

2001-11-11  Masatake YAMATO  <jet@...>

	 * pxl-outline.c (find_outline_pixels):
	 (find_centerline_pixels): Put cancel points.

	 * main.c (main): Use at_splines_new_full.

	 * fit.[hc] (fitted_splines): Put cancel points.
	 If `test_cancel' is given and it returns TRUE,
	 execution is stopped and the control is returned.

	 * types.h (testcancel_func): New type.

	 * autotrace.h (at_testcancel_func): New type.

	 * autotrace.[hc] (at_splines_new_full): New function.
	 at_splines_new_with_progress is removed.
	 at_splines_new_full is almost the same as
	 `at_splines_new_with_progress' but has cancel points.

There is a real bug in AutoTrace, but currently I am very bussy and you will
have to wait some time till I'll find the time to fix it. So if anyone has
currently more time please help to fix this ugly bug.

Thanks
Martin

--- Weitergeleitete Nachricht / Forwarded Message ---
Date: Tue, 13 Nov 2001 15:05:25 +0100
From: Han-Wen Nienhuys <hanwen@...>
To: Martin Weber <martweb@...>
Subject: Re:

>
> martweb@... writes:
> >
> > I tried to understand the patch, it was not always easy. My opinion
> > is that this patch isn't neccessary and also produces sometimes
> > wrong results. I think calling AutoTrace with the option
> > background-color FFFFFF should do the same on pictures that contain
> > only black and white. Please test this with the unpatched
> > version. If problems occur contact me.
>
> Find a bitmap that causes an error  at
>
>   http://www.cs.uu.nl/~hanwen/pktrace/at-crash.pbm
>
> With -background-color FFFFFF, autotrace dies with
>
>   fatal: zero determinant of C0*C1.
>
> Without -background-color, it seems to work OK.
>
> Finally, I spoke to Szabo, but it turns out he isn't interested in
> improving anything at all (i.e. reporting bugs, improving his own
> package), so I left him out kind of the CC list.
>
> BTW, you might want to link pktrace from the Autotrace homepage. It's
> on
>
>   http://www.cs.uu.nl/~hanwen/pktrace/
>
>
> --
>
> Han-Wen Nienhuys   |   hanwen@...    | http://www.cs.uu.nl/~hanwen/
>

--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

I found a much simpler image that crashes AutoTrace. Here it is (crash.bmp).

Han-Wen Nienhuys schrieb:

> martweb@... writes:
> >
> > I tried to understand the patch, it was not always easy. My opinion
> > is that this patch isn't neccessary and also produces sometimes
> > wrong results. I think calling AutoTrace with the option
> > background-color FFFFFF should do the same on pictures that contain
> > only black and white. Please test this with the unpatched
> > version. If problems occur contact me.
>
> Find a bitmap that causes an error  at
>
>   http://www.cs.uu.nl/~hanwen/pktrace/at-crash.pbm
>
> With -background-color FFFFFF, autotrace dies with
>
>   fatal: zero determinant of C0*C1.
>
> Without -background-color, it seems to work OK.
>
> Finally, I spoke to Szabo, but it turns out he isn't interested in
> improving anything at all (i.e. reporting bugs, improving his own
> package), so I left him out kind of the CC list.
>
> BTW, you might want to link pktrace from the Autotrace homepage. It's
> on
>
>   http://www.cs.uu.nl/~hanwen/pktrace/
>
> --
>
> Han-Wen Nienhuys   |   hanwen@...    | http://www.cs.uu.nl/~hanwen/

I fixed the bug. Masatake please add it to the cvs (Changelog: fixed a
problem in calculation of halftangent with cyclic curves). Han-Wen please
test the code again and tell me if all works fine for pktrace.

--- c:\cvs\fit.c Mon Oct 29 21:15:44 2001
+++ fit.c Fri Nov 16 20:23:24 2001
@@ -1352,7 +1352,7 @@
  {
    unsigned p;
    int factor = to_start_point ? 1 : -1;
-  unsigned tangent_index = to_start_point ? 0 : c->length - 1;
+  unsigned tangent_index = (to_start_point || c->cyclic) ? 0 : c->length -
1;
    real_coordinate_type tangent_point = CURVE_POINT (c, tangent_index);
    vector_type tangent = { 0.0, 0.0 };
    unsigned int surround;


Han-Wen Nienhuys schrieb:

> martweb@... writes:
> >
> > I tried to understand the patch, it was not always easy. My opinion
> > is that this patch isn't neccessary and also produces sometimes
> > wrong results. I think calling AutoTrace with the option
> > background-color FFFFFF should do the same on pictures that contain
> > only black and white. Please test this with the unpatched
> > version. If problems occur contact me.
>
> Find a bitmap that causes an error  at
>
>   http://www.cs.uu.nl/~hanwen/pktrace/at-crash.pbm
>
> With -background-color FFFFFF, autotrace dies with
>
>   fatal: zero determinant of C0*C1.
>
> Without -background-color, it seems to work OK.
>
>
> BTW, you might want to link pktrace from the Autotrace homepage. It's
> on
>
>   http://www.cs.uu.nl/~hanwen/pktrace/
>
> --
>
> Han-Wen Nienhuys   |   hanwen@...    | http://www.cs.uu.nl/~hanwen/

I've just commited.

> I fixed the bug. Masatake please add it to the cvs (Changelog: fixed a
> problem in calculation of halftangent with cyclic curves). Han-Wen please
> test the code again and tell me if all works fine for pktrace.

Masatake

Dear Han-Wen, dear all,

the following two errors have both the same reason, the filtering routine in
fit.c If you use high values for filter-iterations small curves collapse to a
single point. Currently I don't know how to solve it. Any ideas for better
curve filtering routines that do not cause a collapsing are highly welcome.

Martin

Han-Wen Nienhuys schrieb:

> martweb@... writes:
> > I fixed the bug. Masatake please add it to the cvs (Changelog: fixed a
> > problem in calculation of halftangent with cyclic curves). Han-Wen please
> > test the code again and tell me if all works fine for pktrace.
>
> thanks for the fix. It fixes this particular glyph. In the pktrace run
> of last night, I found some two more problematic bitmaps (both of them
> are typewriter capital W):
>
>   blauw:~/usr/src/pktrace-0.3/pktrace.dir$ autotrace -background-color
>   FFFFFF  --input-format=pbm  --output-file=char.eps
>   -filter-iterations 9  assert.pbm
> autotrace: fit.c:1276: set_initial_parameter_values: Assertion
>   `((curve)->point_list[(curve)->length-1].t) != 0.0' failed.
> Aborted
>
> find it at http://www.cs.uu.nl/~hanwen/pktrace/assert.pbm
>
>   blauw:~/usr/src/pktrace-0.3/pktrace.dir$ autotrace -background-color
>   FFFFFF --input-format=pbm  -filter-iterations 9  crash.pbm
> fatal: zero determinant of C0*C1.
>
> find it at http://www.cs.uu.nl/~hanwen/pktrace/crash.pbm
>
> --
>
> Han-Wen Nienhuys   |   hanwen@...    | http://www.cs.uu.nl/~hanwen/

I need an idea how to improve the fitting quality for small letters. One
other problem is that a single point should give a circle after fitting
(composed by two smooth splines). Any help?

Thanks
Martin

Hi,

I'd like to remove types.h that is installed as a header file of
autotrace library.

Types defined in types.h might cause type name conflicting if
libautotrace.a is used as a componenet of a large application.
bool, string, address, real are typedef'ed in types.h.

I think we should define
at_bool, at_string, at_address, at_real
in autotrace.h and use these types in autotrace.h.

Instead of removing types.h, I'd like to introduce private.h
that is not installed.

In private.h:
#include "autotrace.h"
typedef at_bool    bool;
typedef at_string  string;
typedef at_address address;
typedef at_real    real;

I'll include private.h in all *.c files. Therefore no change
on *.c files is needed.

I'd like to do this before releasing 0.28.
How do you think?

I have a new code for despeckling images. I want to use it in AutoTrace.
It works well with indexed images. Then I ported it to 24 bit. The new
code doesn't work, but I was unable to find the error. So take a indexed
image and process it. Then convert this image to 24 bit and process it
with the new code. The results are different although they should be the
same. Where is the bug? Please help!!! I already had a look at several
hours, perhaps someone who didn't write the code will find it easier by
comparing both codes.

Thanks
Martin

Feel free to do it.

Masatake YAMATO schrieb:

> Hi,
>
> I'd like to remove types.h that is installed as a header file of
> autotrace library.
>
> Types defined in types.h might cause type name conflicting if
> libautotrace.a is used as a componenet of a large application.
> bool, string, address, real are typedef'ed in types.h.
>
> I think we should define
> at_bool, at_string, at_address, at_real
> in autotrace.h and use these types in autotrace.h.
>
> Instead of removing types.h, I'd like to introduce private.h
> that is not installed.
>
> In private.h:
> #include "autotrace.h"
> typedef at_bool    bool;
> typedef at_string  string;
> typedef at_address address;
> typedef at_real    real;
>
> I'll include private.h in all *.c files. Therefore no change
> on *.c files is needed.
>
> I'd like to do this before releasing 0.28.
> How do you think?
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

I found the bug!!!

I wrote:
> > I'd like to remove types.h that is installed as a header file of
> > autotrace library.

Martin wrote:
> Feel free to do it.

I've added ptypes.h in which autotrace local private types are defined.
I think no type name conflicting occurs now.

Masatake

I've removed the last global variable `at_centerline' that makes
libautotrace.a thread unsafe. centerline is now in fit opts.

Buy 4 processors machine from Sun:-P

We need a cgm export for AutoTrace. Could anyone help?

Soon there will be a new release of AutoTrace. So please checkout the
cvs and tell me if all works for you so we can find any bugs before
releasing it.

Thanks
Martin

> Soon there will be a new release of AutoTrace. So please checkout the
> cvs and tell me if all works for you so we can find any bugs before
> releasing it.

Here a snapshot for one who cannot have CVS access:
ftp://ftp.gyve.org/pub/snapshot/autotrace-0.28pre1.tar.gz

Masatake

I think we should not use FATAL macro in a library.
Instead we should provide a way to return an error.

How do you think?

Testing 0.28 pre 1,
  when exporting as .fig files, all lines are saved as closed curves,
thus the letter S turns into 8 due to the curve closing.
Does anyone have a copy of the spec. for .fig files so I can fix this?

Regards, Dan.

On Sat, 24 Nov 2001, Dan Mills wrote:

> Testing 0.28 pre 1,
>  when exporting as .fig files, all lines are saved as closed curves,
> thus the letter S turns into 8 due to the curve closing.
> Does anyone have a copy of the spec. for .fig files so I can fix this?

Dan;
Please forward an example source file to me. I'll try to fix it.

Ian.
----------------------------------------------------------------------------
Ian MacPhedran,    Engineering Computer Centre,   2B13 Engineering Building,
University of Saskatchewan,  57 Campus Drive,  Saskatoon SK  S7N 5A9, CANADA
Phone: (306)966-4832 Fax: (306)966-5205  Email: Ian_MacPhedran@...

On Sat, 24 Nov 2001, Dan Mills wrote:

> Testing 0.28 pre 1,
>  when exporting as .fig files, all lines are saved as closed curves,
> thus the letter S turns into 8 due to the curve closing.
> Does anyone have a copy of the spec. for .fig files so I can fix this?
>
> Regards, Dan.

Dan;
Thanks for catching that. The enclosed patch should fix this.

Ian.
----------------------------------------------------------------------------
Ian MacPhedran,    Engineering Computer Centre,   2B13 Engineering Building,
University of Saskatchewan,  57 Campus Drive,  Saskatoon SK  S7N 5A9, CANADA
Phone: (306)966-4832 Fax: (306)966-5205  Email: Ian_MacPhedran@...

*** output-fig.c.orig Tue Nov 20 19:29:44 2001
--- output-fig.c Tue Nov 27 16:48:53 2001
***************
*** 90,96 ****
   {
       unsigned this_list;
   /*    int fig_colour, fig_depth, i; */
!     int fig_colour, fig_fill, fig_width, i;
       int *spline_colours;

   /*
--- 90,96 ----
   {
       unsigned this_list;
   /*    int fig_colour, fig_depth, i; */
!     int fig_colour, fig_fill, fig_width, fig_subt, i;
       int *spline_colours;

   /*
***************
*** 218,223 ****
--- 218,224 ----
  	     if (j != 0) {fprintf(file,"\n");}
  	 } else {
  	     /* Polygons can be handled better as polygons */
+ 	    fig_subt = 3;
  	     if (pointcount == 2) {
  		 if ((pointx[0] == pointx[1]) && (pointy[0] == pointy[1])) {
  		     /* Point */
***************
*** 245,258 ****
  		 } else {
  		 if ((pointx[0] != pointx[pointcount-1]) ||
  		  (pointy[0] != pointy[pointcount-1])) {
  		 /* Need to have last point same as first for polygon */
  		     pointx[pointcount] = pointx[0];
  		     pointy[pointcount] = pointy[0];
  		     pointcount++;
  		 }
  		 fig_new_depth();
! 	 fprintf(file,"2 3 0 %d %d %d %d 0 %d 0.00 0 0 0 0 0 %d\n",
! 	 fig_width, fig_colour, fig_colour, fig_depth, fig_fill, pointcount);
  		 /* Print out points */
  		 j = 0;
  		 for (i=0; i<pointcount; i++) {
--- 246,263 ----
  		 } else {
  		 if ((pointx[0] != pointx[pointcount-1]) ||
  		  (pointy[0] != pointy[pointcount-1])) {
+ 		  if (shape.centerline) {
+ 		 fig_subt = 1;
+ 		  } else {
  		 /* Need to have last point same as first for polygon */
  		     pointx[pointcount] = pointx[0];
  		     pointy[pointcount] = pointy[0];
  		     pointcount++;
+ 		  }
  		 }
  		 fig_new_depth();
! 	 fprintf(file,"2 %d 0 %d %d %d %d 0 %d 0.00 0 0 0 0 0 %d\n",
! 	 fig_subt, fig_width, fig_colour, fig_colour, fig_depth, fig_fill,
pointcount);
  		 /* Print out points */
  		 j = 0;
  		 for (i=0; i<pointcount; i++) {

> Dan;
> Thanks for catching that. The enclosed patch should fix this.
>
> Ian.

Should I put the patch into our CVS repository?
Contributors, I'm happy if you write a ChangeLog entry like:

2001-11-21  Masatake YAMATO  <jet@...>

	 * ptypes.h: New file.

	 * Makefile.am: Added ptypes.h.

	 * types.h: Added "at_" as prefix to all type names.

	 * *.[ch]: Include ptypes.h.

2001-11-19  Martin Weber  <martweb@...>

	 * pxl-outline.c (find_one_outline): Fixed that sometimes the first
	 point of the outline is wrong

Dear Masatake,

I don't know much about fig but I think you should add the patch.

Martin

> > Dan;
> > Thanks for catching that. The enclosed patch should fix this.
> >
> > Ian.
>
> Should I put the patch into our CVS repository?
> Contributors, I'm happy if you write a ChangeLog entry like:
>
> 2001-11-21  Masatake YAMATO  <jet@...>
>
>  * ptypes.h: New file.
>
>  * Makefile.am: Added ptypes.h.
>
>  * types.h: Added "at_" as prefix to all type names.
>
>  * *.[ch]: Include ptypes.h.
>
> 2001-11-19  Martin Weber  <martweb@...>
>
>  * pxl-outline.c (find_one_outline): Fixed that sometimes the first
>  point of the outline is wrong
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

> Dear Masatake,
>
> I don't know much about fig but I think you should add the patch.

I've just commited wtih following log:

2001-11-28  Ian MacPhedran <Ian_MacPhedran@...>

	 * output-fig.c (out_fig_splines): introduce new local variable,
	 fig_subt. That fix a bug reported by Dan Mills
	 <dmills@...>.

	 "Testing 0.28 pre 1,
	  when exporting as .fig files, all lines are saved as closed curves,
	  thus the letter S turns into 8 due to the curve closing.
	  Does anyone have a copy of the spec. for .fig files so I can fix this?"

The AutoTrace cvs contains new code for exporting dxf. When using no
splines all works well but when using splines in the generated files the
files cannot be read by AutoCad. All of you who know about dxf please
help to fix it.

Thanks
Martin