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

Re: [AutoTrace] Future of AutoTrace

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 of 14 , Jun 8 10:55 PM
                    • 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 10 of 14 , Jun 27 6:26 AM
                      • 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 11 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 12 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 13 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.