So, I reached a point where I know how the next steps can be implemented, but, differently from before, the next steps on libdepixelize can have a big impact on how it will be integrated on Inkscape. I decided it would be a good thing to discuss this matter with other developers.
Currently it's possible to represent simple paths on libdepixelize (see this), but to implement the full Kopf-Lischinski algorithm, I'll need to have paths with "holes" and I'll need to use complex path representations with enough expressive power to communicate things like "point start in A, then do a Bézier to C...". I don't want to create a new interface to represent paths, because this interface already exists and it's called SVG.
Anyway, I'm sending this message now, but I'll look deeper in Inkscape code and come up with some design ideas later.
2013/8/1 Vinícius dos Santos Oliveira <vini.ipsmaker@...400...>
** So, I reached a point where I know how the next steps can be implemented, but, differently from before, the next steps on libdepixelize can have a big impact on how it will be integrated on Inkscape. I decided it would be a good thing to discuss this matter with other developers.
Currently it's possible to represent simple paths on libdepixelize (see this https://plus.google.com/118295250366112843114/posts/Mpk1yLuMbEY), but to implement the full Kopf-Lischinski algorithm, I'll need to have paths with "holes" and I'll need to use complex path representations with enough expressive power to communicate things like "point start in A, then do a Bézier to C...". I don't want to create a new interface to represent paths, because this interface already exists and it's called SVG.
Inkscape represents paths using Geom::PathVector, which is a vector of Geom::Path. Geom::Path represents a single contiguous subpath, while Geom::PathVector corresponds to an SVG path. Geom::Path is a collection of Geom::Curve, a virtual class which has subclasses like Geom::BezierCurve, Geom::LineSegment, Geom::EllipticalArc, and so on.
You can read the docs by checking out the lib2geom source tree and running Doxygen, or inspecting the headers in src/2geom in Inkscape source.
Regards, Krzysztof
Krzysztof and Jabiertxo,
thanks for the hints. I talked to Nathan and he also hinted one direction to go.
I delayed this task for later and I started to learn linear algebra (two large topics in two days, only other two missing). Reasons to study linear algebra ASAP started to grow.
Reason #1
I'll have to use this knowledge to understand harmonic maps (step done after B-Splines optimization in Kopf-Lischinski) to fix the positions.
Reason #2
Chat piece copied without authorization, but it doesn't reveal any secrets, then I think there won't be any problems. ;)
(15:00:28) Vinícius dos Santos Oliviera: I was wondering this about the sparse pixels heuristic, but I thought there is no way to fix sparse pixels (15:00:53) Vinícius dos Santos Oliviera: I think it could possible, somehow, to use dynamic programming in curves heuristic (15:00:55) Nathan Hurst: there might be :) (15:00:58) Nathan Hurst: yes (15:01:07) Nathan Hurst: it feels a bit like eigenvalues (15:01:13) Nathan Hurst: at the intuitive level (15:01:37) Vinícius dos Santos Oliviera: I'll do a research about eigenvalues, thanks for the tip
Reason #3
I'll have a test on Monday.
In the meantime
I implemented some easy tasks on libdepixelize that don't takes too much time like:
* API to tune heuristics values * The next post explaining the remaining of B-Splines extraction
participants (3)
-
Jabiertxo Arraiza Cenoz -
Krzysztof Kosiński -
Vinícius dos Santos Oliveira