Loading ...
Sorry, an error occurred while loading the content.

Future of AutoTrace

Expand Messages
  • Martin Weber
    AutoTrace has several weaknesses so we have to do some redesigns. One will be to add a new way to handle lists. This could be either done using STL or glib.
    Message 1 of 14 , Mar 14, 2002
    • 0 Attachment
      AutoTrace has several weaknesses so we have to do some redesigns. One will
      be to add a new way to handle lists. This could be either done using STL or
      glib. STL will lead to a better performance on an Intel PC, but we will have to
      use C++. As earlier mails showed that the acceptance of C++ for many people
      who helped to improve AutoTrace is low. I personally like C++, but I also
      accept not to use it. Glib also has several other interesting functionality as
      an interesting plugin concept so we will use it in future versions (0.31 or
      later). If you have any comments on this please feel free to send them to this
      mailing list.

      Martin

      --
      GMX - Die Kommunikationsplattform im Internet.
      http://www.gmx.net
    • rob@mediasolution.it
      ... Could you elaborate more on this? I know this is mainly a problem of mine, since I ve not been able to study autotrace sources deeply, but knowing where
      Message 2 of 14 , Mar 14, 2002
      • 0 Attachment
        > AutoTrace has several weaknesses so we have to do some redesigns.

        Could you elaborate more on this? I know this is mainly a problem of mine,
        since I've not been able to study autotrace sources deeply, but knowing
        where are the major problems could help all to better understand which
        kind of work is ahead (and help me especially to find the useful spots to
        study :-)

        > One will be to add a new way to handle lists.

        You mean we need faster list management functions? Or more flexibility? Is
        there a specific reason we need better list handling, for example to be
        able to do better tracing, or segments "joining" to have smaller and more
        manageable vector images.

        I know I may appear a little "dense" :-) but I'd like to help and the time
        I can spend on AT (like yours all, I imagine) is rather limited.


        Ciao,
        Roberto.
      • Martin Weber
        Here some things that came to my mind: 1.) Bad list management, that means the generation of lists is time consuming and fragmentates the main storage. 2.)
        Message 3 of 14 , Mar 14, 2002
        • 0 Attachment
          Here some things that came to my mind:
          1.) Bad list management, that means the generation of lists is time
          consuming and fragmentates the main storage.
          2.) Outlines are traced two times that means that it could be faster and if
          we trace and fit every outline only once we will not have the problems with
          unwanted gaps anymore.
          3.) Till now there are only very few code optimizations.
          4.) Bitmap handling is fast but not very usefull for large pictures that
          means images have to fit completely into memory.
          5.) No support of image libraries as freeimage or paintlib.
          6.) dxf export has currently no spline support
          7.) Fitting quality could be optimized towards the program Scanfont.
          8.) Better thinning algorithm like CAT (Chordal Axis Transformation)
          9.) Also compressed pdf and svg export.
          10.) Recognition of Circle and Ellipse pieces
          11.) Addition of code to recognize lines, splines and circles even if there
          is a lot of noise
          12.) Graphical userinterface for all platforms
          13.) New algorithm to work best with antialiased pictures
          14.) 3D recognition
          15.) Plugin interface for import and export filters


          > > AutoTrace has several weaknesses so we have to do some redesigns.
          >
          > Could you elaborate more on this? I know this is mainly a problem of mine,
          >
          > since I've not been able to study autotrace sources deeply, but knowing
          > where are the major problems could help all to better understand which
          > kind of work is ahead (and help me especially to find the useful spots to
          > study :-)
          >
          > > One will be to add a new way to handle lists.
          >
          > You mean we need faster list management functions? Or more flexibility? Is
          >
          > there a specific reason we need better list handling, for example to be
          > able to do better tracing, or segments "joining" to have smaller and more
          > manageable vector images.
          >
          > I know I may appear a little "dense" :-) but I'd like to help and the time
          >
          > I can spend on AT (like yours all, I imagine) is rather limited.
          >
          >
          > Ciao,
          > Roberto.
          >
          >
          >
          >
          >
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >

          --
          GMX - Die Kommunikationsplattform im Internet.
          http://www.gmx.net
        • Masatake YAMATO
          ... I d like to support gdk-pixbuf for posix platforms. ... gdk-pixbuf can take import a filter as a plugin. freeimage cal also take import a filter as a
          Message 4 of 14 , Mar 15, 2002
          • 0 Attachment
            > 5.) No support of image libraries as freeimage or paintlib.

            I'd like to support gdk-pixbuf for posix platforms.

            > 15.) Plugin interface for import and export filters

            gdk-pixbuf can take import a filter as a plugin.
            freeimage cal also take import a filter as a plugin.
            So, if autotrace supports both gdk-pixbuf (on posix) and
            freeimage (on windows), I think autotrace itself does not
            need (*dynamic*) plugin interface. static plugin interface
            is nice for makeing code clear. These libraries will work
            much better work.

            * "dynamic plugin" means loading a module at runtime.
            * "static plugin" means linking a module at building time.

            In the other hand, there is no good export filter library. Therefore,
            we have to develop it. Further more, it is worth to distribute an
            export filter library separated from autotrace itself.
            We can call the library freevector or freefigure or figurelib:)

            Anyway, these tasks should be done after releasing 0.30.

            > 12.) Graphical userinterface for all platforms
            Work in progress for posix/gnome.

            the GUI program(frontline) has three aspects:
            1. standalone program
            2. sodipodi add-in
            3. library

            Masatake
          • rob@mediasolution.it
            ... Hmmm... I m starting to integrate AT with my cartoon program, and I m planning on using the QT functions to load images, convert the bitmaps to AT format
            Message 5 of 14 , Mar 15, 2002
            • 0 Attachment
              > 1.) Bad list management, that means the generation of lists is time
              > consuming and fragmentates the main storage.

              Hmmm... I'm starting to "integrate" AT with my cartoon program, and I'm
              planning on using the QT functions to load images, convert the bitmaps to
              AT format (seems easy) and then using the "original" AT vector lists to
              "populate" some object hierarchy still to be defined.

              Just speculating: the way I see the lists from "the outside" isn't too
              bad: after all, you do have all those things to put in lists, and if there
              aren't a lot of alloc-free-realloc cycles inside the tracing functions,
              there should not be too much memory fragmentation. Maybe avoiding the
              double pass you mention in point 2) will avoid a lot of fragmentation.

              > 4.) Bitmap handling is fast but not very usefull for large pictures that
              > means images have to fit completely into memory.

              I can't see this as a real limit, at least until you use AT on modern PC.
              Besides, for the occasional huge picture, I can always split it and
              combine the vectorfiles together.
              But I don't know: does anyone use regularly AT on really big images?

              > 9.) Also compressed pdf and svg export.
              > 12.) Graphical userinterface for all platforms
              > 15.) Plugin interface for import and export filters

              I see a "cultural" problem here: unix people would certainly prefer some
              simple, separate tools: they have many ways to convert from graphic format
              X to something AT can read, and they can use one of the output format to
              get another format they want (i.e. xyz2png, autotrace, ps2pdf)
              Windows users OTOH need a complete package, gibing them "full service":
              image loading, trace preview, interactive parameter manipulation, full
              multi format export capabilities.
              The problem is: I don't know if unix people (that already have the
              functionality using other tools) will want to work on internal copies of
              that functionality...

              Just my 2 Eurocent :-)


              Ciao,
              Rob!
            • Masatake YAMATO
              ... sodipodi add-in has just worked. http://autotrace.sourceforge.net/frontline/frontline.png The standalone program needs more work. I ll register FRONTLINE
              Message 6 of 14 , Mar 15, 2002
              • 0 Attachment
                > > 12.) Graphical userinterface for all platforms
                > Work in progress for posix/gnome.
                >
                > the GUI program(frontline) has three aspects:
                > 1. standalone program
                > 2. sodipodi add-in
                > 3. library

                sodipodi add-in has just worked.
                http://autotrace.sourceforge.net/frontline/frontline.png

                The standalone program needs more work.
                I'll register FRONTLINE to sourceforge.net soon.

                Masatake
              • Masatake YAMATO
                ... I ve just put tar.gz at sourceforge.net. http://autotrace.sourceforge.net/frontline/frontline-0.2.1.tar.gz See README in the tar.gz. Masatake
                Message 7 of 14 , Mar 16, 2002
                • 0 Attachment
                  > sodipodi add-in has just worked.
                  > http://autotrace.sourceforge.net/frontline/frontline.png
                  >
                  > The standalone program needs more work.

                  I've just put tar.gz at sourceforge.net.
                  http://autotrace.sourceforge.net/frontline/frontline-0.2.1.tar.gz

                  See README in the tar.gz.

                  Masatake
                • Masatake YAMATO
                  Hi, ... Interesting. Any comments and requests for autotrace.h are welcome. I d like to provide better function sets to access the output splines. Currently, a
                  Message 8 of 14 , Mar 19, 2002
                  • 0 Attachment
                    Hi,

                    Rob wrote:
                    > Hmmm... I'm starting to "integrate" AT with my cartoon program, and I'm
                    > planning on using the QT functions to load images, convert the bitmaps to
                    > AT format (seems easy) and then using the "original" AT vector lists to
                    > "populate" some object hierarchy still to be defined.

                    Interesting. Any comments and requests for autotrace.h are welcome.
                    I'd like to provide better function sets to access the output splines.
                    Currently, a library user access directly the output splines data
                    structure(nested lists). However, accessing directly nested lists
                    is very easy to be understood by a library user.

                    Masatake
                  • rob@mediasolution.it
                    ... Seems to be ok, it contains all the useful stuff, clearly described. ... I still have to test this, since I ve been caught in other problems (from
                    Message 9 of 14 , Mar 19, 2002
                    • 0 Attachment
                      > Interesting. Any comments and requests for autotrace.h are welcome.

                      Seems to be ok, it contains all the useful stuff, clearly described.

                      > I'd like to provide better function sets to access the output splines.
                      > Currently, a library user access directly the output splines data
                      > structure(nested lists). However, accessing directly nested lists
                      > is very easy to be understood by a library user.

                      I still have to test this, since I've been caught in other problems (from
                      customers with problems to QT3-KDE3 updates), and I've still to write some
                      "list-walking" code.
                      From the look of teh lists definitions in autotrace.h, as you say, it
                      should be fairly simple.

                      Ciao,
                      Roberto!
                    • Masatake YAMATO
                      Hi, signor Reberto ... I ve added list-walking code to autotrace itself. In output.h: void at_spline_list_foreach (at_spline_list_type *,
                      Message 10 of 14 , Jun 8, 2002
                      • 0 Attachment
                        Hi, signor Reberto

                        Time ago, you wrote:
                        > I still have to test this, since I've been caught in other problems (from
                        > customers with problems to QT3-KDE3 updates), and I've still to write some
                        > "list-walking" code.
                        > >From the look of teh lists definitions in autotrace.h, as you say, it
                        > should be fairly simple.

                        I've added list-walking code to autotrace itself.
                        In output.h:

                        void at_spline_list_foreach (at_spline_list_type *,
                        AtSplineListForeachFunc func,
                        at_address user_data);
                        void at_spline_list_array_foreach (at_spline_list_array_type *,
                        AtSplineListArrayForeachFunc func,
                        at_address user_data);

                        I'd like to know more about your Qt/KDE program.
                        I'm interested in a Qt based GUI of autotrace.

                        Masatake YAMATO
                      • rob@mediasolution.it
                        Sorry for the late reply, but I went to an animation festival for a week, and then fell hill due to the bad weather condition I had to endure while there. I m
                        Message 11 of 14 , Jun 27, 2002
                        • 0 Attachment
                          Sorry for the late reply, but I went to an animation festival for a week,
                          and then fell hill due to the bad weather condition I had to endure while
                          there.
                          I'm still trying to catch up with the email backlog... :-/

                          > I've added list-walking code to autotrace itself.
                          > In output.h:

                          Thanks, that could be useful :)

                          > I'd like to know more about your Qt/KDE program.
                          > I'm interested in a Qt based GUI of autotrace.

                          Basically, the program should be a cartoon creation aid, with the ambition
                          to become similar to the good professional programs like USAnimation or
                          Animo. But that won't be easy.

                          I'm planning to use the KDE scanning interface (to sane) to acquire images
                          (and the QT image loading functions to load them from disc), then to build
                          an interface for autotrace library, finally displaying the splines in a
                          QTCanvas, that has rather good support for displaying and editing vector
                          graphics objects.

                          I've been caught in a quite nasty backlog of work however, so I don't know
                          when I'll be able to release something useful.

                          Ciao,
                          Roberto.
                        • Masatake YAMATO
                          From: rob@mediasolution.it Subject: Re: [AutoTrace] Future of AutoTrace Date: Thu, 27 Jun 2002 15:26:47 +0200 ... Thank you for replying. I m very interested
                          Message 12 of 14 , Jul 2, 2002
                          • 0 Attachment
                            From: rob@...
                            Subject: Re: [AutoTrace] Future of AutoTrace
                            Date: Thu, 27 Jun 2002 15:26:47 +0200

                            > I'm planning to use the KDE scanning interface (to sane) to acquire images
                            > (and the QT image loading functions to load them from disc), then to build
                            > an interface for autotrace library, finally displaying the splines in a
                            > QTCanvas, that has rather good support for displaying and editing vector
                            > graphics objects.

                            Thank you for replying. I'm very interested in "an interface for autotrace library."
                            What kind of interface?
                            About "interface", I'd like to hear you comments about frontline.
                            Look at screenshots at:
                            http://autotrace.sf.net/frontline

                            Your image about the interface in your brain is different from frontline?
                            If the difference is small, I'd like to work on KDE version of frontline.
                            I'll provide it in library, so you could use it.

                            The problem is I don't have skill about C++/Qt/KDE.

                            Masatake
                          • rob@mediasolution.it
                            ... autotrace library. ... A lot of time ago I downloaded your Display Ghostscript version of frontline, and since then I ve liked the idea of creating an
                            Message 13 of 14 , Jul 4, 2002
                            • 0 Attachment
                              > Thank you for replying. I'm very interested in "an interface for
                              autotrace library."
                              > What kind of interface?

                              A lot of time ago I downloaded your Display Ghostscript version of
                              frontline, and since then I've liked the idea of creating an interactive
                              interface for autotrace. That's, IMHO, is really helpful to understand
                              what the many parameters do.

                              > About "interface", I'd like to hear you comments about frontline.

                              I was thinking about something similar to your interface, but maybe on two
                              levels: a first level with only the main parameters (if/when I'll be able
                              to understand exactly which they are :-) and a "extra panel" with the
                              "fine tuning" parms.

                              > Your image about the interface in your brain is different from
                              frontline?
                              > If the difference is small, I'd like to work on KDE version of
                              frontline.
                              > I'll provide it in library, so you could use it.

                              Its not really that different. But there are things I'd like to achieve
                              "globally" in my program user interface, for example not having "pop-up"
                              windows like in the gimp. I'd like to have a group of controls
                              "embeddable" in an existing, docked window pane.

                              > The problem is I don't have skill about C++/Qt/KDE.

                              I'll try to find time to read and understand frontline code, and to
                              understand how we could port it to KDE (I think the main problem will be
                              to rewrite the preview window to use Qt widgets), and maybe to try and
                              write a first port as a standalone application.

                              That said, since you already know C, it's easy to adapt your C knowledge
                              to understand/write some C++ code. Probably it won't be good clean object
                              oriented code (mine isn't either ;-), but if the problem is simple enough
                              (and writing a one pane user interface usually is), the solution can be
                              simple too: no need for 5 C++ classes with multiple inheritance. Using
                              Qt/KDE classes is simple enough if you understand the basis of the C++
                              syntax, and that's not difficult.

                              Regarding Qt/KDE, there are very good tools and documentation on the
                              Trolltech site, and on the various kde sites, mainly
                              http://developers.kde.org , and tools like KDevelop really help to start
                              building code quickly, if they support the kind of application you're
                              planning to write. As a matter of fact, I initially planned to build my
                              project Anitoolbox using GTK/Gnome, but after the Qt license change to GPL
                              I checked Qt/KDE, and the quality of their documentation and tools won me
                              over very quickly.

                              I hope to be able to get back to you with some news (or some questions)
                              soon.


                              Ciao,
                              Roberto.
                            • Masatake YAMATO
                              In private mail from Martin(quotation is permitted.) ... No concrete idea. Probably new gnome-canvas class is needed. Further more, I think modification for
                              Message 14 of 14 , Oct 4, 2002
                              • 0 Attachment
                                In private mail from Martin(quotation is permitted.)
                                > Dear Masatake,
                                >
                                > do you have an idea how to implement the new functionality of AutoTrace
                                > 0.31 in frontline. Now we have as output lines with variable thickness
                                > and we have to display this in frontline.
                                >
                                > Greetings
                                > Martin

                                No concrete idea. Probably new gnome-canvas class is needed. Further
                                more, I think modification for libart might be needed. It might be
                                not easy job.

                                For a while, I will not provide GUI for variable width untill I
                                can have free time to implement such big function. Of course,
                                someone implements, I'll include it with pressure.

                                I'll freeze to add more functions to frontline. I'll move to
                                sodipodi development. Probably Sodipodi has variable width.

                                Masatake
                              Your message has been successfully submitted and would be delivered to recipients shortly.