(Relates to FlaskMPEG 0.7.8-39 beta)
-- the main video
window always has a noticeably brighter image than the "video
panel" has. How comes?
I realized this when I was trying to
correct the brightness level (which is in dire need of a numeric value
display - maybe even a histogram ... I see, I am asking for too
much).
Has something obvious escaped me?
But
a great piece of software anyway, thanks very much!
Fred
Logged In: YES
user_id=596130
I'm going to take a stab in the dark and ask if there are any
dark spots on your monitor due to magnetic interference. I
have had monitors that are not a uniform brightness, and if
that was the case, the application is not at fault.
I hate to accuse you of being absent minded. If this is
indeed the reason, then I will have reason to guffaw at this
support request.
Logged In: YES
user_id=166425
Quick answer: do not change brightness in FlaksMPEG.
Long answer:
I also experience such "problems" but in the reverse direction:
video panel brighter than normal video display.
This is not FlaskMPEG's fault... err... well, let me explain:
The main video window is a Video overlay surface (most
probably using DirectX), and the video panel window is normal
windows' window (i.e. graphic window, the image is displayed
using DrawDIB or BitBlt).
You can notice the difference when moving the windows:
video overlay surfaces have slower reponse time. Also, when
you try a screen capture (using the PrintScreen key), you will
get a black area for the video overlay, and the normal picture
for the video panel.
Video overlay surfaces are handled directly by the hardware
(on recent video cards, i.e. after 1997), and thus, rendering
can differ from what is shown by windows graphics, especially
if the video overlay is in YUV space (while windows is RBG),
because the YUV->RGB translation done by the hardware may
be different from FlaskMPEG algorithm.
In my case, all these issues do not really influence brightness.
For me, the difference comes from a setting in my display
driver (I have a nVidia GeForce 2): gamma correction.
As I do not like the default PC 2.2 to 2.5 gamma setting, I
always tweak my gamma correction setting in the display
driver to calibrate my display to a gamma between 1.8 and
2.0 (which is close to Macintosh: 1.72), because this
matches the settings of my Canon camera, scanner, etc.
Most photo stuff being made on Macs, this is a widespread
setting.
The problem is: this only impacts graphics, NOT video
overlays (in nVidia board - other chips from Cirrus Logic or
others can ask the user if he wants to apply it also to video).
So, in my case, as gamma 2.0 makes a brighter display than
2.2 or 2.5, I end up with a video panel brighter than the video
overlay.
I would suggest that you keep in mind that video overlay is
different from normal windows graphics, but nearly all video
players use video overlays (much faster...). So, if you change
brightness, trust the overlay.
BUT, you should also keep in mind that PCs have different
settings than TVs (TVs are brighter, I think), and different
PCs can have different settings. Alas, there is no standard
gamma setting in the PC world (contrary to the Mac world).
Something around 2.0-2.2 seems widely accepted, though.
Gamma differences are most noticeable in the dark areas.
Finally, the brightness setting in FlaksMPEG does not correct
gamma. It is just a basic gain, which will nearly not affect
dark areas. So, I would suggest that you do not touch it.
Version 6.0 provided an 'offset/gain' setting which was a bit
more useful, but not as much as a gamma correction would
be. All movies seem too dark on my PC.
I wish next versions will provide gamma correction (maybe I
will write the code myself... that is the magic of Open
Source!)
Hoping this would clarify the brightness issue.
Philippe de Lagrange
--------------
For more info about monitor calibration:
http://www.aim-
dtp.net/aim/evaluation/gamma_space/index.htm
(super-accurate calibration charts, very useful)
and also, to help calibrating your monitor, this software is
useful (Nokia monitor test):
http://freepctech.com/rode/004.shtml
(brightness and contrast must be correctly set before
tweaking with aim-dtp calibration charts)