Fwd: Re: [cairo] filters/image processing
by MenTaLguY
-------- Original Message --------
Subject: Re: [cairo] filters/image processing
Date: Fri, 24 Mar 2006 08:31:17 -0800
From: Carl Worth <cworth@...573...>
To: MenTaLguY <mental@...3...>
On Fri, 24 Mar 2006 10:23:31 -0500, MenTaLguY wrote:
>
> We've been discussing "Cairoification" in Inkscape recently again,
Sounds like fun!
> If we adopt Cairo, should we expect to always have to implement
> things like e.g. gaussian blur ourselves using intermediate image
> surfaces, or will Cairo eventually provide image processing
> operations like that in ways which can be accelerated in hardware?
We already have an API for specifying that a given filter should be
applied to a pattern, (cairo_pattern_set_filter), but the current
selection of filters is fairly limited here. So I see two things that
need to be done:
1) We need to add more filter types. Gaussian blur is an obvious first
one that needs to be added, and something I've been giving some
thought to lately. One trick with this is that it requires at least
one parameter, so the current cairo_filter_t enum is not going to
be sufficient.
Oh, look, there is even a CAIRO_FILTER_GAUSSIAN there already. I'm
not sure if that does anything useful or not yet.
2) We need to add support for filtering the implicit masks that cairo
generates. This is the right place to put a filter for doing
something like a drop shadow or for applying what Xara calls
"feathering" to a filled shape.
There's still a mask pattern involved here, but the user doesn't
get to see it since it is implicitly created by cairo. So I think
all we need here is a simple new API:
cairo_public void
cairo_set_mask_filter (cairo_t *cr, cairo_filter_t filter);
(Modulo the same enum limitations we discussed above.) So this
filter would be applied to the implicit masks created by
cairo_stroke, _fill, _show_text, and _show_glyphs. It would not
apply to cairo_mask where the user has a pointer to a pattern
already and can call cairo_pattern_set_filter.
As for what filter types to add, I think that "can be accelerated in
hardware" is a pretty good criterion for inclusion in cairo. I think
we've got Gaussian blur stuff just sitting there waiting in some
existing backends already.
As for a bunch of the other SVG filter types, I'm less confident that
we'll see a lot of hardware support for them. I don't think it makes
sense to complicate the cairo API for these if they're all going to
end up in software anyway. (Though, if someone can convince
programmable GPUs to do these, then there's a different question to be
asked---so let me know if you know someone that has figured that out.)
-Carl
17 years, 8 months
Check up time
by Mike Hearn
Hey guys,
I thought I'd pop in and see how you were getting on with autopackage. Are
there any issues I need to be aware of? Are you happy campers? Are there
any features you'd really like to have?
I'm asking so I can get a better idea of where we should be going in
future. Here is the current roadmap as relevant to Inkscape:
* Get 1.2 released. This brings:
* Better C++ support, that is, a build of the correct ABI will
always be installed for the user. This resolves various obscure
problems related to bugs in GCC and will allow for usage of gtkspell
(finally!)
* Better compression -> smaller Inkscape downloads
* Better uninstall support, can now check for RPM/debs of
Inkscape already being installed and (when safe) remove them.
* New binreloc system. If it works out then this will make it totally
transparent and the prefix location code could be dropped.
* Further out, automatic online updates and maybe support for abstracting
the Python unicode ABI so the python plugins support could be safely
enabled.
Any other features you guys want?
thanks -mike
17 years, 8 months
Educational contact(s)
by Jon A. Cruz
Hi,
Just trying to track down what kind of interest there is for being
point contact for .edu kind of people.
So, who's interested?
I can think of a few levels of involvement. There's working with
people trying to develop open source based curriculum, and then also
working with educators themselves. Also, both of those might be
further broken down by various age groups, technical programs, etc.
(I have various interests in this myself, but wanted to be sure to
find out who all is also interested)
17 years, 8 months
Libre Graphics Meeting - A Recap
by PLinnell
Hi all,
For those who were not able to attend and/or also wondering about the
quietness on IRC or the ML over the weekend, below is far from
complete summary of the Libre Graphics Meeting held this past weekend
in Lyon, France.
First, this was the first ever meet of all the Scribus devels in the
same place with the exception of Franz who could not attend.
This meeting came about from the generous offer of Dave Neary from the
GIMP team to bring in other graphics app developers such as Inkscape
and it soon snowballed into a larger meet. Dave and the local Linux
LUG group did a fantastic job organzing everything and a great time
was had by all.
One of the first presentations was by Øyvind Kolås aka pippin from the
GIMP team demoing working code using GEGL,babl and gggl , the next
generation of image libraries for the GIMP and other applications.
Most impressive is the way Øyvind used oxide and bauxite, which are
built from these components.
For end users, GEGL, babl and gggl are a means to break the current
limits in GIMP with 16bit and larger bit depths available, along with
the ability to support other color spaces like CieLAB and CMYK. When
can we see this in cvs ? The GIMP devs I spoke with said as soon as
2.4 is released.
Next up was Marti Maria from littlecms and now HP. He gave an
excellent presentation connecting how we see as humans with the
nature of digital color in computing. Suffice to say, Scribus is as
good as any at demonstrating littlecms' capabilities. Little known is
indeed littlecms is used in the color management firmware in a number
of high end HP specialty printers. We're hoping we can have that
presentation on the docs site as a primer for beginning with color
management.
Gerald Friedland gave a demo of SIOX or Simple Interactive Object
Extraction, which is in the current development version of GIMP.
Simply put, SIOX is a clever new way of selecting objects in an image
in a way which otherwise takes many manual steps. If you have a
chance to get the latest GIMP beta, it is worth it just to see this
in action. Who says open source folks do not innovate ?
Cedric Gemy, better know for his new book on GIMP 2.2 in French 'Gimp
2 efficace' gave a demo of Tuxpaint in French. If you can read
French, his new book is probably the most comprehensive book on GIMP
2.2.x
Jon Phillips from Inkscape gave a talk on Create and how open source
graphics applications are working to share things like brushes, color
swatches and other image oriented media.
Xara has been open sourced - a very bold move for a commercial
graphics application company. Xara is an illustration application
which has tremendous rendering speed on the canvas among other
assets. One of the principal reasons for open sourcing the "crown
jewels" as they put it, is to port Xara to Linux and MacOSX.
It was obvious from the interaction with other teams and developers
that not only the Xara folks were very much welcome there, but also
they have taken the open source development model to heart.
The Blender folks had a number of small talks and demos, but owning to
other meetings none of us had much time to participate.
One of the best parts of this meet was the time spent outside of the
presentations to be able to meet and interact with other teams.
Examples: Marti Maria from Littlecms gave us some hints on making
Scribus more robust when handling corrupted icc profiles. We also had
the chance to meet Carl Worth who developed Cairo.
Sunday afternoon was a chance to meet with the Inkscape team and we
looked over our mutual future plans. Jon Cruz from Inkscape showed
off a drag and drop debugging tool, which should help us with Scribus
to make drag and drop work easier with a more diverse group of
applications.
Similarly, we outlined how Scribus uses Ghostscript to import EPS and
PS files with high fidelity. Adding this to Inkscape should be
feasible without a major rewrite of Inkscape. The collaboration
between Inkscape and Scribus teams has been good and should be even
better in the future now we have met face to face. More to come later
on.
If there was one area lacking was simply time to meet and exchange
with everyone there. We had less time to meet with some of the GIMP
team than hoped, but we did have some informal one to one chats and
we are much more attuned to future plans and wishlists.
The GIMP team has been often unfairly criticized, in my opinion, for
perceived shortcomings and unwillingness to address long standing
feature requests. To the contrary, my sense is they are very well
aware of these requests, but they are a small team indeed, not much
larger than Scribus.
That said, what I saw and heard gives me confidence that the GIMP will
see major additions to its feature list in the future. The plans they
outlines for future versions are ambitious.
Other folks there included one of the Krita developers and folks from
the Tango Project.
One great surprise was to meet Nicholas Spalinger and Victor Gaultney,
creator of the award winning typeface Gentium, which has been
re-released under their newly written Open Font License. A few of us
over a dinner had a chance to learn a great deal about Gentium,
typography and future plans for enhancements and additions.
The Open Font License has been carefully researched and written to
maintain both openess and type creators desire for artistic
integrity. This license avoids the kind of ambiguity discussed a few
months ago on the list here about font embedding and the GPL.
Summing up, the meet exceeded everyone's expectations I suspect. The
atmosphere was fun, collegial and less a show and tell, than a chance
for lots of face to exchanges.
Attendance was roughly double the number anticipated. The simple fact
this kind of event took place is a testament to the capabilities and
maturity of open source graphics applications. Five years ago when
Scribus was launched, one could hardly imagine an event like this.
Already, it was decided amongst the teams to meet again next year and
work is underway already on a venue. Discussion and plans will take
place on the Create list on freedesktop.
I'm sure I missed some important bits, but maybe we will see you there
next year...
Peter
17 years, 8 months
Re: Live Effects Discussion
by Ricard Marxer Piñón
Hi there,
I was at the LGM this weekend and one of the Inkscape developpers
pointed me out to this list in order to discuss one of the concepts I
talked him about:
vector graphics shaders (as in 3D graphics shaders)
It's an idea I have been thinking about and working on for a while.
Today I had a look at the archives of the mailing-list and I just
found the thread on Live Effects Discussion. Which seems to be
exactly what I was looking for.
I think my point of view is not that different from yours but maybe
there are some new ideas. I basically try to recycle the work done on
the 3D shader field to what could be the 2D shader field.
>From my point of view we should define some perceptual data that
should be accessible to a shader programmer and some principle drawing
functions that he should be able to use. I haven't worked on it a lot
yet but some of these ideas are:
data accessible from a path:
- point (given the % of the arclength)
- tangent and / or normal (given the % of the arclength)
- curvature (given the % of the arclength) (this could be given by
the modulus of the tangent) (so it could be avoided)
- color (given the % of the arclength)
- stroke weigth (given the % of the arclength)
I guess the only thing hard to do here is the reparametrization for
the beziers or other curves in order to make this a function of the %
of the arclength. But I think that this is something that would make
this shaders powerful, since the shader shouldn't bother to know if
the path is made of curves, beziers or whatever he only needs what's
perceptually important about the vector graphic.
What do you think?
anyway here I post a little experiment with some experiments in vector
graphics renderers that I made (feedback is greatly appreciated!!!!):
http://www.caligraft.com
--
ricard
http://www.ricardmarxer.com
17 years, 8 months
Font issues
by Jon A. Cruz
I was taking a peek at bug 1456620, and hit an interesting problem.
There might be many other problems overlapping, but the name of one
has issues right off the bat.
One font name is 'Magnump.i.', but gets truncated at the first
period. Does anyone have insight on this?
17 years, 8 months
Live Effects Discussion
by Ted Gould
Hey all,
Sorry, I've been effectively offline for over a week, so I'm catching
up. I feel like I'm spamming the mailing lists :)
Anyway, Aaron, I noticed that you made a branch for live effects. I've
thought I little about this -- I was thinking perhaps we can all have a
big friendly discussion about some of the ideas/features that would be
required. (if there are any Xara developers on the list we'd love your
comments on what worked and what didn't) If nothing else, so we don't
overlap on any work.
Here are some thoughts that I've had, feel free to destroy at will :)
- Live Effects need to work with opening and saving a file, so they need
to be stored somewhere. I was thinking we could add a
"<inkscape:live-effect>" node in the defs section to define each live
effect and read them when the file is opened.
- Live Effects should be triggered when the original objects are edited,
so we need to mark who those are. Probably by node ID.
- If one of those nodes is deleted in the process of running the effect,
then it should be stored in the live-effect node so that when re-running
the effect it can be placed back on the canvas temporarily.
- We need to keep track of the objects that are created by the effect,
so we can delete them before rerunning the effect. I think this could
also be accomplished through a node ID.
- If any of the objects created by the live-effect are modified (ie
moved) the live-effect is broken. I'm not sure if there should be some
warning, or atleast a status bar message for this. I think it is simply
to difficult to track the changes.
- We need a way for the effects themselves to mark which nodes they
created or deleted in their execution. I'm thinking that we can just
add a inkscape namespace attribute for the nodes. When we reparse the
file, we'll look for those. Then, in the inx file, we can mark whether
an effect is "live effects aware" to keep the basic case simple. We may
be able to accomplish this through comparing the before and after
documents, but that seems likely to cause error (perhaps Mental has some
ideas on this?)
- I think that live effects should work for output and input extensions
too. That way you could have an SVG document that you're working on
constantly update the Postscript output copy that you want to have. Of
course, this might be slow, but people will find it useful when they
have 64-core computers :)
- To make the performance reasonable, I think that we'll need to keep
parsed copies of the scripts cached. I think I know how to do this with
the python libraries. There is already the load/unload mechanism in the
extensions to facilitate this. After I finish the extensions dialog,
I'll start working on this. (unless someone really knows how to do it,
I'd be happy to let someone who knows what they're doing go ahead :)
Those are the things that I can think of right now. Comments and ideas
are welcome!
--Ted
17 years, 8 months
NEW: better statusbar tips for multiple objects in selection
by bulia byak
For multiple selected objects, the statusbar now reports their types.
For example, if 5 groups are selected, it displays
5 objects of type Group in layer LayerName.
instead of just "5 objects selected" as before. If there are up to 3
types in the selection, they will be listed, for example:
5 objects of types Group, Path, Rectangle in layer LayerName.
The order of the list will correspond to the order in which the
objects were added to selection. If there are 4 or more types in
selection, only the number of types is reported, for example:
5 objects of 4 types in layer LayerName.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
17 years, 8 months
