headers
Danny Robson | 4 Apr 2010 04:24
Gravatar

gsoc2010: a collection of filters for GEGL

Hi all,

I am a PhD candidate at the Australian National University, currently
creating and evaluating performance profiling tools for NUMA systems.
I have always had an interest in the realm of graphics, though I have
only managed minor patches for GEGL/BABL in the past.

As the deadline for gsoc2010 applications is far too rapidly
approaching, I was curious about thoughts on another alternative
proposal: implementing a collection or series of related filters.

I have a selection of ideas which I have briefly investigated, and may
be of interest:

1. While GEGL has excellent support for high depth colour spaces, there
are few examples of filters which take advantage of this explicitly. I
would be interested in implementing (or porting) a collection of tone
mapping operators as native GEGL filters.

2. Image matting techniques with trimaps, such as the closed form of
Levin et. al., have very interesting applications for end users. I
would be interested in implementing one such technique and further
filters applying it (such as haze removal and spatially varying white
balance).

3. The matting of #2 could segue nicely into an implementation of image
completion/inpainting (which is receiving more public exposure due to
similar techniques in the upcoming Adobe CS5). 

I'm not quite clear on the level of complexity required for a gsoc
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Gowers | 4 Apr 2010 05:16
Picon

Re: gsoc2010: a collection of filters for GEGL

On Sun, Apr 4, 2010 at 11:54 AM, Danny Robson <danny@...> wrote:
> Hi all,
>
> I am a PhD candidate at the Australian National University, currently
> creating and evaluating performance profiling tools for NUMA systems.
> I have always had an interest in the realm of graphics, though I have
> only managed minor patches for GEGL/BABL in the past.
>
> As the deadline for gsoc2010 applications is far too rapidly
> approaching, I was curious about thoughts on another alternative
> proposal: implementing a collection or series of related filters.
>
> I have a selection of ideas which I have briefly investigated, and may
> be of interest:
>
> 1. While GEGL has excellent support for high depth colour spaces, there
> are few examples of filters which take advantage of this explicitly. I
> would be interested in implementing (or porting) a collection of tone
> mapping operators as native GEGL filters.
This leads me to wonder what kind of operation the GEGL 'tone-map' op
currently performs.

>
> 2. Image matting techniques with trimaps, such as the closed form of
> Levin et. al., have very interesting applications for end users. I
> would be interested in implementing one such technique and further
> filters applying it (such as haze removal and spatially varying white
> balance).
>
> 3. The matting of #2 could segue nicely into an implementation of image
(Continue reading)

Permalink | Reply | 3 comments |
headers
Danny Robson | 4 Apr 2010 05:58
Gravatar

Re: gsoc2010: a collection of filters for GEGL

On Sun, 4 Apr 2010 12:46:49 +0930
David Gowers <00ai99@...> wrote:

> > 1. While GEGL has excellent support for high depth colour spaces,
> > there are few examples of filters which take advantage of this
> > explicitly. I would be interested in implementing (or porting) a
> > collection of tone mapping operators as native GEGL filters.
> This leads me to wonder what kind of operation the GEGL 'tone-map' op
> currently performs.

Different operators produce different effects. It is often desirable to
select one which imparts a specific look to the end image. Having a
selection would be beneficial.

> >
> > 2. Image matting techniques with trimaps, such as the closed form of
> > Levin et. al., have very interesting applications for end users. I
> > would be interested in implementing one such technique and further
> > filters applying it (such as haze removal and spatially varying
> > white balance).
> >
> > 3. The matting of #2 could segue nicely into an implementation of
> > image completion/inpainting (which is receiving more public
> > exposure due to similar techniques in the upcoming Adobe CS5).
> 
> GMIC and Resynthesizer already do this.
> Perhaps they could do it faster or better.

Most likely they could do the completion/inpainting operations more
efficiently. However my interest is more in the matting operators, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Øyvind Kolås | 4 Apr 2010 06:33
Picon

Re: gsoc2010: a collection of filters for GEGL

On Sun, Apr 4, 2010 at 4:16 AM, David Gowers <00ai99@...> wrote:
>> 1. While GEGL has excellent support for high depth colour spaces, there
>> are few examples of filters which take advantage of this explicitly. I
>> would be interested in implementing (or porting) a collection of tone
>> mapping operators as native GEGL filters.
> This leads me to wonder what kind of operation the GEGL 'tone-map' op
> currently performs.

That op has been removed, I have some experimental (not commited to
git yet) code that revisits the ideas that originally were employed in
that op, another place where some of the concepts of this op is
manifested is in the gegl:stress op (which is stochastic and noisy for
low iterations/reasonable processing times.)

>> 3. The matting of #2 could segue nicely into an implementation of image
>> completion/inpainting (which is receiving more public exposure due to
>> similar techniques in the upcoming Adobe CS5).
>
> GMIC and Resynthesizer already do this.
> Perhaps they could do it faster or better.

GMIC and resynthesizer do some of these things with some approaches,
netiher of them do it as GEGL ops nor are they usable for GIMP or
other applications as GEGL operations. Thus from a purely GEGL based
view no such functionality is available.

/Øyvind K.
--

-- 
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Gowers | 4 Apr 2010 08:47
Picon

Re: gsoc2010: a collection of filters for GEGL

On Sun, Apr 4, 2010 at 2:03 PM, Øyvind Kolås <islewind@...> wrote:
> GMIC and resynthesizer do some of these things with some approaches,
> netiher of them do it as GEGL ops nor are they usable for GIMP or
> other applications as GEGL operations. Thus from a purely GEGL based
> view no such functionality is available.
>
> /Øyvind K.
Sorry, I misread the message headers and thought this was the GIMP list.
Permalink | Reply | 0 comments |
headers
Michael Schumacher | 9 Apr 2010 00:03
Picon
Picon
Gravatar

[GSoC] Reminder: 21 hours left for applying

See http://tinyurl.com/gsoc2010-student-deadline for the countdown

Apply at http://socghop.appspot.com/

Regards,
Michael

--

-- 
    GIMP > http://www.gimp.org      | IRC: irc://irc.gimp.org/gimp
    Wiki > http://wiki.gimp.org     | .de: http://gimpforum.de
Plug-ins > http://registry.gimp.org |
Permalink | Reply | 0 comments |
headers
hendrik | 9 Apr 2010 13:33

Re: [Inkscape-devel] Cairo rendering proposal

On Fri, Apr 09, 2010 at 03:52:03PM +0100, Øyvind Kolås wrote:
> 2010/4/8 Krzysztof Kosiński <tweenk.pl <at> gmail.com>:
> >> On 4/7/10, Krzysztof Kosiński wrote:
> >>> Here's my Cairo rendering proposal. I made it public so that all
> >>> people can comment.
> >>>
> 
> (linking to archived mail instead of full quoting original message)
> http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33871
> 
> To me this looks like a good approach for a cairo based renderer for
> inkscape, since I maintain GEGL which could possibly considered an
> alternative I'll post some thoughts on whether GEGLs rendering model
> could possibly fit into inkscape. (Note, until the last paragraph I
> list thing that are similar to what is needed, but at the moment
> probably would be a much worse option than what you have outlined).
> GEGL deals with many or most of the concerns of an interactive SVG
> canvas. And at least the long term it should be an eligible candidate
> for such SVG rendering (I've probably deleted an old naive SVG -> GEGL
> graph compiler I had lying around, as well as experiments with
> stroking SVG paths with soft brushes and variable line widths).
> 
> GEGL already does various caching of intermediate rendered surfaces
> and propagation of dirty rectangles in the compositing graph based on
> graph re-arrangements/property changes. Rendering is at the moment
> split into spatial regions that are processed sequentially (work is
> slowly under way to paralellize this processing of rectangular
> subregions with threads).

A few years ago, Henk Boom did a google summer-of-code project to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Øyvind Kolås | 9 Apr 2010 17:49
Picon

Re: [Inkscape-devel] Cairo rendering proposal

On Fri, Apr 9, 2010 at 12:33 PM,  <hendrik <at> topoi.pooq.com> wrote:
> On Fri, Apr 09, 2010 at 03:52:03PM +0100, Øyvind Kolås wrote:
>> 2010/4/8 Krzysztof Kosiński <tweenk.pl <at> gmail.com>:
>> >> On 4/7/10, Krzysztof Kosiński wrote:
>> >>> Here's my Cairo rendering proposal. I made it public so that all
>> >>> people can comment.
>>
>> (linking to archived mail instead of full quoting original message)
>> http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33871
>>
>> To me this looks like a good approach for a cairo based renderer for
>> inkscape, since I maintain GEGL which could possibly considered an
>> alternative I'll post some thoughts on whether GEGLs rendering model
>> could possibly fit into inkscape. (Note, until the last paragraph I
>> list thing that are similar to what is needed, but at the moment
>> probably would be a much worse option than what you have outlined).
>> GEGL deals with many or most of the concerns of an interactive SVG
>> canvas. And at least the long term it should be an eligible candidate
>> for such SVG rendering (I've probably deleted an old naive SVG -> GEGL
>> graph compiler I had lying around, as well as experiments with
>> stroking SVG paths with soft brushes and variable line widths).
>>
>> GEGL already does various caching of intermediate rendered surfaces
>> and propagation of dirty rectangles in the compositing graph based on
>> graph re-arrangements/property changes. Rendering is at the moment
>> split into spatial regions that are processed sequentially (work is
>> slowly under way to paralellize this processing of rectangular
>> subregions with threads).
>
> A few years ago, Henk Boom did a google summer-of-code project to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Schumacher | 13 Apr 2010 22:55
Picon
Picon
Gravatar

[GSoC] Mentors, rank the proposals

Hi,

multiple important deadlines for Google Summer of Code happen on April 21:

0700 UTC : all mentors have to be signed up and assigned to the
proposal(s) they want to handle

1700 UTC : ranking has to be finished

An IRC meeting to resolve any double accepts for students will follow
after that.

So it is important that you clearly mark your favorite proposals by
giving them a positive score.

Regards,
Michael

--

-- 
    GIMP > http://www.gimp.org      | IRC: irc://irc.gimp.org/gimp
    Wiki > http://wiki.gimp.org     | .de: http://gimpforum.de
Plug-ins > http://registry.gimp.org |
Permalink | Reply | 0 comments |
headers
Michael Schumacher | 13 Apr 2010 23:40
Picon
Picon
Gravatar

[GSoC] Mentor Request from GNOME Outreach Program for Women

Hi,

we've been approached on the #gimp channel by Marina Zhurakhinskaya from
the GNOME Outreach Program for Women. She has helped GSoC applicants
with their applications and is currently looking for a mentor for the
following project:

Abstract:

"Image editors overwrite originals of an image file with modified
versions, causing originals to be lost by default, or clutter up folders
with original and modified images. Some make copies of images and
organise them in a predefined unalterable manner (e.g. date taken). This
causes loss of originals and messy photo collections. The system being
proposed would allow the user to modify images in any folder, and allow
any modified image to be reverted back to its original unmodified version."

Full version (minus personal data of the student, of course):

http://www.fpaste.org/qLNt/raw/

If you are interested in commenting on or mentoring this application,
then please sign up as a mentor with the GNOME organization. But keep in
mind that ranking of the proposals is currently underway, so don't wait
too long:

http://socghop.appspot.com/gsoc/org/apply_mentor/google/gsoc2010

Regards,
Michael
(Continue reading)

Permalink | Reply | 3 comments |

Gmane