hi list,
is the [pix_freeframe] working only with .frf files? on the
freeframe.org site the majority of filters are there as .dll files.
anyone working with those freeframe plugins? the site looks a bit out
of date. is this a dead project?
thanks, m.
Hi Max,
I'm curious about this too.
On my debian machine, I installed the package: freeframe-petesvfx and
pd-pdp-freeframe which works nicely to control the plugins but I've
never worked with (or even knew about) pix_freeframe.
Best, p
On Aug 29, 2006, at 12:07 PM, Max Neupert wrote:
hi list,
is the [pix_freeframe] working only with .frf files? on the
freeframe.org site the majority of filters are there as .dll files.
anyone working with those freeframe plugins? the site looks a bit
out of date. is this a dead project?thanks, m.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On Aug 29, 2006, at 12:07 PM, Max Neupert wrote:
is the [pix_freeframe] working only with .frf files? on the
freeframe.org site the majority of filters are there as .dll files.
anyone working with those freeframe plugins? the site looks a bit
out of date. is this a dead project?
...not dead yet...as usual, a .dll file in this case is windows only,
and indeed most of the available plugins are compiled only for
windows...generally we have to wait for source releases to make a
linux or osx version...
...[pix_freeframe] does work on all 3 platforms (err, I haven't tried
windows), but currently the freeframe spec is undergoing a bit of
revision to make the api interface more "level" between all the
os's...basically, when freeframe 1.0 was released, it really hadn't
been ported to linux or osx: there is working code, but it is
similar to pre-1.0 specs that had been tried out...so it works, but...?
james
Zitat von james tittle tigital@mac.com:
...[pix_freeframe] does work on all 3 platforms (err, I haven't tried windows), but currently the freeframe spec is undergoing a bit of
but i did. [pix_freeframe] is tested to work on all 3 platforms.
Zitat von Paris Treantafeles paris@parisgraphics.com:
Hi Max,
I'm curious about this too.
On my debian machine, I installed the package: freeframe-petesvfx and
now i didn't know that pete's plugins have been packaged by debian. good news.
pd-pdp-freeframe which works nicely to control the plugins but I've
never worked with (or even knew about) pix_freeframe.
that's just like live is... [pix_freeframe] is approximately 4 months older than it's pdp sister (search the archives) however, there haven't been an official release of Gem since (our fault)
also note that there are different philosophies between the 2 objects (you cannot change the plugin loaded into [pix_freeframe], for good reasons(!); probably this will change a bit in the future)
since Gem's native colorspace is RGBA (except for osx), freeframe-effects (only RGB(A)) should perform better on Gem than on pdp (which is YUV), though i have never done any benchmarks.
mfga.sdr IOhannes
zmoelnig@iem.at a écrit :
now i didn't know that pete's plugins have been packaged by debian. good news.
Another good new, Pete's plugins dlls works on a windoz box.
p5.vert.ukl.yahoo.com uncompressed Tue Aug 29 18:27:02 GMT 2006
___________________________________________________________________________
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet !
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences.
http://fr.answers.yahoo.com
Zitat von Patco megalegoland@yahoo.fr:
zmoelnig@iem.at a écrit :
now i didn't know that pete's plugins have been packaged by debian. good news.
Another good new, Pete's plugins dlls works on a windoz box.
well, they also work on osx. pete's plugins are kind of reference implementation of freeframe effects.
mfg.asdr IOhannes
Am 29.08.2006 um 22:24 schrieb zmoelnig@iem.at:
Zitat von Patco megalegoland@yahoo.fr:
zmoelnig@iem.at a écrit :
now i didn't know that pete's plugins have been packaged by debian. good news.
Another good new, Pete's plugins dlls works on a windoz box.
well, they also work on osx. pete's plugins are kind of reference implementation of freeframe
effects.
i guess you got them there: www.troikatronix.com/freeframe.html
they work (at least the ones w/o spaces in the names) but they should
rather be called freezeframe because they lock my G4 pb 1.67 GHz
completely up.
m.
ola,
since Gem's native colorspace is RGBA (except for osx), freeframe-effects (only RGB(A)) should perform better on Gem than on pdp (which is YUV), though i have never done any benchmarks.
yes, but as RGB(A) is twice heavier than YUV, you don't prove anything with this remark, all depends of the patch.
saludos, sevy
On Wed, 30 Aug 2006, Yves Degoyon wrote:
Johannes wrote:
since Gem's native colorspace is RGBA (except for osx), freeframe-effects (only RGB(A)) should perform better on Gem than on pdp (which is YUV), though i have never done any benchmarks.
yes, but as RGB(A) is twice heavier than YUV, you don't prove anything with this remark, all depends of the patch.
I think that what Johannes wants to say, is that FreeFrame is RGBA, and that if the colorspace you are using is not RGBA, you will have to convert to RGBA and back to your colorspace, and that if there's not a RGBA image format, you won't be able to eliminate the unnecessary conversions between FreeFrame objects directly connected together.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Wed, 30 Aug 2006, Yves Degoyon wrote:
Johannes wrote:
since Gem's native colorspace is RGBA (except for osx), freeframe-effects (only RGB(A)) should perform better on Gem than on pdp (which is YUV), though i have never done any benchmarks.
yes, but as RGB(A) is twice heavier than YUV, you don't prove anything with this remark, all depends of the patch.
I think that what Johannes wants to say, is that FreeFrame is RGBA, and that if the colorspace you are using is not RGBA, you will have to convert to RGBA and back to your colorspace, and that if there's not a RGBA image format, you won't be able to eliminate the unnecessary conversions between FreeFrame objects directly connected together.
i perfectly know what he means, but as most quicktime movies are in YUV mode, and most cameras output YUV, you cannot avoid some kind of conversion somewhere.
ademas, there is a RGBA format in pdp, and pdp_xv doesn't need any conversion to output frames.
pues, piensalo,
ciao, sevy
Yves Degoyon wrote:
i perfectly know what he means, but as most quicktime movies are in YUV mode, and most cameras output YUV, you cannot avoid some kind of conversion somewhere.
ademas, there is a RGBA format in pdp,
this is good to know (if you know what "ademas" means)
and pdp_xv doesn't need any conversion to output frames.
as you have said: it all depends on the patch.
i would also be interested in which context "RGBA" is twice as heavy as "YUV" (with respect to Gem/pdp)
fg.asd.r IOhannes
PS: "you don't prove anything with this remark" :-)
ola,
i would also be interested in which context "RGBA" is twice as heavy as "YUV" (with respect to Gem/pdp)
it's as simple as have shown dumb+dumber :
in RGBA format, a pixel is represented by 4x(data size) in YUV planar 4:2:2 format, it is represented by : 1Y + 1/4*U +1/4*V = 1,5*(data size )
of course, loops are much faster with YUV 4:2:2
i like the way people always argue here.
sevy
On 8/30/06, Yves Degoyon ydegoyon@free.fr wrote:
ola,
i would also be interested in which context "RGBA" is twice as heavy as "YUV" (with respect to Gem/pdp)
it's as simple as have shown dumb+dumber :
in RGBA format, a pixel is represented by 4x(data size) in YUV planar 4:2:2 format, it is represented by : 1Y + 1/4*U +1/4*V = 1,5*(data size )
Technically that is 4:2:0. ;)
4:2:2 would be represent as 1Y + 1/2U + 1/2V in your notation. That is 16 bits per pixel or two in the 32bit space required for RGBA.
of course, loops are much faster with YUV 4:2:2
Just about everything related to video is faster with YUV processing. That's why both PDP and GEM have full YUV chains right?
cgc
Yves Degoyon wrote:
ola,
hi
i would also be interested in which context "RGBA" is twice as heavy as "YUV" (with respect to Gem/pdp)
it's as simple as have shown dumb+dumber :
thanks for the compliment.
in RGBA format, a pixel is represented by 4x(data size) in YUV planar 4:2:2 format, it is represented by : 1Y + 1/4*U +1/4*V = 1,5*(data size )
of course, loops are much faster with YUV 4:2:2
actually my point was about "datasize" in Gem and pdp. in Gem's RGBA format, each pixel is represented by 4 bytes (datasize=1byte)
i always thought, pdp uses short as datatype, which gives you far better resolution. otoh, this means that you need 6 bytes per pixel (datasize=2bytes)
of course loops are much faster with less data.
i like the way people always argue here.
me too. please note that i don't say that pdp is bad or worse than Gem or something. but most likely i don't prove anything with this remark.
mfg.adsr IOhannes
ola,
in RGBA format, a pixel is represented by 4x(data size) in YUV planar 4:2:2 format, it is represented by : 1Y + 1/4*U +1/4*V = 1,5*(data size )
of course, loops are much faster with YUV 4:2:2
actually my point was about "datasize" in Gem and pdp. in Gem's RGBA format, each pixel is represented by 4 bytes (datasize=1byte)
i always thought, pdp uses short as datatype, which gives you far better resolution. otoh, this means that you need 6 bytes per pixel (datasize=2bytes)
err, 1,5*datasize = 1,5*2 is not really 6, mas bien 3. but the point is not this ( not the size of the data ), but how many data you process in a loop, actually more than 2 times less.
and, cgc was right, the real name of the format used in pdp is YUV 4:2:0, sorry, i'm a bit far from video these days.
tschuss, sevy
Yves Degoyon wrote:
ola,
i always thought, pdp uses short as datatype, which gives you far better resolution. otoh, this means that you need 6 bytes per pixel (datasize=2bytes)
err, 1,5*datasize = 1,5*2 is not really 6, mas bien 3.
oops, sorry; my math is getting rusty...
of course you are right that one pdp-pixel is still less than one Gem RGBA pixel.
but the point is not this ( not the size of the data ), but how many data you process in a loop,
do i read this correctly as: how many data is processed in the entire loop (e.g. the size of the image)? that's what i meant with "loops are much faster with less data"; i haven't said that loops are faster when you process bytes instead of shorts.
actually more than 2 times less.
now again my math strikes me. if one pixel takes 3 bytes in pdp and 4 bytes in Gem, then an image of 100x100 pixels has 30000 bytes in pdp and 40000 bytes in Gem. so its 25% less data and not 50% (however, with a better resolution)
mfg.asdr IOhannes
I kind of get the feeling this thread is in need of some
clarification regarding RGB, YUV, 4-1-1, 4-2-0, 4-2-2 and 4-4-4. I'll
threat you all as idiots and try to explain it from scratch.
A digital image is built up by pixels.
If the picture is in gray-scale you only need one number to define
the tone of each pixel. The defining number is somewhere in a
predefined range, the greater the range the more possible tones. If
the range is only 0 and 1 you can define only black and white. If the
range consists of more than about 200 possible variations you can
define a seemingly unbroken grayscale between black and white (8 bits
equals 256 variations). If you need to make vast manipulations of the
tones of your pixels you might need an even greater range of possible
tones in your original pixels (that's why there is such things as 16
bit and 32 bit grayscale images).
In a RGB-format image the color is defined by 3 grayscale channels
(that is three separate grayscale images really), one for red, one
for green and one for blue. It is also possible to ad other channels
to an image, such as alpha-channels for transparency or z-channels
for depth or any other channel you find useful. Every pixel in your
image could be defined by 1, 3, 4, 5 or even more channels, each
consisting of 1, 2, 4, 8, 10, 16, or 32 bits.
YUV also contains 3 channels, but the luminance (brightness)
information (Y) of the image is separated from the color information
(u and v). The human brain is much less sensitive for changes in
color than for changes in luminance. Therefore if the color
information is separated from the luminance you can save space by
removing some of the information in the color-channels while
retaining approximately the.
Sorry about the double-post, wrong key sequence.
I kind of get the feeling this thread is in need of some
clarification regarding RGB, YUV, 4-1-1, 4-2-0, 4-2-2 and 4-4-4. I'll
threat you all as idiots and try to explain it from scratch.
A digital image is built up by pixels.
If the picture is in gray-scale you only need one number to define
the tone of each pixel. The defining number is somewhere in a
predefined range, the greater the range the more possible tones. If
the range is only 0 and 1 you can define only black and white. If the
range consists of more than about 200 possible variations you can
define a seemingly unbroken grayscale between black and white (8 bits
equals 256 variations). If you need to make vast manipulations of the
tones of your pixels you might need an even greater range of possible
tones in your original pixels (that's why there is such things as 16
bit and 32 bit grayscale images).
In a RGB-format image the color is defined by 3 grayscale channels
(that is three separate grayscale images really), one for red, one
for green and one for blue. It is also possible to ad other channels
to an image, such as alpha-channels for transparency or z-channels
for depth or any other channel you find useful. Every pixel in your
image could be defined by 1, 3, 4, 5 or even more channels, each
consisting of 1, 2, 4, 8, 10, 16, or 32 bits.
YUV also contains 3 channels, but the luminance (brightness)
information (Y) of the image is separated from the color information
(u and v). The human brain is much less sensitive for changes in
color than for changes in luminance. Therefore if the color
information is separated from the luminance you can save space by
removing some of the information in the color-channels while
retaining approximately the same visual qualities. 4-1-1 means you
have only one pixel in every color channel per pixel in the luminance-
channel (4-2-0 is a variant where the color-pixels alternate between
u and v every frame (or field?), the compression is the same). 4-2-2
means 1 color-channel pixel per 2 luminance pixels. In this respect
RGB is actually always 4-4-4.
4-2-2 or 4-1-1 reduces space in a great way, but if you need to make
manipulations that moves information from color to luminance the
method might be a rather bad idéa. Worse even, if you need to use
color-information for creating an alpha-channel (blue-screen/green-
screen f.ex.) you might experience serious loss of quality.
regards, Pär
ola,
4-2-2 or 4-1-1 reduces space in a great way, but if you need to make
manipulations that moves information from color to luminance the
method might be a rather bad idéa. Worse even, if you need to use
color-information for creating an alpha-channel (blue-screen/green- screen f.ex.) you might experience serious loss of quality.
sick of quality maniacs and of professors, hey man, we knew what you taught us.
ask yourself why many people work in YUV ( and i'm not defending it, i don't care )
sevy
ola,
4-2-2 or 4-1-1 reduces space in a great way, but if you need to
make manipulations that moves information from color to luminance
the method might be a rather bad idéa. Worse even, if you need to
use color-information for creating an alpha-channel (blue-screen/ green- screen f.ex.) you might experience serious loss of quality.sick of quality maniacs and of professors, hey man, we knew what you taught us.
I'm new to this community but I'm sure most of you did know this,
though I'm not really sure everyone involved did, and thought some
clarification might bring the discussion up to a more constructive
level. Sorry if I insulted you in some way by doing this. I'm
seriously not a quality maniac but there are always decisions to make
or ignore and as you so wisely remarked earlier: "it all depends on
the patch". In some cases it's just good to have the information.
ask yourself why many people work in YUV ( and i'm not defending it, i don't care )
I think I did rather well explain why people use YUV and 4-2-2 don't
you think? I don't want to take sides in this discussion, as the
truth is in "it all depends". Though I would agree (of course), in
most cases 4-2-2 or 4-2-0 is far more than good enough.
In the end just use what works, simple as that. OK?
.p
ok, sorry,
that was harsh for your 1st message on the list ( but that's a harsh list ), it's always full of 'my stuff is better, blah, blah. blah, ...'
YUV is just a compromise between quality and real-time processing ( that's a concern in pd )
sorry again, sevy
pär F wrote:
ola,
4-2-2 or 4-1-1 reduces space in a great way, but if you need to
make manipulations that moves information from color to luminance
the method might be a rather bad idéa. Worse even, if you need to
use color-information for creating an alpha-channel (blue-screen/ green- screen f.ex.) you might experience serious loss of quality.sick of quality maniacs and of professors, hey man, we knew what you taught us.
I'm new to this community but I'm sure most of you did know this,
though I'm not really sure everyone involved did, and thought some
clarification might bring the discussion up to a more constructive
level. Sorry if I insulted you in some way by doing this. I'm
seriously not a quality maniac but there are always decisions to make
or ignore and as you so wisely remarked earlier: "it all depends on
the patch". In some cases it's just good to have the information.ask yourself why many people work in YUV ( and i'm not defending it, i don't care )
I think I did rather well explain why people use YUV and 4-2-2 don't
you think? I don't want to take sides in this discussion, as the
truth is in "it all depends". Though I would agree (of course), in
most cases 4-2-2 or 4-2-0 is far more than good enough.In the end just use what works, simple as that. OK?
.p _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey,
I've only been doing VJ stuff for this year, and I had no idea about the technical and memory-size differences between RGB and YUV. so "par F" - please know that your post was VERY helpful. I use alpha channels a lot too, and I might try and create a DVD to demo my work, so some of us really need to know the types of trade offs involved. It is NOT just academic, it lets me know some things to experiment with and see what results it gives me and whether it looks satisfactory.
Btw, I'm doing live visuals for a show with UNDERGROUND RESISTANCE from Detroit - I'm really excited because UR records were my first influences when I was getting into techno. I'll be using PD and GEM to full effect. This is my first show in a big club -- well, I hate clubs, but I'm happy to do a show with Underground Resistance, and hopefully I can sneak in some revolutionary propaganda into my show...
~David
On 8/30/06, Yves Degoyon ydegoyon@free.fr wrote:
ok, sorry,
that was harsh for your 1st message on the list ( but that's a harsh list ), it's always full of 'my stuff is better, blah, blah. blah, ...'
YUV is just a compromise between quality and real-time processing ( that's a concern in pd )
sorry again, sevy
pär F wrote:
ola,
4-2-2 or 4-1-1 reduces space in a great way, but if you need to make manipulations that moves information from color to luminance the method might be a rather bad idéa. Worse even, if you need to use color-information for creating an alpha-channel (blue-screen/ green- screen f.ex.) you might experience serious loss of quality.
sick of quality maniacs and of professors, hey man, we knew what you taught us.
I'm new to this community but I'm sure most of you did know this, though I'm not really sure everyone involved did, and thought some clarification might bring the discussion up to a more constructive level. Sorry if I insulted you in some way by doing this. I'm seriously not a quality maniac but there are always decisions to make or ignore and as you so wisely remarked earlier: "it all depends on the patch". In some cases it's just good to have the information.
ask yourself why many people work in YUV ( and i'm not defending it, i don't care )
I think I did rather well explain why people use YUV and 4-2-2 don't you think? I don't want to take sides in this discussion, as the truth is in "it all depends". Though I would agree (of course), in most cases 4-2-2 or 4-2-0 is far more than good enough.
In the end just use what works, simple as that. OK?
.p _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, David Powers hat gesagt: // David Powers wrote:
Btw, I'm doing live visuals for a show with UNDERGROUND RESISTANCE from Detroit - I'm really excited because UR records were my first influences when I was getting into techno. I'll be using PD and GEM to full effect. This is my first show in a big club -- well, I hate clubs, but I'm happy to do a show with Underground Resistance, and hopefully I can sneak in some revolutionary propaganda into my show...
Wow, congratulations! I'm not listening to much UR today, but I was doing so *a lot* some years ago. (1990++, I must be getting old...)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I'm not following this thread but nice explanation. So YUV in anything other than 4 4 4 is basically "compressed video" ?
On Wed, 30 Aug 2006 19:44:25 +0200 pär F p.friden@gmail.com wrote:
Sorry about the double-post, wrong key sequence.
I kind of get the feeling this thread is in need of some
clarification regarding RGB, YUV, 4-1-1, 4-2-0, 4-2-2 and 4-4-4. I'll
threat you all as idiots and try to explain it from scratch.A digital image is built up by pixels.
If the picture is in gray-scale you only need one number to define
the tone of each pixel. The defining number is somewhere in a
predefined range, the greater the range the more possible tones. If
the range is only 0 and 1 you can define only black and white. If the
range consists of more than about 200 possible variations you can
define a seemingly unbroken grayscale between black and white (8 bits
equals 256 variations). If you need to make vast manipulations of the
tones of your pixels you might need an even greater range of possible
tones in your original pixels (that's why there is such things as 16
bit and 32 bit grayscale images).In a RGB-format image the color is defined by 3 grayscale channels
(that is three separate grayscale images really), one for red, one
for green and one for blue. It is also possible to ad other channels
to an image, such as alpha-channels for transparency or z-channels
for depth or any other channel you find useful. Every pixel in your
image could be defined by 1, 3, 4, 5 or even more channels, each
consisting of 1, 2, 4, 8, 10, 16, or 32 bits.YUV also contains 3 channels, but the luminance (brightness)
information (Y) of the image is separated from the color information
(u and v). The human brain is much less sensitive for changes in
color than for changes in luminance. Therefore if the color
information is separated from the luminance you can save space by
removing some of the information in the color-channels while
retaining approximately the same visual qualities. 4-1-1 means you
have only one pixel in every color channel per pixel in the luminance- channel (4-2-0 is a variant where the color-pixels alternate between
u and v every frame (or field?), the compression is the same). 4-2-2
means 1 color-channel pixel per 2 luminance pixels. In this respect
RGB is actually always 4-4-4.4-2-2 or 4-1-1 reduces space in a great way, but if you need to make
manipulations that moves information from color to luminance the
method might be a rather bad idéa. Worse even, if you need to use
color-information for creating an alpha-channel (blue-screen/green- screen f.ex.) you might experience serious loss of quality.regards, Pär _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 8/31/06, padawan12 padawan12@obiwannabe.co.uk wrote:
I'm not following this thread but nice explanation. So YUV in anything other than 4 4 4 is basically "compressed video" ?
Depends on how crazy you want to be with semantics. There is no distribution video format other than subsampled YUV. Typically 4:2:2 without datarate decimation is called uncompressed video. Some television studiom equipment is RGB but anything coming in from the field or going out for broadcast is YUV.
Broadcast video is actually removing information per sample as it moves forward. NTSC and PAL were 4:2:2 uncompressed while ATSC (US HDTV) uses 4:2:0 with fairly lossy MPEG2.
YUV is a method for defining colors. 4-2-2 and 4-1-1 are ways of
reducing the file size of an image that are possible only in an YUV
space (not quite true, but at least not possible in RGB). YUV is in
reality mainly used for video.
I'm not following this thread but nice explanation. So YUV in anything other than 4 4 4 is basically "compressed video" ?
Pär
YUV predates computer graphics by several years. It was developed to add color to NTSC broadcasts without losing monochrome compatibility and also to fit within the already mandated TV broadcast bandwidth.
On 8/30/06, pär F p.friden@gmail.com wrote:
YUV is a method for defining colors. 4-2-2 and 4-1-1 are ways of reducing the file size of an image that are possible only in an YUV space (not quite true, but at least not possible in RGB). YUV is in reality mainly used for video.
I'm not following this thread but nice explanation. So YUV in anything other than 4 4 4 is basically "compressed video" ?
Pär _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 30 Aug 2006, pär F wrote:
YUV is a method for defining colors. 4-2-2 and 4-1-1 are ways of reducing the file size of an image that are possible only in an YUV space (not quite true, but at least not possible in RGB). YUV is in reality mainly used for video.
It's "possible" in RGB, it just doesn't give pretty results on average, which is one reason why those kinds of downsampling are done in YUV, and why JPEG compression is done in YUV, etc.
(The real original reason for YUV is that it was backwards-compatible with greyscale TV, but we can safely ignore that fact because YUV is nice for its own reasons)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, 31 Aug 2006, padawan12 wrote:
I'm not following this thread but nice explanation. So YUV in anything other than 4 4 4 is basically "compressed video" ?
Depends on who you ask, what's the meaning of "compression"... it's certainly "subsampled", as in, when people say DV is 720x480, that's not what it is for real, only the Y channel is like that, and the UV channels are in 360x480.
basically "444" is uncompressed, "422" has the UV in half-width, "411" has the UV in quarter-width, and "420" has the UV in both half-width and half-height.
if you're in 8 bits per value, then "444" is 24 bpp, "422" is 16 bpp, and the others are 12 bpp, but those "bits per pixel" are assuming a "pixel" is defined only in terms of the Y channel. If you do it only in terms of UV channels, then everything is reversed, as "444" is 24 bpp, "422" is 32 bpp, and the others are 48 bpp.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 9/1/06, Mathieu Bouchard matju@artengine.ca wrote:
if you're in 8 bits per value, then "444" is 24 bpp, "422" is 16 bpp, and the others are 12 bpp, but those "bits per pixel" are assuming a "pixel" is defined only in terms of the Y channel. If you do it only in terms of UV channels, then everything is reversed, as "444" is 24 bpp, "422" is 32 bpp, and the others are 48 bpp.
It is important to state that all of the pixels are 24 bit in every YCbCr system. Each pixel can have a unique value even with the shared CbCr.
On 9/1/06, chris clepper cgclepper@gmail.com wrote:
On 9/1/06, Mathieu Bouchard matju@artengine.ca wrote:
if you're in 8 bits per value, then "444" is 24 bpp, "422" is 16 bpp, and the others are 12 bpp, but those "bits per pixel" are assuming a "pixel" is defined only in terms of the Y channel. If you do it only in terms of UV channels, then everything is reversed, as "444" is 24 bpp, "422" is 32 bpp, and the others are 48 bpp.
It is important to state that all of the pixels are 24 bit in every YCbCr system. Each pixel can have a unique value even with the shared CbCr.
And to finish the thought before hitting send: each pixel has a discrete 24 bits of information in YCbCr system. The subsampling means that pixels share some of the chroma (Cb and Cr) values and not that some pixels lack those color values.
On Fri, 1 Sep 2006, chris clepper wrote:
On 9/1/06, chris clepper cgclepper@gmail.com wrote:
On 9/1/06, Mathieu Bouchard matju@artengine.ca wrote:
if you're in 8 bits per value, then "444" is 24 bpp, "422" is 16 bpp, and the others are 12 bpp, but those "bits per pixel" are assuming a "pixel" is defined only in terms of the Y channel. If you do it only in terms of UV channels, then everything is reversed, as "444" is 24 bpp, "422" is 32 bpp, and the others are 48 bpp.
It is important to state that all of the pixels are 24 bit in every YCbCr system. Each pixel can have a unique value even with the shared CbCr.
Well, I hope so!
If it didn't have a value of its own, it wouldn't be a pixel.
each pixel has a discrete 24 bits of information in YCbCr system. The subsampling means that pixels share some of the chroma (Cb and Cr) values and not that some pixels lack those color values.
Why is it important to make that distinction? There's no point in saying that pixels share chromas vs that pixels lack chromas. It depends on how you think of the pixel (e.g. is a pixel a point or is it a square?). To complicate matters, in practice, various types of interpolation are used, which leads the concepts of "sharing" and "lacking" to be a lot blurrier (pun intended).
BTW, congrats for the first mention of YCbCr in this thread. For anyone who doesn't know, Cb = blue chroma, Cr = red chroma, and those are synonymous with U and V, and also with B-Y and R-Y. Some people insist on distinguishing YCbCr, YUV and Y(B-Y)(R-Y) to mean slightly different things and may also use apostrophes and stuff, but in the current situation, one can't really expect a consistent notation from person to person.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 9/7/06, Mathieu Bouchard matju@artengine.ca wrote
BTW, congrats for the first mention of YCbCr in this thread. For anyone who doesn't know, Cb = blue chroma, Cr = red chroma, and those are synonymous with U and V, and also with B-Y and R-Y. Some people insist on distinguishing YCbCr, YUV and Y(B-Y)(R-Y) to mean slightly different things and may also use apostrophes and stuff, but in the current situation, one can't really expect a consistent notation from person to person.
YCbCr is the terminology in CCIR 601 and ITU-R 709 and other digital standards. YUV and YIQ are part of the original PAL and NTSC analog systems which is where confusion can come in - particularly with 601 since it converts from YUV/YIQ analog into YCbCr.
http://www.poynton.com/papers/YUV_and_luminance_harmful.html
On Wed, 30 Aug 2006, IOhannes m zmoelnig wrote:
now again my math strikes me. if one pixel takes 3 bytes in pdp and 4 bytes in Gem, then an image of 100x100 pixels has 30000 bytes in pdp and 40000 bytes in Gem. so its 25% less data and not 50% (however, with a better resolution)
Btw, didn't I hear Tom say that the YUV mode is using signed 16-bit instead of unsigned 8-bit values? Or is that just an option?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Wed, 30 Aug 2006, IOhannes m zmoelnig wrote:
now again my math strikes me. if one pixel takes 3 bytes in pdp and 4 bytes in Gem, then an image of 100x100 pixels has 30000 bytes in pdp and 40000 bytes in Gem. so its 25% less data and not 50% (however, with a better resolution)
Btw, didn't I hear Tom say that the YUV mode is using signed 16-bit instead of unsigned 8-bit values? Or is that just an option?
well, this was my point; that's why i am talking about 2byte datasize.
if pdp is using yuv420, then the above calculation is valid. if pdp is using yuv422, then pdp and Gem have the same imagesize.
i _think_ that signed short YUV is the "native" cs of pdp, though it can handle other cs's too.
mfg.asdr IOhannes
On Sun, 3 Sep 2006, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Wed, 30 Aug 2006, IOhannes m zmoelnig wrote:
if one pixel takes 3 bytes in pdp and 4 bytes in Gem, then an image of 100x100 pixels has 30000 bytes in pdp and 40000 bytes in Gem. so its 25% less data and not 50% (however, with a better resolution)
Btw, didn't I hear Tom say that the YUV mode is using signed 16-bit instead of unsigned 8-bit values? Or is that just an option?
well, this was my point; that's why i am talking about 2byte datasize.
d'oh! sorry, transient brain failure... =)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
I'm on PD-extended-0.39.2-test2, WinXP. (Most recent version, test4 for WinXP just crashes, and I believe for test3 GEM doesn't work... ).
I can't for the life of me get [pix_freeframe] to load a plugin. I put all the DLL's in my pd/extra folder.
I changed PD "path" settings, deleting the path for System fonts, and replacing this with the pd/extra, thinking that, based on the freeframe helpfile, pd should look for the freeframe plugins, in all the directories inside the path. But, it doesn't work.
Am I doing something wrong?
~David
On 8/29/06, james tittle tigital@mac.com wrote:
On Aug 29, 2006, at 12:07 PM, Max Neupert wrote:
is the [pix_freeframe] working only with .frf files? on the freeframe.org site the majority of filters are there as .dll files. anyone working with those freeframe plugins? the site looks a bit out of date. is this a dead project?
...not dead yet...as usual, a .dll file in this case is windows only, and indeed most of the available plugins are compiled only for windows...generally we have to wait for source releases to make a linux or osx version...
...[pix_freeframe] does work on all 3 platforms (err, I haven't tried windows), but currently the freeframe spec is undergoing a bit of revision to make the api interface more "level" between all the os's...basically, when freeframe 1.0 was released, it really hadn't been ported to linux or osx: there is working code, but it is similar to pre-1.0 specs that had been tried out...so it works, but...?
james
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello
David Powers a écrit :
I'm on PD-extended-0.39.2-test2, WinXP. (Most recent version, test4 for WinXP just crashes, and I believe for test3 GEM doesn't work... ).
I can't for the life of me get [pix_freeframe] to load a plugin. I put all the DLL's in my pd/extra folder.
I changed PD "path" settings, deleting the path for System fonts, and replacing this with the pd/extra, thinking that, based on the freeframe helpfile, pd should look for the freeframe plugins, in all the directories inside the path. But, it doesn't work.
Am I doing something wrong?
~David
I put a folder called freeframe in extra path and load freeframe object like that:
[pix_freeframe freeframe/Syz_DelayStrips] and in console all parameters of the plugins appears:
trying to load c:/pd39/extra/freeframe/Syz_DelayStrips.dll plugin @ CB71E30 pix_freeframe[freeframe/Syz_DelayStrips]: param#0: Strips param#1: Right To Left? param#2: Take Center? param#3: Bars?
Patco.
___________________________________________________________________________ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com
Hi, This is SO weird, I just don't get it. Here's what I tried:
- If I try to open a new pix_freeframe, nothing happens. I get:
pix_freeframe freeframe/Slice ... couldn't create
- If I open the "pix_freeframe" help file, this is what happens:
pix_film:: avi support pix_film:: quicktime support error: pix_freeframe: can't load abstraction within itself
pix_freeframe WaveVFX ... couldn't create pix_freeframe.pd 31 0 43 0 (pix_filmNEW->canvas) connection failed pix_freeframe.pd 41 0 43 1 (gatom->canvas) connection failed pix_freeframe.pd 43 0 30 0 (canvas->pix_texture) connection failed error: pix_freeframe: can't load abstraction within itself
Okay, not surprising, because I don't have anything called "WaveVFX" ... BUT
- If I then try to modify the help file, so that instead of WaveVFX
it's trying [pix_freeframe freeframe/Slice] I STILL get:
pix_freeframe WaveVFX ... couldn't create
But I'm not even trying to create "WaveVFX" any more!
Every time I get excited about something on PD, it turns out not to work! ARGH!
~David
On 8/29/06, Patco megalegoland@yahoo.fr wrote:
Hello
David Powers a écrit :
I'm on PD-extended-0.39.2-test2, WinXP. (Most recent version, test4 for WinXP just crashes, and I believe for test3 GEM doesn't work... ).
I can't for the life of me get [pix_freeframe] to load a plugin. I put all the DLL's in my pd/extra folder.
I changed PD "path" settings, deleting the path for System fonts, and replacing this with the pd/extra, thinking that, based on the freeframe helpfile, pd should look for the freeframe plugins, in all the directories inside the path. But, it doesn't work.
Am I doing something wrong?
~David
I put a folder called freeframe in extra path and load freeframe object like that:
[pix_freeframe freeframe/Syz_DelayStrips] and in console all parameters of the plugins appears:
trying to load c:/pd39/extra/freeframe/Syz_DelayStrips.dll plugin @ CB71E30 pix_freeframe[freeframe/Syz_DelayStrips]: param#0: Strips param#1: Right To Left? param#2: Take Center? param#3: Bars?
Patco.
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com
David Powers a écrit :
Hi, This is SO weird, I just don't get it.
Hi, try with this attached one, some just don't work at all...
if it's okay, i've made an archive with all working dlls, it's here:
http://megalego.free.fr/pd/freeframe.zip
Patco.
Nope - still doesn't work. EXACTLY the same problems as before.
Gem version in this PD-extended is 0.90, maybe the problem is with Gem?
Unfortunately, I only have computers from work to use, so running Linux is not an option. My bosses would kill me if they turned on the computer and found a confusing Linux OS! (yes, I'm working on PD when I should be working ... not always though, I get to take my work laptop home and use it for other things.)
~David
On 8/29/06, Patco megalegoland@yahoo.fr wrote:
David Powers a écrit :
Hi, This is SO weird, I just don't get it.
Hi, try with this attached one, some just don't work at all...
if it's okay, i've made an archive with all working dlls, it's here:
http://megalego.free.fr/pd/freeframe.zip
Patco.
David Powers a écrit :
Nope - still doesn't work. EXACTLY the same problems as before.
Gem version in this PD-extended is 0.90, maybe the problem is with Gem?
Unfortunately, I only have computers from work to use, so running Linux is not an option. My bosses would kill me if they turned on the computer and found a confusing Linux OS! (yes, I'm working on PD when I should be working ... not always though, I get to take my work laptop home and use it for other things.)
Hmm, no need for installing linux (or you could try dyne which have gem, pidip and gridflow, and doesn't need hard drive install)
I usually take the externals dll from pd-extended and put them in the extra folder of a Miller's version which is installed at the root of my hardrive.
My Gem.dll version has been created the may 31 2006 and is about 2.32Mo I assume it comes from the last pd-extended version. I tested it on pd-0.39-2 and pd-0.40 (first version I guess) and it works like a charm:
trying to load C:/pd39/extra/freeframe/tantricFeedback.dll plugin @ 7FC1010 pix_freeframe[freeframe/tantricFeedback]: param#0: speed param#1: x centre param#2: y centre param#3: mix param#4: rotation param#5: colour cycling param#6: threshold
hmmm, I've just added with regedit a chain value called path12 and entered in it the path of my freeframe folder: c:/pd39/extra/freeframe now I can even use freeframe with pd-extended installed in Program Files.
Hope that helps.
___________________________________________________________________________ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com
Okay, well I will try Miller's PD with the extended DLL's like you suggest. Hopefully this will work, because I do have a newer version of Gem (not the one in PD-extended).
~David
On 8/29/06, Patco megalegoland@yahoo.fr wrote:
David Powers a écrit :
Nope - still doesn't work. EXACTLY the same problems as before.
Gem version in this PD-extended is 0.90, maybe the problem is with Gem?
Unfortunately, I only have computers from work to use, so running Linux is not an option. My bosses would kill me if they turned on the computer and found a confusing Linux OS! (yes, I'm working on PD when I should be working ... not always though, I get to take my work laptop home and use it for other things.)
Hmm, no need for installing linux (or you could try dyne which have gem, pidip and gridflow, and doesn't need hard drive install)
I usually take the externals dll from pd-extended and put them in the extra folder of a Miller's version which is installed at the root of my hardrive.
My Gem.dll version has been created the may 31 2006 and is about 2.32Mo I assume it comes from the last pd-extended version. I tested it on pd-0.39-2 and pd-0.40 (first version I guess) and it works like a charm:
trying to load C:/pd39/extra/freeframe/tantricFeedback.dll plugin @ 7FC1010 pix_freeframe[freeframe/tantricFeedback]: param#0: speed param#1: x centre param#2: y centre param#3: mix param#4: rotation param#5: colour cycling param#6: threshold
hmmm, I've just added with regedit a chain value called path12 and entered in it the path of my freeframe folder: c:/pd39/extra/freeframe now I can even use freeframe with pd-extended installed in Program Files.
Hope that helps.
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com
Okay, with Miller's PD and a new Gem I seem to have freeframe working ... but Patco, how did you get the extended libraries to load with Miller's PD, even when i try to add the path I get:
cyclone: can't load library zexy: can't load library creb: can't load library cxc: can't load library ext13: can't load library iemlib: can't load library iemmatrix: can't load library list-abs: can't load library
etc.............. Did you edit the registry?
On 8/29/06, Patco megalegoland@yahoo.fr wrote:
David Powers a écrit :
Hi, This is SO weird, I just don't get it.
Hi, try with this attached one, some just don't work at all...
if it's okay, i've made an archive with all working dlls, it's here:
http://megalego.free.fr/pd/freeframe.zip
Patco.
Tell me 'bout it!
~Kyle
On 8/31/06, Yves Degoyon ydegoyon@free.fr wrote:
ola,
etc.............. Did you edit the registry?
registry? big centralized system... nahnahnah
sevy
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
does it mean you have to _register_ to run a progam? and have your id ready and let your belongings on the tray?
oh sorry, i'm speaking of the world domination control again...
sevy
Kyle Klipowicz wrote:
Tell me 'bout it!
~Kyle
On 8/31/06, Yves Degoyon ydegoyon@free.fr wrote:
ola,
etc.............. Did you edit the registry?
registry? big centralized system... nahnahnah
sevy
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You have to edit the registry by hand, try using the example included with Pd-extended. Make sure to use the full pathnames.
~Kyle
On 8/31/06, David Powers cyborgk@gmail.com wrote:
Okay, with Miller's PD and a new Gem I seem to have freeframe working ... but Patco, how did you get the extended libraries to load with Miller's PD, even when i try to add the path I get:
cyclone: can't load library zexy: can't load library creb: can't load library cxc: can't load library ext13: can't load library iemlib: can't load library iemmatrix: can't load library list-abs: can't load library
etc.............. Did you edit the registry?
On 8/29/06, Patco megalegoland@yahoo.fr wrote:
David Powers a écrit :
Hi, This is SO weird, I just don't get it.
Hi, try with this attached one, some just don't work at all...
if it's okay, i've made an archive with all working dlls, it's here:
http://megalego.free.fr/pd/freeframe.zip
Patco.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, David Powers hat gesagt: // David Powers wrote:
Okay, with Miller's PD and a new Gem I seem to have freeframe working ... but Patco, how did you get the extended libraries to load with Miller's PD, even when i try to add the path I get:
list-abs: can't load library
Are you sure you're trying to "add the path" with "-path"? Because "can't load library" is an error which you get, when you change the startup libraries to load, and as list-abs is no library, you normally should never get this error because you normally never try to load it as a library (only maybe as a libdir).
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I don't know ... this is what happens running Miller's pd, after having Hans' pd-extended installed. Maybe someone can help explain in simple language whats going on.
I didn't exactly "change the startup libraries to load".
~David
On 9/1/06, Frank Barknecht fbar@footils.org wrote:
Hallo, David Powers hat gesagt: // David Powers wrote:
Okay, with Miller's PD and a new Gem I seem to have freeframe working ... but Patco, how did you get the extended libraries to load with Miller's PD, even when i try to add the path I get:
list-abs: can't load library
Are you sure you're trying to "add the path" with "-path"? Because "can't load library" is an error which you get, when you change the startup libraries to load, and as list-abs is no library, you normally should never get this error because you normally never try to load it as a library (only maybe as a libdir).
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hello,
David Powers a écrit :
Okay, with Miller's PD and a new Gem I seem to have freeframe working ...
Good
but Patco, how did you get the extended libraries to load with
Miller's PD,
There are several ways to get the extended libraries with windoz, you can make a batch file that starts pd with -lib and -path options (see .pdrc howto), also you can add -path and -lib in Startup... editor from File menu in PD main Graphic User Interface, but with this method you have to make fork libraries in Miller's PD extra folder.
even when i try to add the path I get:
cyclone: can't load library zexy: can't load library creb: can't load library cxc: can't load library ext13: can't load library iemlib: can't load library iemmatrix: can't load library list-abs: can't load library
etc.............. Did you edit the registry?
The other way is about using the registry like we were saying before in another recent topic.
pd-extended comes with a pd-settings.reg that you need to load into registry, it will add a bunch of pathes and libraries to the registry, but in the actually available .reg file, the path of the library is missing, then pd will look for folders in it's own extra folder, that's why you are getting these message with Miller's PD.
Go to registry (Start Menu --> execute --> regedit) and browse HKEY_LOCAL_MACHINE ---> SOFTWARE ---> pd, and then add the complete path of libraries in loadlibs, and the complete path of the abstraction folders (like list-abs), I assume it works when the complete path doesn't contain spaces in the name.
It's not a very good solution, but the only one, Pure Data really need an editor for that, that is not limited, something like Desire Data, or something in pd-extended installer that put the complete path of everything without having to edit the .reg file, and that automatically install it in registry, then we can use libraries with other pd versions than pd-extended.
___________________________________________________________________________ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com
Patco a écrit :
hello,
There are several ways to get the extended libraries with windoz, you can make a batch file that starts pd with -lib and -path options (see .pdrc howto), also you can add -path and -lib in Startup... editor from File menu in PD main Graphic User Interface, but with this method you have to make fork libraries in Miller's PD extra folder.
Also, if you put the complete path in 'Startup...' menu you don't have to make forks, still assuming that the path name doesn't contain spaces.
p4.vert.ukl.yahoo.com uncompressed Fri Sep 1 09:27:00 GMT 2006
___________________________________________________________________________
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet !
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences.
http://fr.answers.yahoo.com
Zitat von David Powers cyborgk@gmail.com:
I changed PD "path" settings, deleting the path for System fonts, and replacing this with the pd/extra, thinking that, based on the freeframe helpfile, pd should look for the freeframe plugins, in all the directories inside the path. But, it doesn't work.
i am pretty sure the search-path feature does work (it does so on linux and os-x, there is no reason to not work on w32). so put the font-path back into the registry, and remove the pd/extra path, since this is searched by pd anyhow (no need to add it double)
your problem is that you have a version of Gem that has no freeframe-support built into it. this explains the weird error messages you get: when you open the help-patch, the best you get is the help-patch trying to load an abstraction of the name "pix_freeframe"; the only one of this name is itself - so you get the "abstraction cannot load within itself" error; also when you change the object parameter to e.g. [pix_freeframe freeframe/Slice], you instantiate the help-patch with the [pix_freeframe WaveVFX] object inside (which refuses to create because of recursion), which explains why you think that it loads "WaveVFX" instead of "freeframe/Slice"
mf.asdr IOhannes
-
chris clepper -
David Powers -
Frank Barknecht -
IOhannes m zmoelnig -
james tittle -
Kyle Klipowicz -
Mathieu Bouchard -
Max Neupert -
padawan12 -
Paris Treantafeles -
Patco -
pär F -
Yves Degoyon -
zmoelnig＠iem.at