encoder "pre-emphasis"... useful idea?

[Mug Funky]

yo. i'm encoding something with loads of dark scenes, and they're going blocky no matter what i do (blockbuster, etc). so i had a bit of an idea:

assuming that most dark scenes look great on a low gamma screen, an LCD or a TV when the lights are on, but they look crapful when the lights are turned off, or the gamma is upped, could an encoder work on a gamma-corrected input, but actually store the non-filtered picture? this would basically be a kind of psychovisual thing, a little like lumi-masking - the encoder does it's bit allocation and ME on a gamma-corrected image, but actually stores the untouched video.

i'm not sure if this is workable or even useful, but it could be something an mpeg-2 philanthropist could look at :)

i swear, one of these days i'll learn C or C++ and do all this stuff myself...

[communist]

Just an idea: would a 2pass encode work? 1st pass with the filtered source, then in the 2nd pass encode the unfiltered source with the pass file generated by analyzing the filtered one.

[Mug Funky]

i was thinking that, but without the encoder being aware of the differences, i doubt i'd get the intended effect - probably just an undersized file :)

[vhelp]

@ Mug_funky

Two possible causes of this are:

* Encoder (ie, brand-x)
* Encoder param setup (ie, bitrate)

Based off my long-term experience with encoding ...

IMO, most of the pixelation (blocky) seen in those dark
scenes are on account of too low a bitrate. The only way to
eliviate is to rase the bitrate high, especially if you are trying
to squeeze more than an hours (60 mins) worth of video onto
a r/rw disk. This is why I switched to using CBR in my encodes
and make 60 minute videos.., though most of my stuf are all 60 min
or less - a coinsidence.
.
I've found ways to eliminate this, but this requires some good
tools.., and TMPGenc's color filters and built-in WYSIWYG preview
inside OVERLAY window. That, coupled with my ATI-Rage Furo Pro
graphics card and how it interacts with OVERLAY preview turned on
is no match (I always win the batter w/ this blocky issue) on
account of the graphics cards capabilities, I can see certain
granurility/ditering of pixels, and while I adjust the colors,
I can see very distintivly the smoothness (or roughness) and
adjust appropriately. For low bitrate, this is a great tool to
use, and no other filter needs to be applied.
But, if you have a tipicle graphics card, chances are, you won't
have this "unique" feature, and as a result, you will not be
able to see what I'm on about here :(
.
So, in the end, its all down to bitrate. You just gotta raise it,
or do a bunch of what-if scenarios with color filters.

True about the lighting. I've known about this untalked of phenomina
for a long time. And, an LCD will express this even more. That's why
I do all my video color tweaking late in the evening or so.. its the time.

-vhelp

[Mug Funky]

actually, for whatever reason the LCD i'm on now shows sod-all of the dark areas. no matter what i tweak it just doesn't show darks properly.

i'd like to have the lights off, but unfortunately setup doesn't allow this.

it would be good if an encoder saw a dark scene the same way we do - nonlinearly.

[Pookie]

Have you looked at Don's deblocking features that are built into DGIndex ? Pretty good stuff.

[Mug Funky]

by default i use cpu=4 in mpeg2source... however in dark scenes from an already blocky source encoders tend to just output greenish pulsing mush. i think curve compression settings may be useful in these cases (and some heavy "de-blinking" filters in avisynth).