Hi Dan -
> From: [EMAIL PROTECTED]
> would it be feasible to use the individual article form I wonder?
>
> Done. Bad enough I did it twice in a row, but I know me, and I'd do
> it again if I stayed on digest. Now if others wouldn't rub it in by
> replying with the same subject line... :)
<grin> But I couldn't remember exactly what the original subject
was (I'm not one of those packrats that hordes/logs everything sent
or received).
> highpass filter (no pixels with Y' above 48 are even looked at)
>
> I assume you mean highpass in the Y-domain sense and not in the usual
> Fourier domain sense?
Yes indeed. I check the Y' value and if it's above a threshold
(48 by default but it's selectable by the user) the pixel isn't
considered for replacement.
> but leave things like 49/125/128 and 16/200/64 alone.
>
> What you are suggesting is a more precise clipping/quantizing of the
> color 3-space than my own slash-and-burn. I was thinking that Y=16
That is definitely the case. Trying to minimize the 'damage' done
by any kind of filtering but also achieve a noticeable positive
effect in the dark scenes and the fade in/out from black.
> was black regardless of CbCr, which I guess isn't really true. Do you
You betcha it aint! Y'=16, Cb=200, Cr=128 is a shade blue that's
almost eye-popping (and 16/200/200 is an awful pink/magenta/violet).
I have a little utility (local work of art that started out as a
'black' generator) that allows me to generate steady frames of any
Y'CbCr combo I want:
y4mblack -n 1000 -Y 16 -U 200 -V 128 | yuvplay
to check things out. Man you can get some weird colors that way ;)
> actually have visible colored regions where Y is meaningfully less
> than your gray patches? I was assuming that below 28 or so everything
> was essentially black, and that you wanted to translate your gray
> regions to true black. But it sounds like the Y values of your gray
> areas actually float above those of some image features you want to keep?
Below 28 or so is definitely not black unless you take into account
the chroma components of course (as mentioned above). 28/128/128
is not, that I can see, appreciably different from 16/128/128 on
a computer monitor. On a real TV? It might be noticeable. I
decided it was better to not be overly aggressive.
The goal was to reduce the number of shades of 'black/grey' so that
the encoder in dark scenes wouldn't see so much variation (when
everything is close to a single number then anything that's even
slightly different stands out like a sore thumb or greyblock).
> I'll look forward to trying this out. Does it seem to reduce bitrates much?
I made a short DVD tonight with a ~2-3 second fade in from black and
oh my goodness - what a difference 'y4mblackfix' made! The bulk of
the movie clip wasn't dark so it wasn't affected at all. Probably
doesn't do very much at all for the overall bit rate unless the movie
is one that has a lot of dark scenes (and even then the aesthetic
improvement is worth more than a bitrate reduction ;)). I do have
one entire (89min) movie I'll re-encode tomorrow and see if there's
any bitrate effect (luckily it's a Vincent Price horror film with
lots of dark scenes!).
If none of the other developers object to the introduction of a
new utility I'll check it in. No manpage yet but between the usage()
summary and the defaults (plus the source :)) it shouldn't be hard to
figure out. It's still a bit "rough" in that the command line options
and syntax might change wildly from one day to the next.
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
