Help me adjust brightness for a dark video source

[B3-bomber]

Any tips on what these do so I can tweek them and check for actual results would be awesome

YLevelsS(0,10.0,255,0,255)
Tweak(Bright=-14,Cont=0.93,Coring=False)

I spent more time on the avisynth warpsharp site finding files I was missing (and a few on the forum that aren't there oddly, masktools).


LemMotlow, those screenshots of the redman holding a head are an improvement. Forgot to mention that earlier. On the default encode when it gets that far into the scene the head is no longer visible.

[manono]

Originally Posted by B3-bomber

Any tips on what these do so I can tweek them and check for actual results would be awesome

A=Last
B=A.YLevelsS(0,10.0,255,0,255)
B=B.Tweak(Bright=-14,Cont=0.93,Coring=False)
StackHorizontal(A,B)#perhaps followed by a resize so you can see them more easily

Or teach yourself to use AvsPMod where you can compare by switching tabs back and forth.

[B3-bomber]

Which one of these actually increases/decreases brightness and whats the value range for them. Adding more steps to something I have no clue how it works isn't the best idea.

Man that reminds me of debugging some old mirc code. One guy I asked basically told me get lost until I learned the entire new coding structure. I knew where the error was generally too, just not specifically what was messed up. Was all of maybe 10 minutes with someone who actually bothered to help me debug it. So yeah just what is present first. I'll ask questions if that doesn't do anything like I need it to:P

[manono]

If you're not even willing to read the docs, then why should anyone care enough to explain it to you?

Tweak

Ylevels

StackHorizontal

Which one of these actually increases/decreases brightness...

If you understand that brightness determines the black levels, then Tweak's 'Bright=' does that.

...and whats the value range for them.

From the Tweak page:

bright (-255.0 to 255.0, default 0.0)

[B3-bomber]

sorry, didn't know those sites existed. it's been a few years since i've worked with this stuff.

[StainlessS]

@B3-bomber
The docs are also included via "Avisynth 2.5/Docs/English/Index.htm" although I doubt if YLevels is in there.
There is also a searchable compressed (CHM) help file version of docs via link in my sig, nice to have on a hot-key
eg "CTRL/ALT H". (EDIT: Although most up to date versions are in the Wiki)

[B3-bomber]

cool. i read the ylevels stuff. the scary thing is i had used levels at one point. that's how outdated my memories are.

got some progress working on the overly dark stuff. seems i have to use a sharpener on it though since it fuzzes the outlines. thanks for the information

[LemMotlow]

d l t d

[LemMotlow]

d l t d

[IanB]

Yes crushing blacks (and smashing whites) looses data. It's what you get with 8 bit integer arithmetic.

As you see in your histograms, when you stretch out the crushed blacks you get holes.

The maths is simple O=k*(I-16)+16, k being the 'stretch' factor.

For example with k=2 we get the following :-

Inpt Outpt
16 -> 16
17 -> 18
18 -> 20
19 -> 22
20 -> 24
...
32 -> 48
...
etc

You can mask and compensate for the effect with methods like dithering and non-linear stretching methods, but the data is gone.

[LemMotlow]

d l t d

[Mounir]

Something like intelligent dithering (like the msu super precision filter) would be better, i'm not sure we have that for avisynth yet, i recall we talked about it some time ago here

[manono]

Originally Posted by manono

All this makes me wonder just how you're making your conversion to RGB in the first
place. And why convert at all?

Originally Posted by LemMotlow

I guess I'm misinformed.

Maybe. We'll see. You already know the reason for doing the conversion to RGB before using any of the
VDub filters that require RGB - because VDub stretches everything to 0-255 which often results in clipping.
So to prevent that from happening we like to do the conversion properly ourselves when the use of VDub
filters is necessary, whether we use the filters in our scripts or in VDub itself. Let's see what happens if we don't
do a proper conversion. I'm opening the lightarea.demuxed.m2v directly in VDubMod, scrolling to frame 39 and
using the Histogram in Color Tools. The result is the leftmost picture 1 of the set of four pictures
below. Does it look familiar? Opening an AviSynth script with no conversion in the script results in
picture 2, pretty much the same thing. Adding your conversion line to the script
(ConvertToRGB32(Matrix="Rec601")) gives you pic 3, something very similar to the first two. Now, convert it the
way you should have with ConvertToRGB(Matrix="PC.601") and you get the fourth picture. No clipping.

As you know, since you lectured me on RGB and YUV and computer monitors and television monitors, a video
looks different on a computer monitor than it does on a TV screen. The levels are different and they're
calibrated differently. What looks too dark to make out anything on a computer monitor just looks dark
but viewable on a television. Which is the way that dark scene is meant to appear - murky, difficult to make
out, which adds to the feelings of paranoia and horror it's meant to convey. I'm convinced the production
company that made this anime knew exactly what they were doing and that it looks exactly as it should
when viewed on a properly calibrated TV set. However...

Originally Posted by LemMotlow

...and that you won't get clean images using YLevels and Tweak alone...

You're saying that the AviSynth filters aren't good enough to adjust the brightness, contrast, levels,
gamma, and the like? Sheer and utter nonsense. Not only can you do it well using AviSynth, but you
should use AviSynth for such simple things (if they need it) to avoid the unnecessary colorspace
conversions and the problems (and mistakes) that result from colorspace conversions. The only time
I ever go to RGB is for some color work. Others use VDub only filters (ones such as Neat Video) for other purposes.

By the way, I'm sure you know your 'new and improved' darkarea_open_try8g.m2v is encoded as 4:3 while the
source is 16:9. And I'm sure you know you hard-telecined it and encoded it as interlaced, while the
source is encoded as progressive 23.976fps with pulldown. At least the samples are. So we won't use it as
an example of your restoration and encoding prowess.

[LemMotlow]

d l t d

[B3-bomber]

ok, is there anything that default drops crap frames they added in a lame attempt as a transition frame? they really would have done better just using the next one after this crap. the frame after the 2 ghosted spots he is shifted entirely to fit that position. i noticed these running an encoded ver at normal speed. i HATE when things like this are done.