Re: [Mjpeg-users] Colorspace transform question
Hi Steven, > > In particular the 'pnmnlfilt' program sounds intriguing, it offers: > > 'Alpha trimmed mean filter', 'Optimal estimation smoothing' and > > 'Edge enhancement'. All the types of things we might want to do or > > at least try. Smoothing would be useful but edge enhancement will explode your bitrates. Lots of nasty sharp HF components introduced! cheers, Andrew --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Colorspace transform question
Hi - > From: Ronald Bultje <[EMAIL PROTECTED]> > > 4:2:2 10-bit? Where did he get that?!? Isn't that 16-bit? Intead of 8 bits per sample (which is what we use - 8 bits for Y' 8 bits for Cr and 8 for Cb) the professional folks use 10 bits for each of Y' Cr and Cb. > > Perhaps the more efficient method would be to grab copies of > > y4mtoppm and ppmtoy4m and find a way to merge in filters and create > > A bash-script should do... ;-). Pipes aren't that heavy, it's mostly > processes you save. You get flexibility, though. Up to a point that is true. When you get 7 or 8 processes connected though the constant traversal of the data to/from the kernel really does start to kill the performance - up to 5 or 6 it's not really noticeable but when I added a couple more I could see peformance really starting to fall off. The other benefit of the single program approach is that the header information (frame rate, field order, sample aspect, etc) could be maintained and passed thru without manually using command line arguments. Cheers, Steven Schultz --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Colorspace transform question
Hey Steven, On Fri, 2003-03-28 at 18:19, Steven M. Schultz wrote: > Very true. One of my brothers works at a TV station and mentioned > they use 10 bit 4:2:2 everywhere up till the final stage - some > really good looking pictures when he showed me around ;) 4:2:2 10-bit? Where did he get that?!? Isn't that 16-bit? > Perhaps the more efficient method would be to grab copies of > y4mtoppm and ppmtoy4m and find a way to merge in filters and create > a single program that'd do the y4m -> ppm -> filtering -> y4m > without half a dozen (or so) pipes. A bash-script should do... ;-). Pipes aren't that heavy, it's mostly processes you save. You get flexibility, though. Ronald -- Ronald Bultje <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Colorspace transform question
Hi Dan - > From: [EMAIL PROTECTED] > Or really how much more damage than is already done going from 4:1:1 > to 4:2:0, which really results in the (quality) equivalent of 4:1:0 Very true. One of my brothers works at a TV station and mentioned they use 10 bit 4:2:2 everywhere up till the final stage - some really good looking pictures when he showed me around ;) > In particular the 'pnmnlfilt' program sounds intriguing, it offers: > 'Alpha trimmed mean filter', 'Optimal estimation smoothing' and > 'Edge enhancement'. All the types of things we might want to do or > at least try. > > Do they do pipes? Horrible to think of splitting into frame images... Yes. Or rather I should say many of them do. It's on a "per request" basis that the individual programs are converted from single image to stream handling. pnmnlfilt is one program that's been converted. Perhaps the more efficient method would be to grab copies of y4mtoppm and ppmtoy4m and find a way to merge in filters and create a single program that'd do the y4m -> ppm -> filtering -> y4m without half a dozen (or so) pipes. Cheers, Steven Schultz --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Colorspace transform question
Out of curiosity how much is the data "damaged" by a conversion from 4:1:1 to RGB and from there to 4:2:0? Or really how much more damage than is already done going from 4:1:1 to 4:2:0, which really results in the (quality) equivalent of 4:1:0 (if such a beast exists). The decimation and interpolation errors that result from 4:1:1 -> 4:4:4 (RGB) -> 4:2:0 can be made as small as you like in theory - just use larger filters (kernels). Of course, many of the available conversion tools don't allow very sophisticated filtering, and large filters take a while to compute. In particular the decimation (subsampling) stage is the critical one. As for colorspace-conversion damage, I presume this depends on the nature of the input. The full R'G'B' colorspace maps into YCbCr, but even ignoring quantization it's not always invertible. It's easy enough to check for clipping in the inverse map, though (although I don't know of any programs that do). If the actual source of the video was an RGB source - say a typical CCD-based video camera, then maybe you're OK. My own camera does actually produce Y values above 235, in which case you would have to scale it down to avoid clipping. I have used yuvcorrect in RGB mode on occasion, and I can't say I've identified any obvious artifacts due to the conversion. Certainly the CCD noise dominates any extra quantization noise. A cheap and dirty measurement would be to measure the mean-square/avg/peak error between 4:1:1->4:2:0 frames and 4:1:1->RGB->4:2:0. Or just look at them side by side. The normal path is to go from DV (411) to 420 directly but I'm eye'ing some of the NetPBM filters (seems that most/many of the good filters want PPM data). In particular the 'pnmnlfilt' program sounds intriguing, it offers: 'Alpha trimmed mean filter', 'Optimal estimation smoothing' and 'Edge enhancement'. All the types of things we might want to do or at least try. Do they do pipes? Horrible to think of splitting into frame images... Dan --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] Colorspace transform question
Hi - Out of curiosity how much is the data "damaged" by a conversion from 4:1:1 to RGB and from there to 4:2:0? The normal path is to go from DV (411) to 420 directly but I'm eye'ing some of the NetPBM filters (seems that most/many of the good filters want PPM data). In particular the 'pnmnlfilt' program sounds intriguing, it offers: 'Alpha trimmed mean filter', 'Optimal estimation smoothing' and 'Edge enhancement'. All the types of things we might want to do or at least try. Are there similar types of programs that work with the DV or 420 data?Those would be preferable of course but I do not know of any. Cheers, Steven Schultz --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
