RSS/Atom feed Twitter
Site is read-only, email is disabled

Colorizing Images and Video by Scribbling

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

6 of 6 messages available
Toggle history

Please log in to manage your subscriptions.

Colorizing Images and Video by Scribbling Pepster 15 Mar 07:37
  Colorizing Images and Video by Scribbling Sven Neumann 15 Mar 21:45
   Colorizing Images and Video by Scribbling Pepster 15 Mar 22:03
    Colorizing Images and Video by Scribbling Tor Lillqvist 15 Mar 22:21
    Colorizing Images and Video by Scribbling Bill Kendrick 15 Mar 22:21
    Colorizing Images and Video by Scribbling Joao S. O. Bueno Calligaris 16 Mar 06:24
Pepster
2005-03-15 07:37:49 UTC (about 19 years ago)

Colorizing Images and Video by Scribbling

Slashdot has the "Story" about this - http://www.cs.huji.ac.il/~yweiss/Colorization/

I assume that to implement it one needs the color+timestamp for each drawn pixel. Is that at all possible to do in a gimp plugin?

-Joseph

Sven Neumann
2005-03-15 21:45:34 UTC (about 19 years ago)

Colorizing Images and Video by Scribbling

Hi,

Pepster writes:

Slashdot has the "Story" about this - http://www.cs.huji.ac.il/~yweiss/Colorization/

I assume that to implement it one needs the color+timestamp for each drawn pixel. Is that at all possible to do in a gimp plugin?

I don't see why this should not be possible to do in a plug-in. But I don't understand your comment about the timestamp.

Sven

Pepster
2005-03-15 22:03:15 UTC (about 19 years ago)

Colorizing Images and Video by Scribbling

Their page says
"Our method is based on a simple premise: neighboring pixels in space-time that have similar intensities should have similar colors"

I assume this to mean you need the "timing information of the stroke", similar to data needed for recognizing handwriting.

While I am not sure of the GTK low-level API for such a "capture", a plugin using such low level functions would have to re-implement the non trivial functionality of drawing the stroke (colors, brush, what-have-you ...), which is pointless.

I was asking if any of you see a better way to implement such a method in the gimp.

Hope I made myself clear this time.

-Joseph

Sven Neumann wrote:

Hi,

Pepster writes:

Slashdot has the "Story" about this - http://www.cs.huji.ac.il/~yweiss/Colorization/

I assume that to implement it one needs the color+timestamp for each drawn pixel. Is that at all possible to do in a gimp plugin?

I don't see why this should not be possible to do in a plug-in. But I don't understand your comment about the timestamp.

Sven

Tor Lillqvist
2005-03-15 22:21:13 UTC (about 19 years ago)

Colorizing Images and Video by Scribbling

Pepster writes:
> "Our method is based on a simple premise: neighboring pixels in > space-time that have similar intensities should have similar > colors"

> I assume this to mean you need the "timing information of the > stroke", similar to data needed for recognizing handwriting.

Nope, it refers to video. I.e. pixel neighbourhood not only in the (x,y) plane, but also in preceeding and succeeding video frames.

--tml

Bill Kendrick
2005-03-15 22:21:48 UTC (about 19 years ago)

Colorizing Images and Video by Scribbling

On Wed, Mar 16, 2005 at 10:03:15AM +1300, Pepster wrote:

Their page says
"Our method is based on a simple premise: neighboring pixels in space-time that have similar intensities should have similar colors"

I only skimmed the site a little last night, but I was under the impression that the 'time' aspect had to do only with colorizing videos. (Apparently the user can stroke every 10th frame, or so, and their software would figure out the colorization need on the in-between frames.)

I could've easily be mislead by my skimming, though. ;)

Joao S. O. Bueno Calligaris
2005-03-16 06:24:52 UTC (about 19 years ago)

Colorizing Images and Video by Scribbling

On Tuesday 15 March 2005 18:03, Pepster wrote:

Their page says
"Our method is based on a simple premise: neighboring pixels in space-time that have similar intensities should have similar colors"

I assume this to mean you need the "timing information of the stroke", similar to data needed for recognizing handwriting.

While I am not sure of the GTK low-level API for such a "capture", a plugin using such low level functions would have to re-implement the non trivial functionality of drawing the stroke (colors, brush, what-have-you ...), which is pointless.

Nope.
The "time" part of the "space time" proximity applies to animations (and movies, of course). For stativc drawings , it is all about spatial proximity.

I was asking if any of you see a better way to implement such a method in the gimp.

Hope I made myself clear this time.

-Joseph

Sven Neumann wrote: