[Tracing] Report #8: Inkscape integration
I proposed a merge: https://code.launchpad.net/~vinipsmaker/inkscape/libdepixelize/+merge/185237
The code is based on current practice, I think (grep is my friend). The changes between my choices and the code that inspired me was favoring C ++ish interfaces when available.
I have to say that Inkscape is pretty huge and took me some time to finish this integration.
The whole libdepixelize was developed with Inkscape in mind and integration was very straigh forward. There are options to generate voronoi diagrams, B-Splines and optimized B-Splines. I'm still working on B-Splines optimization and it's not possible to get a optimized output right now, but the interface is done and after I implement this step the only update required will be a "libdepixelize release bumping", with no code changes required to Inkscape itself.
I went beyond Kopf-Lischinski to preserve more color information and the result is quite nice, but when you have a really evil gradient the result will be worse. The "worse" result is caused by a small bug (can and will be fixed) and have small artifacts (no crash, don't worry).
Also, I made a major refactor on a large part of the project that will make it 4 times more maintainable and greatly abstracts memory layout access. The memory layout access abstraction is important to implement the suggested improvement (cache oblivious algorithm) by Nathan Hurst.
I improved the "depixelize" binary, so it can be packed by distros.
This is what I remember so far, but there were a lot of changes and I'm sure I'm missing some one.
Now that I finished the Inkscape integration I'll be working on the B-Splines optimization.
Em Qui, 2013-09-12 às 07:43 -0300, Vinícius dos Santos Oliveira escreveu:
This is what I remember so far, but there were a lot of changes and I'm sure I'm missing some one.
I just remembered another thing: Somebody please create an icon for the "Trace pixel art" dialog. It's pretty ugly by now.
On Thu, 2013-09-12 at 07:47 -0300, Vinícius dos Santos Oliveira wrote:
I just remembered another thing: Somebody please create an icon for the "Trace pixel art" dialog. It's pretty ugly by now.
Please create a bug report, we can have a look at the icon situation :-)
Thanks so much for working on the feature, a quick question about the build system:
Will inkscape build without libdepixelise installed? If it's a separate library to be packaged into distributions. And should it be added to the trunk PPA build system so users can test this new feature?
Martin,
Em Qui, 2013-09-12 às 07:09 -0400, Martin Owens escreveu:
Please create a bug report, we can have a look at the icon situation :-)
Okay, I'll create a bug report after the branch is merged. =)
Thanks so much for working on the feature, a quick question about the build system:
Will inkscape build without libdepixelise installed? If it's a separate library to be packaged into distributions. And should it be added to the trunk PPA build system so users can test this new feature?
Yes, Inkscape will build without libdepixelize installed. libdepixelize is a "bundled lib" on the proposed merge.
If you build libdepixelize separately you will have a depixelize-kopf2011 binary that can be used to generate SVG files outside of Inkscape (it will be very helpful to script users convert large collections of pixel art assets).
I'm not used to PPAs, but if you are wondering that the library should be installed on the build environment, then you need not to worry. Like I said some lines above, libdepixelize is a "bundled lib" on the proposed merge. And I encourage users to test the branch (just don't bother me if a really intensive gradient based image produces shit). =P
I couldent wait to check!
El jue, 12-09-2013 a las 07:43 -0300, Vinícius dos Santos Oliveira escribió:
I proposed a merge: https://code.launchpad.net/~vinipsmaker/inkscape/libdepixelize/+merge/185237
The code is based on current practice, I think (grep is my friend). The changes between my choices and the code that inspired me was favoring C ++ish interfaces when available.
I have to say that Inkscape is pretty huge and took me some time to finish this integration.
The whole libdepixelize was developed with Inkscape in mind and integration was very straigh forward. There are options to generate voronoi diagrams, B-Splines and optimized B-Splines. I'm still working on B-Splines optimization and it's not possible to get a optimized output right now, but the interface is done and after I implement this step the only update required will be a "libdepixelize release bumping", with no code changes required to Inkscape itself.
I went beyond Kopf-Lischinski to preserve more color information and the result is quite nice, but when you have a really evil gradient the result will be worse. The "worse" result is caused by a small bug (can and will be fixed) and have small artifacts (no crash, don't worry).
Also, I made a major refactor on a large part of the project that will make it 4 times more maintainable and greatly abstracts memory layout access. The memory layout access abstraction is important to implement the suggested improvement (cache oblivious algorithm) by Nathan Hurst.
I improved the "depixelize" binary, so it can be packed by distros.
This is what I remember so far, but there were a lot of changes and I'm sure I'm missing some one.
Now that I finished the Inkscape integration I'll be working on the B-Splines optimization.
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Em Qui, 2013-09-12 às 19:40 +0200, Jabiertxo Arraiza Cenoz escreveu:
I couldent wait to check!
Enjoy it. ^^
Em Qui, 2013-09-12 às 07:43 -0300, Vinícius dos Santos Oliveira escreveu:
I proposed a merge: https://code.launchpad.net/~vinipsmaker/inkscape/libdepixelize/+merge/185237
Hi fellow devs,
I fixed the blockers issues pointed by Kris and some users (~suv and Jabier) successfully compiled the branch in their systems (MAC OS X and a Debian with disabled deprecated GLib features).
But... nobody gave me green light to merge commits. Anyway, I have commits right in the Inkscape repository and I wanna know if it's okay for me to do that (blocker issues with the merge are resolved).
I'm not as good with bzr as I am with git and I don't want to postpone this merge too much. If the branches diverge too much I'm not sure if I'll be able to merge them.
I think the only missing test is the CMake integration, but I cannot compile Inkscape with CMake in my system (even before these changes), then I cannot test.
I really liked Kris knowledge and I wanted to wait for his approval before do the merge, but him seems to be very busy and I don't know when he'll have time to look in my code again. Current integration is done and after any update to libdepixelize all I need to do is update its local copy in Inkscape (no changes required to the Inkscape code itself).
On Wed, 2013-09-18 at 22:13 -0300, Vinícius dos Santos Oliveira wrote:
But... nobody gave me green light to merge commits. Anyway, I have commits right in the Inkscape repository and I wanna know if it's okay for me to do that (blocker issues with the merge are resolved).
Hey Vinícius,
We try to get to code review as best we can and where we each know the code base. We're all still learning different bits of this massive beast that is inkscape. Sorry I couldn't go through it all.
If you're happy with it, then merge it to trunk. The thing about trunk is 'with great power comes great responsibility' and thus if something goes wrong, you should have the time/intention to help fix it too.
Best regards, Martin Owens
Em Qua, 2013-09-18 às 21:23 -0400, Martin Owens escreveu:
If you're happy with it, then merge it to trunk. The thing about trunk is 'with great power comes great responsibility' and thus if something goes wrong, you should have the time/intention to help fix it too.
Free software development is not something completely weird to me and I got the feeling that I should merge after I fixed the blocker issues and got no replies for some time. I just asked here in the list, because I thought it'd be disrespectful with all you guys. Thanks for the reply. I'm more confident now.
Code merged (with some updates regarding own Inkscape interfaces evolution).
Just a couple observations: 1) The English words chosen for the various fields in the UI are not very amateur (non-professional/non-educated) friendly. 2) The ability to hang Inkscape unintentionally if an image is not small enough (with no related warning) is disconcerting.
Granted, I didn't use small art as one of the first searches turned up when using the terms "8-bit zelda" was at a much higher resolution... which seemed like a good reason to test it. It seems like it should operate with relatively similar speed, regardless of size, when you're just dealing with interpreting "blocks" (granted I know on a technical level it's pixels, but uneducated users may run across something like http://fc07.deviantart.net/fs70/i/2011/340/9/3/link_the_legend_of_zelda_8bit... say "well, it's pixel art" because they're just looking at the blockiness of it and doing those simple searches). Again, I understand the technical meaning of pixels and what the intended functionality is, but perhaps if an image above a certain resolution is detected as the selection, the dialog should show a warning about the amount of time it may take.
Very nice results otherwise from my limited testing. :)
Cheers, Josh
On Wed, Sep 18, 2013 at 10:06 PM, Vinícius dos Santos Oliveira < vini.ipsmaker@...400...> wrote:
** Em Qua, 2013-09-18 às 21:23 -0400, Martin Owens escreveu:
If you're happy with it, then merge it to trunk. The thing about trunk is 'with great power comes great responsibility' and thus if something goes wrong, you should have the time/intention to help fix it too.
Free software development is not something completely weird to me and I got the feeling that I should merge after I fixed the blocker issues and got no replies for some time. I just asked here in the list, because I thought it'd be disrespectful with all you guys. Thanks for the reply. I'm more confident now.
Code merged (with some updates regarding own Inkscape interfaces evolution).
-- Vinícius dos Santos Oliveira https://about.me/vinipsmaker
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2013-09-19 at 01:02 -0700, Josh Andler wrote:
Just a couple observations: 1) The English words chosen for the various fields in the UI are not very amateur (non-professional/non-educated) friendly.
A tutorial would be of great help. For example, I tried this image:
http://invisible-island.net/xterm/images/icons-xterm-color_281.png
How can I reduce the number of objects that result from the tracing?
(BTW, "Trace Bitmap" is broken... gets the colors wrong.)
- The ability to hang Inkscape unintentionally if an image is not
small enough (with no related warning) is disconcerting.
Granted, I didn't use small art as one of the first searches turned up when using the terms "8-bit zelda" was at a much higher resolution... which seemed like a good reason to test it. It seems like it should operate with relatively similar speed, regardless of size, when you're just dealing with interpreting "blocks" (granted I know on a technical level it's pixels, but uneducated users may run across something like http://fc07.deviantart.net/fs70/i/2011/340/9/3/link_the_legend_of_zelda_8bit... and say "well, it's pixel art" because they're just looking at the blockiness of it and doing those simple searches). Again, I understand the technical meaning of pixels and what the intended functionality is, but perhaps if an image above a certain resolution is detected as the selection, the dialog should show a warning about the amount of time it may take.
Agreed, there should be an indication that the processing is going on if the time taken is expected to be above some threshold.
3) Voronoi diagram mode doesn't seem to merge adjacent "pixels" with same color values.
4) A future improvement would be to merge adjacent "pixels" if they can be represented by a single path with a gradient.
Very nice results otherwise from my limited testing. :)
+1
Tav
2013/9/19 Tavmjong Bah <tavmjong@...8...>:
On Thu, 2013-09-19 at 01:02 -0700, Josh Andler wrote:
Just a couple observations: 1) The English words chosen for the various fields in the UI are not very amateur (non-professional/non-educated) friendly.
A tutorial would be of great help. For example, I tried this image:
http://invisible-island.net/xterm/images/icons-xterm-color_281.png
How can I reduce the number of objects that result from the tracing?
(BTW, "Trace Bitmap" is broken... gets the colors wrong.)
This may be related to a recent change I made in the tracing code - it gets passed a GdkPixbuf in its native format, instead of the Cairo pixel format. I'll look into this.
Regards, Krzysztof
Em Qui, 2013-09-19 às 14:08 +0200, Tavmjong Bah escreveu:
- Voronoi diagram mode doesn't seem to merge adjacent "pixels" with
same color values.
That's the output of a Voronoi diagram. Several cells which contain all pixels that are closer to it than any other cell.
If user want to apply filters or add border, this output is more useful. And it's possible to sum the cells together, but the inverse process...
- A future improvement would be to merge adjacent "pixels" if they
can be represented by a single path with a gradient.
I've been thinking about create gradients (for similar colors) and simplify paths, but I still don't know how to properly implement this feature. I mean... what would be the center of the gradient? Maybe a linear gradient is not enough (depending on the input image).
When I play with the output of libdepixelize in Inkscape and manually add a gradient for similar colors, the result gets smooth and cool, but I wouldn't say it's "correct" (because of concerns highlighted in previous paragraph). Also, current implementation is "reversible" (you can get the original pixel art from libdepixelize output rendering to the 1:1 size and disabling antialiasing), but this change (gradient) would break this cool property.
On Thu, Sep 19, 2013 at 01:02:01AM -0700, Josh Andler wrote:
Just a couple observations: 1) The English words chosen for the various fields in the UI are not very amateur (non-professional/non-educated) friendly. 2) The ability to hang Inkscape unintentionally if an image is not small enough (with no related warning) is disconcerting.
Threading would solve this.... are we thinking about switching to c++11?
seemed like a good reason to test it. It seems like it should operate with relatively similar speed, regardless of size, when you're just dealing with interpreting "blocks"
I am not sure that the underlying algorithm is actually O(n) for n pixels, we have been talking about that, but I feel that correctness is more valuable for completion than scaling. A cancelable progress bar and a note that this is slow with large images should solve this problem while we think of suitable optimisations.
njh
Em Sex, 2013-09-20 às 02:21 +1000, Nathan Hurst escreveu:
are we thinking about switching to c++11?
Lambdas, foreach, type inference... C++11 would make my code sooo much beautiful. And I'd have automatic perfect forwarding for vectors thanks to move semantics, improving performance a little bit (only a little, I don't believe the overhead of the code is vector). =D'
C++11 could make 2geom more beautiful too (variadic templates replacing the several functions overload that just take one more extra Point argument in Path::appendNew).
As far as I can see, this is the only problem that prevents us from using c++11:
http://sourceforge.net/mailarchive/message.php?msg_id=30712885
Just search this thread for “c++11”.
“As I understand it, there isn't a suitable version of GCC available on
OS X yet.”
I don’t know whether this is still a problem, though.
Regards,
Markus
Von: Vinícius dos Santos Oliveira [mailto:vini.ipsmaker@...400...] Gesendet: Donnerstag, 19. September 2013 19:47 An: Nathan Hurst Cc: Inkscape-dev Betreff: Re: [Inkscape-devel] [Tracing] Report #8: Inkscape integration
Em Sex, 2013-09-20 às 02:21 +1000, Nathan Hurst escreveu:
are we thinking about switching to c++11?
Lambdas, foreach, type inference... C++11 would make my code sooo much beautiful. And I'd have automatic perfect forwarding for vectors thanks to move semantics, improving performance a little bit (only a little, I don't believe the overhead of the code is vector). =D'
C++11 could make 2geom more beautiful too (variadic templates replacing the several functions overload that just take one more extra Point argument in Path::appendNew).
Em Qui, 2013-09-19 às 01:02 -0700, Josh Andler escreveu:
- The English words chosen for the various fields in the UI are not
very amateur (non-professional/non-educated) friendly.
Did you noticed the tooltips? They are supposed to be helpful.
Anyway, I can create a tutorial on the wiki after finish the algorithm (I'm still working to optimize B-Splines and removing the staircasing artifact).
- The ability to hang Inkscape unintentionally if an image is not
small enough (with no related warning) is disconcerting.
Okay, I'll put a warning notice, but this is only a workaround. The real fix is a progress bar with the image being processed in a background thread. I can do that after I learn about Gtk+ event loop and how to pass messages with the gui thread.
Em Qui, 2013-09-19 às 14:28 -0300, Vinícius dos Santos Oliveira escreveu:
- The ability to hang Inkscape unintentionally if an image is not
small enough (with no related warning) is disconcerting.
Okay, I'll put a warning notice, but this is only a workaround. The real fix is a progress bar with the image being processed in a background thread. I can do that after I learn about Gtk+ event loop and how to pass messages with the gui thread.
Rev. 12546 contains the fix.
participants (8)
-
Jabiertxo Arraiza Cenoz -
Josh Andler -
Krzysztof Kosiński -
Markus Engel -
Martin Owens -
Nathan Hurst -
Tavmjong Bah -
Vinícius dos Santos Oliveira