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. =)

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 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,

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 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

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).

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.

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 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

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