On Sun, 28 Sep 2003, Edouard Chalaron wrote:
> For the last week or so I have been playing around with a perl script calling
> a gimp function in a directory full of ppm to be mpeg2encoded later...
> The plugin is plug_in_unsharp_mask and described as :
> So far I export in single ppms my DV file, transform the ppms, save back into
> a DV file.... a pain ! On a 5 minutes stream it is not much of a big deal,
> but on a 280 minutes it is almost impossible. Too slow, too much ressources
> etc.....
It would be a little faster and use less disc space if the GIMP
could process a PPM stream instead of single images but even then
the GIMP is a stillimage processor and isn't optimal for streams
of data.
I have experimented with various filters from the NetPBM package
(in particular the pnmnlfilt program). Some (but not all) of
the programs from NetPBM are 'stream aware' and thus can be placed
in a pipeline instead of having to create a directory full of
ppm files.
What I found is that the color space conversion is quite cpu
intense. And there are two of them involved - from YUV to RGB
and then back again. That takes more cpu time than one might
have initially thought. There's also the inevitable errors
introduced (while the conversion is symmetric there's the
rounding/truncation that creeps in). Also of concern is the
color shift that might happen. Calculations in the RGB space
may produce non-broadcast safe colors, the truncation back to
safe values may introduce a color shift. Oh, the internal RGB
calculations could also overflow 8 bits - to be safe(r) 16 bits
should be used so that the maxval of 255 can be enforced (which of
course means the output image will not be quite correct).
It'd better (and a lot faster) if the processing could be done
in the YUV (4:2:0) space and not take all the cpu cycles to
convert to/from RGB - but that's hard (image processing programs
such as the GIMP and most people think RGB rather than YUV).
Since the human eye is more sensitive to luma than chroma perhaps
just running the unsharp filter over the Y would achieve most of
the benefit while reducing the complexity of the code.
As has been pointed out 'sharpening' will raise the average
bitrate.
Have you done some tests comparing the average bitrate reported
by mplex between the before and after unsharp processing?
Cheers,
Steven Schultz
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
