Hi -
> From: [EMAIL PROTECTED]
> Subject: [Mjpeg-users] Re: Mjpeg-users digest, Vol 1 #889 - 5 msgs
Hmmm, the digest form apparently obscures the initial Subject: -
was wonder what "Vol 1 #899 - 5 msgs" was all about.
It is a low volume group for the most part - would it be feasible
to use the individual article form I wonder?
> Have you tried yuvcorrect -M STAT? It makes frame-by-frame histograms
No, I had forgotten about it.
> INFO: [yuvcorrect] 020 00041 00000 00000
> INFO: [yuvcorrect] 021 00432 00000 00000
> INFO: [yuvcorrect] 022 02900 00000 00000
> INFO: [yuvcorrect] 023 09386 00000 00000
> INFO: [yuvcorrect] 024 16027 00000 00000
> INFO: [yuvcorrect] 025 16109 00000 00000
> INFO: [yuvcorrect] 026 12281 00000 00000
> INFO: [yuvcorrect] 027 09313 00000 00000
> INFO: [yuvcorrect] 028 06954 00000 00000
> INFO: [yuvcorrect] 029 04929 00000 00000
> INFO: [yuvcorrect] 030 03300 00000 00000
> INFO: [yuvcorrect] 031 02051 00000 00000
> INFO: [yuvcorrect] 032 01248 00000 00000
> INFO: [yuvcorrect] 033 00681 00000 00000
> INFO: [yuvcorrect] 034 00384 00000 00000
> INFO: [yuvcorrect] 035 00204 00000 00000
> INFO: [yuvcorrect] 036 00091 00000 00000
> INFO: [yuvcorrect] 037 00041 00000 00000
> So it looks like I have less of a spread than you, especially in CbCr.
Not much less though. The center in your case is similar - in
your case it's 25, in my test it was 28.
> Sounds like you want to apply a nonlinear mapping that squeezes your
> darker pixels closer together but leaves the rest alone. Perhaps a
Not really, at least I don't think so. What I _think_ I need
(and have the initial attempt running) is a _very_ selective
highpass filter (no pixels with Y' above 48 are even looked at)
that uses a 'midpoint' and a combination of clip and core. More below.
> piecewise-linear extension to yuvcorrect? Have you tried adjusting
> the gamma (a power nonlinearity curve) via yuvcorrect? That might
But that affects *everything*, not just the values that are similar
in value *and* close to black (where closeness is user specified).
Right?
> have a similar effect. Or, you could just clip below some "black"
> threshold, and then restretch what remains to the full range,
That's a bit too aggressive I suspect.
> something like:
> yuvcorrect -Y Y_1.0_28_235_16_235
Will that translate both 31/128/125 and 26/129/129 into 28/128/128?
> or just clip:
> yuvcorrect -Y Y_1.0_28_235_28_235
> or clip and shift down (makes it darker though):
> yuvcorrect -Y Y_1.0_28_235_16_223
I think what is wanted, and appears to be working is to specify
a 'center point' and a 'radius' for Y', Cb, and Cr (usually Cb and
Cr would be the same but they don't have to be).
Here's a small sample of real data from a 'black frame':
28 128 125
29 128 125
29 128 125
31 129 126
29 129 126
32 129 124
30 129 124
The distribution for the frame is:
Y 16 4669
Y 17 4434
Y 18 1645
Y 19 2228
Y 20 3909
Y 21 6750
Y 22 10897
Y 23 17327
Y 24 25437
Y 25 33738
Y 26 41316
Y 27 46068
Y 28 44184
Y 29 35925
Y 30 26505
Y 31 18060
Y 32 11277
Y 33 5925
Y 34 2862
Y 35 1329
Y 36 606
Y 37 274
Y 38 127
Y 39 73
Y 40 23
U 122 32
U 123 98
U 124 362
U 125 1222
U 126 3432
U 127 9572
U 128 20388
U 129 26756
U 130 16098
U 131 5866
U 132 1816
U 133 548
U 134 166
U 135 38
U 136 2
V 120 62
V 121 354
V 122 1624
V 123 6420
V 124 17160
V 125 24796
V 126 18654
V 127 10470
V 128 4858
V 129 1486
V 130 424
V 131 66
V 132 20
To reduce the random shades of grey problem what I want to do
is convert
23-31/124-132/124-132 into 28/128/128
but leave things like 49/125/128 and 16/200/64 alone.
What I have is a preliminary 'y4mblackfix' which takes allows me to
specify what pixels are to be considered identically black and to
subsitute the specified center point values. '-y 27 -Y 4"
sets the centerpoint for Y' to 27 meaning that pixels with 23 thru 31
values will be examined to see if their Cb and Cr values qualify as
'black'. The defaults for the center point and radius for Cb and Cr
are 128 and 4 respectively (and usually are not changed). This means
that 23-31/124-132/124-132 pixels become 27/128/128 - the Y' values
23, 24, 25, 26 become 27 (clip) and 28,29,30,31 become 27 (core)
Similarily the Cr/Cb values 124,125,126,127 and 129,130,131,132
become 128. Undetectable to most human eyes (I really think) but
to the encoder it has a lot more redundancy in place of random
variation and that helps the picture quality in dim scenes.
Much less random/noise variation in the dark scenes and that should
keep grey blocks from dancing around the screen.
The tests so far show that after the fade in/out from black the
number of "DARK" pixels detected falls dramatically.
INFO: [a.out] W 720 H 480 R 30000/1001 Fsize 518400
INFO: [a.out] frame 0 num_dark: 130448
INFO: [a.out] frame 1 num_dark: 134646
INFO: [a.out] frame 2 num_dark: 137259
INFO: [a.out] frame 3 num_dark: 134091
INFO: [a.out] frame 4 num_dark: 139798
INFO: [a.out] frame 5 num_dark: 140109
INFO: [a.out] frame 6 num_dark: 139352
INFO: [a.out] frame 7 num_dark: 141879
INFO: [a.out] frame 8 num_dark: 138247
INFO: [a.out] frame 9 num_dark: 142985
INFO: [a.out] frame 10 num_dark: 140461
INFO: [a.out] frame 11 num_dark: 140132
INFO: [a.out] frame 12 num_dark: 139869
INFO: [a.out] frame 13 num_dark: 135289
INFO: [a.out] frame 14 num_dark: 135146
INFO: [a.out] frame 15 num_dark: 143586
INFO: [a.out] frame 16 num_dark: 28684
INFO: [a.out] frame 17 num_dark: 28777
INFO: [a.out] frame 18 num_dark: 31784
INFO: [a.out] frame 19 num_dark: 32846
INFO: [a.out] frame 20 num_dark: 31032
INFO: [a.out] frame 21 num_dark: 33111
INFO: [a.out] frame 22 num_dark: 32915
see how it's falling quickly? Each frame is 345600 pixels of course
(720x480). But a few more frames later on, after the fade in from
black is finishing and the opening logo comes up:
INFO: [a.out] frame 100 num_dark: 209
INFO: [a.out] frame 101 num_dark: 209
INFO: [a.out] frame 102 num_dark: 216
INFO: [a.out] frame 103 num_dark: 227
INFO: [a.out] frame 104 num_dark: 220
INFO: [a.out] frame 105 num_dark: 212
INFO: [a.out] frame 106 num_dark: 219
INFO: [a.out] frame 107 num_dark: 226
Then the dark nightscene begins:
INFO: [a.out] frame 1029 num_dark: 59440
INFO: [a.out] frame 1030 num_dark: 60310
INFO: [a.out] frame 1031 num_dark: 59036
INFO: [a.out] frame 1032 num_dark: 60712
INFO: [a.out] frame 1033 num_dark: 57905
~15% of the pixels appear to be 'dark' with randomly varying but
close values.
Later on as the fades to/from black happen it's interesting to
watch the number of 'dark pixels' go up and down.
> I hope that the encoder doesn't waste a lot of bits encoding chroma
> for such low luma, as the eye can't distinguish dark colors so well.
Bits are bits and pixels are pixels. If the encoder gets random
values close to black but not exactly black then of course it will
attempt its best to encode the data. Mpeg2enc has no idea
that 31/128/125 and 28/124/127 should be treated the same - so in
dark scenes where many/all of the pixels are close together in value
the slightest difference will get picked up as the 'action' that
needs to be encoded - at that point there is the familar splotches
of grey dancing around on the screen.
I'm going to play around a bit more and burn a DVD or two to see
if the program's having the expected visual effect using a real TV
Cheers,
Steven Schultz
2
-------------------------------------------------------
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
