Tentative patch for downscaling in Cairo
by Krzysztof Kosiński
Hello
I had a look at how complex would it be to add correct downscaling to
Cairo now that Pixman supports convolution filters. It turns out it
this is rather easy. Here is an initial, minimal attempt. It uses
convolution filters only if the image is being downscaled by more than
half a pixel in at least one dimension.
Some discussion:
1. The sampling and reconstruction kernels are picked in a way that
gives comparable quality when upscaling and downscaling. I paired box
sampling with bilinear reconstruction and impulse (point) sampling
with box reconstruction. This gives the expected result for NEAREST
filter. BEST filter uses Lanczos3 for both kernels.
2. Subsampling bits are always set to 1, since this doesn't seem to
affect quality at all.
3. I am not sure whether this code works correctly for matrices with a
skew component. It should be OK for any combination of scale, rotation
and translation.
4. This patch causes new failures in the test suite:
- recording-surface*: possibly an effect of improved quality.
- surface-pattern-scale-down*, surface-pattern-big-scale-down: the
reference images should be updated.
- pthread-same-source: I have no idea why this is failing, since this
test shouldn't even trigger the new code.
- large-source-roi: this test attempts to downscale an image which is
30000 pixels wide down to 7 pixels. The filter parameters seem to be
created correctly, but they might trigger an overflow somewhere in the
convolution code; the output rectangle is white instead of red, as if
nothing was drawn.
- device-offset-scale: there are subtle differences which look like
convolution-related smoothing; I'm not sure whether this is OK or not.
Note that master currently fails many more tests, I only listed new
failures cause by this patch.
Regards, Krzysztof Kosiński
9 years, 11 months
Safely mixing C/C++ bindings for GNOME libraries
by Alex Valavanis
Hi All,
Just a quick note about a common source of build failures (e.g., bug
#112274) [1].
Basically, we disable the use of deprecated GNOME library symbols
wherever possible so that we can avoid big API migration projects in
future. A common problem, however, is that some of the C++ bindings
(e.g., glibmm and gtkmm) use some of those deprecated symbols!
In other words:
Inkscape ----> glibmm ----> deprecated stuff in glib
\---> glib
\---> gtkmm ----> deprecated stuff in gtk+
\---> gtk+
So, even though we don't use deprecated stuff ourselves, we still need
to take a little care with this!
The solution is to ** Ensure that high-level dependencies are included
in our source before low-level dependencies **
For example, the Glib::Thread API in glibmm depends on deprecated
GThread stuff in glib.
We will get a build failure if we do the following...
#include <glib.h>
#include <glibmm/threads.h>
This is because the deprecated GThread stuff in <glib.h> will be
hidden by the C++ preprocessor. When <glibmm/threads.h> is
subsequently included, GThread stuff will therefore appear to be
undeclared and we get an error like this:
/usr/include/glibmm-2.4/threads.h:142:11: error: field ‘gobject_’ has
incomplete type
/usr/include/glibmm-2.4/glibmm/threads.h: In member function ‘GThread*
Glib::Threads::Thread::gobj()’:
The solution is to do the inclusions in this order:
#include <glibmm/threads.h>
#include <glib.h>
This now compiles correctly because when <glibmm/threads.h> itself
includes <glib.h>, it temporarily re-enables the deprecated stuff,
uses it, and then disables it again.
A couple of additional notes:
1. There's actually no need to #include <glib.h> after one of the
<glibmm/*.h> headers... it is already pulled into our source by the
glibmm header!
2. Remember that you have to avoid *any* inclusion on <glib.h> before
using a <glibmm/*.h> header. As such, it's safest to just put the C++
headers at the top of any source file: i.e.,
// Gtkmm/Glibmm headers first...
#include <gtkmm/aaa.h>
#include <gtkmm/bbb.h>
#include <glibmm/ccc.h>
#include <glibmm/ddd.h>
// Now include Inkscape stuff...
#include "ui/dialog/wibble.h"
#include "ui/dialog/wobble.h"
3. Ultimately, we can probably get rid of all direct usage of <glib.h>
and Gtk+ headers and replace them with their respective C++ binding
headers.
Cheers,
AV
[1] https://bugs.launchpad.net/inkscape/+bug/1122774
9 years, 11 months
Re: [Inkscape-devel] GSoC 2013: Implement a new raster-to-vector algorithm...
by Vinícius dos Santos Oliveira
2013/5/31 Martin Sucha <martin.sucha-inkscape@...2313...>
> What about something like libdepixelize? Although the name does not
> exactly mention pixel art, it seems it does not yield any hits in google
> yet.
My concern was about the name of the symbols/variables/classes/..., not the
library per se.
The library could implement (as you stated) other algorithms in future and
should use a generic name.
The potrace tool ( http://potrace.sourceforge.net/ ) uses the name tracing
to refer to this technique. I like both names (libtracer, libdepixelize)
and other names also (libvectorizer) and whatever you guys choose is fine
to me.
--
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker
9 years, 12 months
Re: [Inkscape-devel] New Inkscape Website (Staging)
by Martin Owens
Nicolas,
Thanks for getting back to me with some fantastic questions. I've pushed
the conversation to the inkscape developer mailing list so others can
stay up to date and offer their ideas.
...
On Fri, 2013-05-31 at 14:34 +0100, Nicolas Dufour wrote:
> I've started to work on translating pages and parts of the UI.
> Django-CMS is a bit complex and its website documentation somewhat
> cryptic, but it looks very interesting, and quite convenient for a
> translator.
It can take one like that. The template formula for including blocks of
CMSable widgets is something that may require refinement as we go
forwards. Especially for the front page. For now, we're using the most
basic formulations.
> I've just added a bug report about translated menus that are split in
> two lines and cause some issues
> (https://bugs.launchpad.net/inkscape-web/+bug/1186235). It's a very
> annoying problem, but I'm sure it won't be too difficult to solve. I
> also have some questions:
I saw the problem with the french menu and have already contacted the
designer and some other people to help solve the issue. There has been
no response as of yet, partly because of classes/exams. If anyone else
wishes to help solve the bug, please see the developers link below.
> * Regarding static content, we currently have some pages (tutorials
> and keys and mouse references) that are generated externally (see
> https://launchpad.net/inkscape-docs). How should we handle them? Note
> that the keys and mouse references are linked directly in the
> application and thus should be accessible from exactly the same
> localized URL (for French: http://inkscape.org/doc/keys048.fr.html).
I didn't know about the generative content, that's quite interesting. We
could either insert the generated content into the right cms widget
items, or do something else. It depends if we want the content committed
to bzr or just in the database with other content.
> * How will the news be managed? I see nothing about it on the website,
> but I guess that's something that won't be abandoned.
The news module is operational, but it has two big caveats: 1. English
only, 2. No on-site editing. Thus as the technical lead, I intend to
replace the news module with a newly written one which has both
multi-language and onsite editing.
> * The French menu is exactly as defined in
> http://staging.inkscape.org/fr/admin/cms/page/, but it's not the case
> with the other languages. Is the menu order language-dependent?
The CMS seems to order the menu according to how much has been
translated and which menu was edited last. It is not idea, but a fix
would require patching upstream.
> * Apparently, the website is synchronized to the LP code manually
> (I've ported images for the books page, but they are not on-line yet).
> Do you plan to give update access to someone else, or do you prefer
> that we ask you every time we something is committed.
The cron jobs are not complete, there is a bug report assigned to me.
Images should actually be uploaded via the CMS unless they are
non-content images for use in the style/theme of the website. I may have
to reverse your commit for now. If you get stuck adding images, let me
know and we'll figure it out together.
> Apart from it, I'd like to run a local version of the website for
> testing purposes. SQLite, Django, Django CMS and the dependencies are
> installed on my computer, but I still have difficulties with the CMS
> modules (Error: No module named cmsplugin_news, or Error: No module
> named cms.plugins.twitter if I comment the cmsplugin_news line). Do
> you have some documentation on how to run it (the README file didn't
> help)? I'm new to Django CMS, and not very experienced with Django and
> I've probably missed something obvious... If not, I'll try to search
> the web, there should be some tips somewhere.
Absolutely, at the bottom of the website there's a link "Website
development guide:" to this wiki page:
http://wiki.inkscape.org/wiki/index.php/WebSite and by following this
guide we hope, the website should work locally for development. This
also includes bringing in the data from the staging website, since the
cms would be empty otherwise.
Please continue to report bugs and press the website further :-)
Best Regards, Martin Owens
9 years, 12 months
I have a faster, SIMD IIR filter implementation, but have accuracy problems
by Yale Zhang
All,
I have ported the IIR filter implementation to use SSE intrinsics and have
achieved a 2.5x speedup so far. But I'm having accuracy problems for large
blurs due to using single precision instead of double.
I've attached examples outputs that blurs a box with several sizes. For
sigma=120, the annoying mach bands start getting noticeable. At sigma=200,
it looks very bad, and at 350, you might as well use it as a sharpen filter
:)
This is the first graphics application I've seen where single precision
isn't enough. Is the reason due to the recursive behavior of IIR (more
accumulation of error) ?
Basically, for large blurs (stdev > 100), 24 bits of precision isn't
sufficient and you end up getting very annoying mach bands. For sigma =
100, the filter coefficients are:
b[0] = 0.00000387430191040
b[1] = 2.96391582489013672
b[2] = -2.92843437194824219
b[3] = 0.96451467275619507
If I add b[0] to the other terms last (b[1] + b[2] + b[3]) + b[0],
(earlier, when I added the b[0] term to b[1], the accuracy was even worse
as expected), the alignment of the operands in binary is approximately:
1.00000000000000000000000
0.00000000000000000100000
meaning the addition loses a lot of the b[0] term's precision.
Can anyone suggest how to proceed next and how useful you think this
speedup is? (for me it's a moderate improvement because in my comic, I use
marble and brick textures for the walls and floors - I also vectorized the
turbulence generator).
I would like to avoid using double precision since SSE supports only 2
doubles per operation instead of 4 floats.
The things I thought about of trying next are:
1. Use int32 arithmetic (that would add 9 extra bits of precision)
2. Use 4 taps instead of 3. Would this really help? I don't know much about
IIR filter design. Can someone give me the coefficient formula for 4 taps?
Thanks for helping,
Yale
10 years
[CAD] Connectors and Symbols
by Martin Owens
Dear Sebastian Götte and Tavmjong Bah,
I'm working on these two items most keenly too, I would like to
participate in code review as well as design review for the blueprints
etc. The codebases for both items are not super big so I'd like to make
sure we don't start committing over each other since the GSoC projects
are nominally forked.
I have a UI change for symbols which is waiting merge. I'm also
interested in the design of the connectors since I know we all have
different ideas about how it should be done (elements vs attributes,
children vs groups). I'm not sure of the scope yet of the CAD work for
2013, can someone link me to the blueprint?
Best Regards, Martin Owens
10 years
[GSoC -Templates]
by Jan Darowski
Hi!
Thanks for accepting my proposal, I hope to be up to your expectations.
First of all, I would like to know few technical details:
Do you guys prefer mailing most of my questions to this list or directly to
the mentor? If the second option, which address?
What do you expect me to do during this period before official coding
start? I mean except google formal requirements and preparing everything
for the fast start.
Thanks,
Jan Darowski, Slagvi
10 years
[GSOC] Welcome to the 2013 GSOC students
by Tavmjong Bah
We have five successful GSOC proposals! Let me first congratulate the
students and wish them success this summer.
The five GSOC projects are:
1) An interactive tool for recoloring artwork.
Arshdeep Singh (demicoder), mentored by Ted Gould.[1]
2) Improved units support and consolidating units handling to one place.
Matthew Petroff, mentored by Johan Engelen.[2]
3) Electronics CAD support, focusing on improving connectors and
symbols.
Sebastian Götte (jaseg), mentored by Tavmjong Bah.[3]
4) A new dialog to create documents from templates.
Jan Darowski (Slagvi), mentored by Krzysztof Kosiński.[4]
5) A new raster-to-vector algorithm focusing on small images.
Vinícius dos Santos Oliveira (vinipsmaker), mentored by Nathan
Hurst.[5]
At this time I would like to remind the students to:
1. Keep discussions on inkscape-devel (or #inkscape on freenode for
quick questions).
This has several advantages: You can receive help and
advice from others; your mentor may not always be available
and may not even know the answer to your question (nobody
knows all of the Inkscape code). Others can learn from your
work. The project administrators will be kept up-to-date.
And it will keep the Inkscape community informed (and
excited) about your project.
To facilitate keeping track of the projects please put at
the start of the subject line an appropriate tag for your
project. I suggest the following:
[Recolor]
[Units]
[CAD]
[Templates]
[Tracing]
The subject line will then become, for example:
[Inkscape-devel][Recolor] ...
2. Set up a public bzr branch for your work.
Announce it on inscape-devel.
See: http://wiki.inkscape.org/wiki/index.php/Working_with_Bazaar
3. Give weekly status reports.
Also, I would like to remind you, that for the final pass, we expect
that your code be merged or ready to be merge into Inkscape trunk.
Good Luck!
Tav
[1]https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/ars...
[2]https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/mpe...
[3]https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/jas...
[4]https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/sla...
[5]https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/vin...
10 years
