hello,
i need some advise about a video processing lib i could use to
convert some c'74 jitter patches. basically, the patches need to be
running smooth on a medium speed computer, the libs should be free
and open source and running on both linux and mac (intel). the stuff
done in jitter is pretty basic and currently uses these objects:
jit.qt.movie streaming movie files off harddisc ; note that the
movies can be converted to any other movie format if necessary
jit.matrix storing frames
jit.window presenting movies
jit.scalebias modifying r / g / b dynamics
jit.op applying fadings
jit.alphablend superimposing png images with transparency
jit.rgb2hsl and jit.hsl2rgb animating de-saturation (to greyscale)
and back to colour
as far as know, when using PD, there are these possibilities:
GEM will allow me to play video files as openGL textures but not be
doing matrix-pixel stuff?
framestein windows only?
gridflow looks as if this has a concept similar to jitter? says mac
version is "experimental" ...
pdp also looks like jitter, but more macro objects instead of low
level when comparing to gridflow? says its linux + mac
also jitter already chokes with playing four small movies (cpu-
nonintensive codec!!) on a fast macbook, so i hope to also reduce the
"jitter" in the frame rate timing (images are only 12 fps but jitter
seems to be really bad in keeping proper timing). to me it looks if
either gridflow or pdp could be a good choice?
thanks for hints (also if there is something i could use outside pd,
i'm gratefull for infos)! ciao,
-sciss-
On 11/9/06, Sciss contact@sciss.de wrote:
Using GEM:
jit.qt.movie streaming movie files off harddisc ; note that the
pix_film
jit.matrix storing frames
pix_buffer
jit.window presenting movies
gemwin
jit.scalebias modifying r / g / b dynamics jit.op applying fadings
pix_gain, pix_offset, colorRGB, fragment_program
jit.alphablend superimposing png images with transparency
pix_image plus pix_texture will do this automatically if the image has a valid alpha channel
jit.rgb2hsl and jit.hsl2rgb animating de-saturation (to greyscale) and back to colour
pix_2grey, pix_contrast (same as pix_saturation),
also jitter already chokes with playing four small movies (cpu- nonintensive codec!!) on a fast macbook, so i hope to also reduce the "jitter" in the frame rate timing (images are only 12 fps but jitter seems to be really bad in keeping proper timing). to me it looks if either gridflow or pdp could be a good choice?
On OSX use the auo message with pix_film to have Quicktime take care of playback timings.
On Thu, 9 Nov 2006, Sciss wrote:
jit.qt.movie streaming movie files off harddisc ; note that the movies can be converted to any other movie format if necessary
[#in quicktime] or [#in mpeg]
jit.matrix storing frames
[#store]
jit.window presenting movies
[#out window]
jit.scalebias modifying r / g / b dynamics
this is a [# *] or a [# *>>8] and a [# +] at once.
jit.op applying fadings
[jit.op @op +] becomes just [# +]
jit.alphablend superimposing png images with transparency
[#draw_image] or [#layer]
jit.rgb2hsl and jit.hsl2rgb animating de-saturation (to greyscale) and back to colour
there's no hsl nor hsv in GridFlow; you can use [#saturation] and [#hueshift] to get similar effects.
GEM will allow me to play video files as openGL textures but not be doing matrix-pixel stuff?
GEM has several maintainers and compared to GridFlow, it has better support for solving usual problems without wasting processing power. (GridFlow was designed to solve unusual problems.)
framestein is for windows only?
Framestein has been unmaintained for many years.
gridflow looks as if this has a concept similar to jitter?
Yeah, GridFlow's grid are a purer version of Jitter's matrices. (GridFlow images have no planes and instead have an extra dimension representing the planes).
says mac version is "experimental" ...
And it's been like that for years. The version for OSX is slower and is missing some important features such as cameras. Also the interoperability with GEM can't work, due to a bug/limitation in Pd itself.
pdp also looks like jitter, but more macro objects instead of low level when comparing to gridflow? says its linux + mac
In PDP there is no concept similar to GridFlow's grids or Jitter's matrices. The message types are all separate from each other, so less reuse is possible. In some cases, the functionality of one GridFlow object class corresponds to two Jitter object classes, but to 3 or 4 or more GEM/PDP object classes.
seems to be really bad in keeping proper timing). to me it looks if either gridflow or pdp could be a good choice?
If you want speed, use PDP or GEM.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Thank you both, Chris and Matju for explaining these connections. This should go up on a Wiki (to pre-quote .hc)!
~Kyle
On 11/9/06, Mathieu Bouchard matju@artengine.ca wrote:
On Thu, 9 Nov 2006, Sciss wrote:
jit.qt.movie streaming movie files off harddisc
;
note that the movies can be converted to any other movie format if
necessary
[#in quicktime] or [#in mpeg]
jit.matrix storing frames
[#store]
jit.window presenting movies
[#out window]
jit.scalebias modifying r / g / b dynamics
this is a [# *] or a [# *>>8] and a [# +] at once.
jit.op applying fadings
[jit.op @op +] becomes just [# +]
jit.alphablend superimposing png images with
transparency
[#draw_image] or [#layer]
jit.rgb2hsl and jit.hsl2rgb animating de-saturation (to greyscale) and back to colour
there's no hsl nor hsv in GridFlow; you can use [#saturation] and [#hueshift] to get similar effects.
GEM will allow me to play video files as openGL textures but not be doing matrix-pixel stuff?
GEM has several maintainers and compared to GridFlow, it has better support for solving usual problems without wasting processing power. (GridFlow was designed to solve unusual problems.)
framestein is for windows only?
Framestein has been unmaintained for many years.
gridflow looks as if this has a concept similar to jitter?
Yeah, GridFlow's grid are a purer version of Jitter's matrices. (GridFlow images have no planes and instead have an extra dimension representing the planes).
says mac version is "experimental" ...
And it's been like that for years. The version for OSX is slower and is missing some important features such as cameras. Also the interoperability with GEM can't work, due to a bug/limitation in Pd itself.
pdp also looks like jitter, but more macro objects instead of low level when comparing to gridflow? says its linux + mac
In PDP there is no concept similar to GridFlow's grids or Jitter's matrices. The message types are all separate from each other, so less reuse is possible. In some cases, the functionality of one GridFlow object class corresponds to two Jitter object classes, but to 3 or 4 or more GEM/PDP object classes.
seems to be really bad in keeping proper timing). to me it looks if either gridflow or pdp could be a good choice?
If you want speed, use PDP or GEM.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
chris clepper -
Kyle Klipowicz -
Mathieu Bouchard -
Sciss