GSoC 2013: Implement a new raster-to-vector algorithm...
I'll be coding for this project very soon and I created a repository for it at https://github.com/vinipsmaker/kopf2011 . When we decide where is the best place to keep the project during the WIP phase, I'll move it.
I'll be using the namespace *Kopf2011* for this library. If you don't like the namespace, let me know and I can change that.
I'll publish updates of the project at my personal blog at http://vinipsmaker.wordpress.com/category/computacao/gsoc2013-inkscape/ .
Let me know if you need anything else.
2013/5/28 Martin Owens <doctormo@...400...>
[...] Good luck!
Thanks.
I'm eager to produce results. =)
If you need help about implementing BSlines, or another thing, tell me. Good boxes
-----Mensaje original----- De: Vinícius dos Santos Oliveira <vini.ipsmaker@...400...> Para: Martin Owens <doctormo@...400...> Cc: Inkscape-dev inkscape-devel@lists.sourceforge.net Asunto: Re: [Inkscape-devel] GSoC 2013: Implement a new raster-to-vector algorithm... Fecha: Tue, 28 May 2013 22:23:08 -0300
2013/5/28 Martin Owens <doctormo@...400...>
[...] Good luck!
Thanks.
I'm eager to produce results. =)
------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2013/5/29 Jabier Arraiza <jabier.arraiza@...2893...>
If you need help about implementing BSlines, or another thing, tell me. Good boxes
Thanks.
I will. =)
On Tue, 2013-05-28 at 21:59 -0300, Vinícius dos Santos Oliveira wrote:
I'll be coding for this project very soon and I created a repository for it at https://github.com/vinipsmaker/kopf2011 . When we decide where is the best place to keep the project during the WIP phase, I'll move it.
The best place is on Launchpad. See the "Publishing your work on Launchpad" section:
http://wiki.inkscape.org/wiki/index.php/Working_with_Bazaar#Publishing_your_...
I'll be using the namespace Kopf2011 for this library. If you don't like the namespace, let me know and I can change that.
It might be better to use a more descriptive name. Kopf2011 is unlikely to be known by anybody who isn't already familiar with the paper.
I'll publish updates of the project at my personal blog at http://vinipsmaker.wordpress.com/category/computacao/gsoc2013-inkscape/ .
Excellent! At one time we required GSOC students to keep a blog. The blog posts were aggregated to planet.inkscape.org. Unfortunately, we seem to have lost the ability to administer this site and it is mostly filled with posts that have nothing to do with Inkscape.
Tav
2013/5/29 Tavmjong Bah <tavmjong@...8...>
I'll be using the namespace Kopf2011 for this library. If you don't like the namespace, let me know and I can change that.
It might be better to use a more descriptive name. Kopf2011 is unlikely to be known by anybody who isn't already familiar with the paper.
Just suggest a name.
On Wed, 2013-05-29 at 10:38 -0300, Vinícius dos Santos Oliveira wrote:
Just suggest a name.
Based on "The Kopf/Lischinski Vectorisation algorithm for depixelation of non-blended non-anti-aliased pixel art tied into Inkscape's Trace Bitmap feature":
"Depixelised Vectors" "Vectorise Pixel Art" "Tracing Pixel Art" "Pixel to Vector" "Pixel Tracing" "Dot to Dot"[1] "Smoothing Trace"
Martin,
2013/5/29 Martin Owens <doctormo@...400...>
On Wed, 2013-05-29 at 10:38 -0300, Vinícius dos Santos Oliveira wrote:
Just suggest a name.
Based on "The Kopf/Lischinski Vectorisation algorithm for depixelation of non-blended non-anti-aliased pixel art tied into Inkscape's Trace Bitmap feature":
"Depixelised Vectors" "Vectorise Pixel Art" "Tracing Pixel Art" "Pixel to Vector" "Pixel Tracing" "Dot to Dot"[1] "Smoothing Trace"
I think I'll use the "Tracer" namespace and specify the algorithm in the name of the class.
What do you guys think about use a more permissive license (LGPLv2.1 and later, MIT, ...) for the library?
On 05/31/2013 04:33 AM, Vinícius dos Santos Oliveira wrote:
What do you guys think about use a more permissive license (LGPLv2.1 and later, MIT, ...) for the library?
If you are writing this from scratch and seperating this into an isolated library, you could just dual-license it with a GPL variant and some sort of commercial license.
I do not like the idea of giving away work for commercial exploitation for free.
Regards, Sebastian
On Thu, 2013-05-30 at 23:33 -0300, Vinícius dos Santos Oliveira wrote:
I think I'll use the "Tracer" namespace and specify the algorithm in the name of the class.
I'm more concerned with what it will be called in the user interface :-) but what's the name of the algorithm? I couldn't find it in the paper.
What do you guys think about use a more permissive license (LGPLv2.1 and later, MIT, ...) for the library?
Unless you have a need to, stick to GPL and relicense later when you need to. If someone needs proprietary integration, then it might be something you can sell or negotiate later.
On Fri, 2013-05-31 at 12:42 +0200, Sebastian Götte wrote:
I do not like the idea of giving away work for commercial exploitation
for free.
Free and Open Source allows commercial use. I could quite legitimately sell Inkscape. We don't have a problem with commercial, we have a problem with proprietary ;-) Allowing anyone to make money from Free Software is part of the freedom.
Martin,
2013/5/31 Martin Owens <doctormo@...400...>
I'm more concerned with what it will be called in the user interface :-) but what's the name of the algorithm? I couldn't find it in the paper.
I didn't find, but the paper homepage ( http://research.microsoft.com/en-us/um/people/kopf/pixelart/ ) has a bibtex reference sample and the key used to reference this paper is kopf2011.
2013/5/31 Sebastian Götte <jaseg@...2974...>
On 05/31/2013 04:33 AM, Vinícius dos Santos Oliveira wrote:
What do you guys think about use a more permissive license (LGPLv2.1 and later, MIT, ...) for the library?
If you are writing this from scratch and seperating this into an isolated library, you could just dual-license it with a GPL variant and some sort of commercial license.
If I use a license compatible with GPL (like LGPL), there is no need to dual-license it.
Nobody seems to disapprove this idea, then I'll license it under LGPL, so other open source projects which use other licenses different than GPL might benefit from it.
Nobody seems to disapprove this idea, then I'll license it under LGPL, so
other open source projects which use other licenses different than GPL might benefit from it. Hmm, we've got different emails then? ;-) I thought it was already said that unless it is really necessary, you should use another license than the license the project uses. So please stick to GPL. Our license situation is already difficult enough. Thanks.
2013/5/31 Vinícius dos Santos Oliveira <vini.ipsmaker@...400...>
2013/5/31 Martin Owens <doctormo@...400...>
I'm more concerned with what it will be called in the user interface :-) but what's the name of the algorithm? I couldn't find it in the paper.
I didn't find, but the paper homepage ( http://research.microsoft.com/en-us/um/people/kopf/pixelart/ ) has a bibtex reference sample and the key used to reference this paper is kopf2011.
2013/5/31 Sebastian Götte <jaseg@...2974...>
On 05/31/2013 04:33 AM, Vinícius dos Santos Oliveira wrote:
What do you guys think about use a more permissive license (LGPLv2.1 and later, MIT, ...) for the library?
If you are writing this from scratch and seperating this into an isolated library, you could just dual-license it with a GPL variant and some sort of commercial license.
If I use a license compatible with GPL (like LGPL), there is no need to dual-license it.
Nobody seems to disapprove this idea, then I'll license it under LGPL, so other open source projects which use other licenses different than GPL might benefit from it.
-- Vinícius dos Santos Oliveira https://about.me/vinipsmaker
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2013/5/31 Kris De Gussem <kris.degussem@...400...>
Nobody seems to disapprove this idea, then I'll license it under LGPL, so
other open source projects which use other licenses different than GPL might benefit from it. Hmm, we've got different emails then? ;-) I thought it was already said that unless it is really necessary, you should use another license than the license the project uses. So please stick to GPL. Our license situation is already difficult enough. Thanks.
I'm sorry. Dual-license then.
On Fri, 2013-05-31 at 11:01 -0300, Vinícius dos Santos Oliveira wrote:
I didn't find, but the paper homepage ( http://research.microsoft.com/en-us/um/people/kopf/pixelart/ ) has a bibtex reference sample and the key used to reference this paper is kopf2011.
Oh that, that's just the meta data id
I was hoping to convince you of the lack of elegance of the 'kopf2011' string. It can't be pronounced (in English). Is there anything else we can use instead?
Martin,
2013/5/31 Martin Owens <doctormo@...400...>
On Fri, 2013-05-31 at 11:01 -0300, Vinícius dos Santos Oliveira wrote:
I didn't find, but the paper homepage ( http://research.microsoft.com/en-us/um/people/kopf/pixelart/ ) has a bibtex reference sample and the key used to reference this paper is kopf2011.
Oh that, that's just the meta data id
I was hoping to convince you of the lack of elegance of the 'kopf2011' string. It can't be pronounced (in English).
Isn't more important to use a name that uniquely identify the thing? We can pronounce kopf the same way we pronounce http (letter by letter).
In the Inkscape interface, we can simply put the text "convert pixel art", but in the program source code, there should be more detail.
I'm open to suggestions anyway.
Is there anything else we can use instead?
The last paper I've read name the technique in the paper title, but this vectorization paper is very different. I've skimmed the paper one more time and the references to the algorithm aren't named:
- "We describe a novel algorithm [...]" - "Our algorithm extracts [...]" - "We applied our algorithm [...]" - "We have presented an algorithm [...]"
PS.: I'm coding aside from discussing the library. You guys don't need to worry about the timeline or me spending time in this discussion. =P
On Fri, May 31, 2013 at 01:04:56PM -0300, Vin??cius dos Santos Oliveira wrote:
2013/5/31 Martin Owens <doctormo@...400...>
On Fri, 2013-05-31 at 11:01 -0300, Vin??cius dos Santos Oliveira wrote:
I didn't find, but the paper homepage ( http://research.microsoft.com/en-us/um/people/kopf/pixelart/ ) has a bibtex reference sample and the key used to reference this paper is kopf2011.
Oh that, that's just the meta data id
I was hoping to convince you of the lack of elegance of the 'kopf2011' string. It can't be pronounced (in English).
Isn't more important to use a name that uniquely identify the thing? We can pronounce kopf the same way we pronounce http (letter by letter).
In the Inkscape interface, we can simply put the text "convert pixel art", but in the program source code, there should be more detail.
I'm open to suggestions anyway.
Is there anything else we can use instead?
I think kopf2011 is a fine name - it's pretty much how it would be referenced in any academic paper, so it's typically how algorithms are named unless the author provides a very memorable name. kopf doesn't seem hard to pronounce to me.
PS.: I'm coding aside from discussing the library. You guys don't need to worry about the timeline or me spending time in this discussion.
Naming is a very important part of coding.
=P
=P
njh
On Fri, 2013-05-31 at 13:04 -0300, Vinícius dos Santos Oliveira wrote:
The last paper I've read name the technique in the paper title, but this vectorization paper is very different. I've skimmed the paper one more time and the references to the algorithm aren't named:
Then perhaps just call it 'depixeliser algorhythum' shortened to depixeliser in code?
2013/5/31 Martin Owens <doctormo@...400...>
On Fri, 2013-05-31 at 13:04 -0300, Vinícius dos Santos Oliveira wrote:
The last paper I've read name the technique in the paper title, but this vectorization paper is very different. I've skimmed the paper one more time and the references to the algorithm aren't named:
Then perhaps just call it 'depixeliser algorhythum' shortened to depixeliser in code?
The "depixeliser algorhythum" name has problem that kopf2011 name doesn't have: name clash
As Martin Sucha stated, the library could implement other algorithms in future and *any* raster-to-vector algorithm could be the "depixeliser algorhythum", but only one could be kopf2011. We also should use the same name that other projects could possibly use (JPEG is JPEG everywhere).
I like kopf2011, maybe without year...
El vie, 31-05-2013 a las 13:04 -0300, Vinícius dos Santos Oliveira escribió:
2013/5/31 Martin Owens <doctormo@...400...> On Fri, 2013-05-31 at 11:01 -0300, Vinícius dos Santos Oliveira wrote: > I didn't find, but the paper homepage > ( http://research.microsoft.com/en-us/um/people/kopf/pixelart/ ) has a > bibtex reference sample and the key used to reference this paper is > kopf2011. >
Oh that, that's just the meta data id I was hoping to convince you of the lack of elegance of the 'kopf2011' string. It can't be pronounced (in English).Isn't more important to use a name that uniquely identify the thing? We can pronounce kopf the same way we pronounce http (letter by letter).
In the Inkscape interface, we can simply put the text "convert pixel art", but in the program source code, there should be more detail.
I'm open to suggestions anyway.
Is there anything else we can use instead?The last paper I've read name the technique in the paper title, but this vectorization paper is very different. I've skimmed the paper one more time and the references to the algorithm aren't named: * "We describe a novel algorithm [...]" * "Our algorithm extracts [...]" * "We applied our algorithm [...]" * "We have presented an algorithm [...]"
PS.: I'm coding aside from discussing the library. You guys don't need to worry about the timeline or me spending time in this discussion. =P
-- Vinícius dos Santos Oliveira https://about.me/vinipsmaker
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2013/5/28 Vinícius dos Santos Oliveira <vini.ipsmaker@...400...>
I'll be coding for this project very soon and I created a repository for it at https://github.com/vinipsmaker/kopf2011 . When we decide where is the best place to keep the project during the WIP phase, I'll move it.
Changes based on the feedback:
- Moved to project to https://launchpad.net/libdepixelize (before was github) - libdepixelize instead kopf2011 - Tracer namespace instead kopf2011 - Dual licensed under GPLv2 or later and LGPLv2.1 or later - The name of the class containing the algorithm's implementation will continue to reference the "kopf2011" name
CMake is being used for the library, but I'll convert to autotools during Inkscape integration.
You can find an initial repo skel that copies the pixel data in a graph data structure and build instructions. I'm using Inkscape code convetions and Inkscape dependencies. I hope I didn't miss anything.
We actually also have cmake building available in Inkscape, so no need to convert, just add hooks for autotools in again to appropriate changes for cmake in-tree.
Cheers, Josh On Jun 2, 2013 9:48 PM, "Vinícius dos Santos Oliveira" < vini.ipsmaker@...400...> wrote:
2013/5/28 Vinícius dos Santos Oliveira <vini.ipsmaker@...400...>
I'll be coding for this project very soon and I created a repository for it at https://github.com/vinipsmaker/kopf2011 . When we decide where is the best place to keep the project during the WIP phase, I'll move it.
Changes based on the feedback:
- Moved to project to https://launchpad.net/libdepixelize (before was
github)
- libdepixelize instead kopf2011
- Tracer namespace instead kopf2011
- Dual licensed under GPLv2 or later and LGPLv2.1 or later
- The name of the class containing the algorithm's implementation will
continue to reference the "kopf2011" name
CMake is being used for the library, but I'll convert to autotools during Inkscape integration.
You can find an initial repo skel that copies the pixel data in a graph data structure and build instructions. I'm using Inkscape code convetions and Inkscape dependencies. I hope I didn't miss anything.
-- Vinícius dos Santos Oliveira https://about.me/vinipsmaker
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Jun 03, 2013 at 01:46:35AM -0300, Vin??cius dos Santos Oliveira wrote:
You can find an initial repo skel that copies the pixel data in a graph data structure and build instructions. I'm using Inkscape code convetions and Inkscape dependencies. I hope I didn't miss anything.
+ guint8 r; + guint8 g; + guint8 b; + guint8 a;
I would recommend against this approach, instead, use guint8 rgba[4];
and replace + _vertices[i].r = pixels[0]; + _vertices[i].g = pixels[1]; + _vertices[i].b = pixels[2]; + _vertices[i].a = pixels[3];
with for (int p = 0; p < 4; p++) { _vertices[i].rgba[p] = pixels[p]; }
It generally ends up being less work and less error prone.
njh
On Tue, 2013-06-04 at 02:02 +1000, Nathan Hurst wrote:
for (int p = 0; p < 4; p++) { _vertices[i].rgba[p] = pixels[p]; }
I'm surprised there's not a better way to do a list assignment, but I guess C++ means it's not slow to loop and still recognizable to other devs.
Martin,
On Mon, Jun 03, 2013 at 12:16:58PM -0400, Martin Owens wrote:
On Tue, 2013-06-04 at 02:02 +1000, Nathan Hurst wrote:
for (int p = 0; p < 4; p++) { _vertices[i].rgba[p] = pixels[p]; }
I'm surprised there's not a better way to do a list assignment, but I guess C++ means it's not slow to loop and still recognizable to other devs.
Well STL provides copy(...), but in my experience it's harder to use, more error prone and harder to read. In practice the compiler turns these loops into whatever is fastest (in this cases probably a 32 bit load and store).
njh
2013/6/3 Nathan Hurst <njh@...1927...>
guint8 r;guint8 g;guint8 b;guint8 a;I would recommend against this approach, instead, use guint8 rgba[4];
and replace
_vertices[i].r = pixels[0];_vertices[i].g = pixels[1];_vertices[i].b = pixels[2];_vertices[i].a = pixels[3];with for (int p = 0; p < 4; p++) { _vertices[i].rgba[p] = pixels[p]; }
It generally ends up being less work and less error prone.
Done: http://bazaar.launchpad.net/~vinipsmaker/libdepixelize/trunk/revision/2
Only a small change for now. I'll try to do more later today.
Hi,
Sorry if this is slightly OT but :
Can someone comment how it will perform compared to http://ralph.cs.cf.ac.uk/papers/geometry/cartoonvectorization.pdf ?
It looks like it gives good output compared to Adobe Live Trace.
IANAL but it looks like it's an (patent free) enhancement of a previous work of http://dcgi.felk.cvut.cz/home/sykorad/ (*) which is patent free too.
So maybe there are tricks that could be "borrowed" to make the "kopf" even better ?
thx
PS:
* there are some interesting video about vector animation
2013/7/1 pennec victor <v1nkscaper@...400...>
Can someone comment how it will perform compared to http://ralph.cs.cf.ac.uk/papers/geometry/cartoonvectorization.pdf ?
I just skimmed through the paper, but if I understood correctly, this paper and kopf's paper are facing very distinct challenges and they both may give good results in their areas, but they will probably be awful if misused.
Kopf's face problems where every pixel matters (pixel art), but this one doesn't care.
Kopf's doesn't care about temporal coherence, but this one takes this challenge at the very beginning.
...
participants (10)
-
Jabier Arraiza -
Jabiertxo Arraiza Cenoz -
Josh Andler -
Kris De Gussem -
Martin Owens -
Nathan Hurst -
pennec victor -
Sebastian Götte -
Tavmjong Bah -
Vinícius dos Santos Oliveira