Use refined average luma to control gamma inside smoothlevels

[Ponder]

Many shows jump from indoor scenes (normal to dark) to outdoor scenes (bright) repeatly.
When using gamma=1.27, the indoor scenes look pleasing on my monitor, but with the same 1.27
gamma, outdoor scenes look very bright. What I want is to collapse the 1.27 gamma to about 1.0
on outdoor scenes.

I tried ScriptClip("smoothlevels(0,1.56-0.006*AverageLuma(),255,0,255,BrightSTR=7000,smode=0")
to vary the gamma paramater inside smoothlevels, but it is 90% slower than without scriptClip!.
By comparison, ScriptClip("levels(..Avgluma)") is about 16% slower than without ScriptClip.

I like the proctect=16 and BrightSTR features from Lato very much. Ylevelss looks very nice
too, but without proctect=16, it is a little bit handicap.

Are there any filters or very fast code to get the average luma value out, so we can use it
elsewhere. Actually, the average luma is half bad, it gets fooled all the time when someone
wearing black clothings or black cars in or pass by the screen; in a tuxedo party; funeral
setting even at bright outdoor; black bear or horse (large objects) under the sun; TV, stereo
equipments near by; Sniper telescope view; fixing cars(problems) on tar road... Average luma
will think all these scenes are alot darker.

Vice versa, doctors, nurses, cooks,sailors in white uniforms in indoor scene; bathrobes in sauna,
spa; dancing in white undies; girls pillows fight; sitting on hotel bed sheet; open a fridge to
get something scenes happen a lot more than we think, will fool average luma to output large
value. I think 20% or more scenes can fool average luma easily.

At times, we do get lucky when very dark and light objects appear in the same scene at
moderate distant, the dark and light affect cancel each other so luma average seem stable.
When these dark or light object moves, or camera view move closer to the one of the object,
luma average get fooled again.

To better separate bright and dark scene,the solution seems to be that pixels under 16,18?
and bright pixels (245-255?) should not be calculated into a "refined luma average",or the
users can choose what dark and bright range to ignore.

something like Get_refined_luma_average(0-16,245-255)

After many hours readings Avisynth syntax, eventually tried this
zz=String("AverageLuma()")
yy=Value(zz)
rnd=round(yy)

Used it to control output_low & hi, it took me a while to realize yy actually =0. Awful mistake.
my skill to write such script or to code such plugin is quite limited.
Mathematically, I know it is very simple to calculate such single number.
I hope someone can eventually write such useful "Get_refined_luma_average" plugin or script.
Any helps appreciated.

I test smoothlevel and ScriptClip together several times to make sure,but 90% slower is
quite painful to watch "half bad averageluma moderating script" in real time 1024 material.:-(

[Ponder]

Read Ycurve 2 weeks ago, suddenly realize doing this
smoothcurve(ycurve="0-128;16-128;21-21;129-129;255-255") map pixel 0-16 to 128, 21-21 probably
map 17-129...21 to 133. I can now get a refined luma average. But still can't assign it to a
variable. Masktool with levels to do similar mapping, don't know if that works, hint?

tried these before
last=FrameEvaluate(last, "global avgLuma=AverageLuma()")
global last=FrameEvaluate(last, "global avgLuma=AverageLuma()")
global last=frameevaluate( last," avgLuma = averageLuma() ")

none work, either wrong syntax, likely undoable. AverageLuma() is a strange animal, you can
see it on screen via ColorYUV(Analyze=True), print the value on screen, save it to file, but
can not assign it to a variable to make it useful!

[Gavino]

AverageLuma() is a per-frame (not a per-clip) property, so is only available inside the run-time environment (http://avisynth.org/mediawiki/Runtime_environment). This means that you cannot get its value 'out' to a variable in the outer script, as these are set at compile-time.

However, you can 'cheat' to get the average luma for a specific frame at compile-time as follows:
current_frame=10
x=AverageLuma(clip)
will give average luma for frame 10.
This is cheating as it relies on the internal workings of AverageLuma which could in principle be changed in the future.

For your refined luma average, you could use MaskTools.
Create a mask which is 255 for the pixels of interest (eg in a specified range) and 0 elsewhere. Then apply the mask to the clip, and calculate
255*AverageLuma(masked clip)/AverageLuma(mask)

[Ponder]

Gavino, thanks for the reply, I began using these 5 commands: mt_makediff, mt_adddiff,mt_average
and mt_invert and mt_merge about 3-4 weeks ago as well as smoothadjust1.74. The line

"AverageLuma() is a per-frame (not a per-clip) property", is understandable. The rest still
over my head. Which "masktool command" is needed to

"Create a mask which is 255 for the pixels of interest (eg in a specified range) and 0
elsewhere". I like to try a refined luma average to ignore the range 0-21, and 240-255.
can this be written in a line or 2?

[Gavino]

The line "AverageLuma() is a per-frame (not a per-clip) property", is understandable. The rest still over my head.
The run-time environment (which includes ScriptClip and FrameEvaluate) is difficult to understand at first and you need to read all the documentation several times before it sinks in. This includes
http://avisynth.org/mediawiki/Runtime_environment
http://avisynth.org/mediawiki/The_script_execution_model
as well as the docs for the individual run-time filters and functions.

Which "masktool command" is needed to "Create a mask which is 255 for the pixels of interest (eg in a specified range) and 0 elsewhere". I like to try a refined luma average to ignore the range 0-21, and 240-255.
... # set up source (assumed YV12) as 'last'
mask = mt_lut(expr=mt_polish("x > 21 & x < 240 ? 255 : 0"))
masked = mt_lut(expr=mt_polish("x > 21 & x < 240 ? x : 0"))
ScriptClip("""
a = AverageLuma(mask)
ravl = a > 0 ? 255*AverageLuma(masked)/a : 0 # avoid divide by zero
... # do something based on value of ravl
""")

[Ponder]

Thanks again Gavino, now I can study this script. it is fairly readable, still need to digest it and learn the syntax. :-)

[Ponder]

@Gavino, Thanks for the script, I learned a lots from it. Also,

"However, you can 'cheat' to get the average luma for a specific frame at compile-time as follows:
current_frame=10
x=AverageLuma(clip)
will give average luma for frame 10.
This is cheating as it relies on the internal workings of AverageLuma which could in principle be changed in the future."

Do some testings, Now I know what you mean,
If frame no. 10 has luma 72,3, all frames get 72.3. :-(. I guess it is impossible to loop it.

I modified the script to this:

mask1=last.reduceby2()
refine_luma=mask1.mt_lut(expr=mt_polish("x > 21 & x < 240 ? x : 128"))
ScriptClip("smoothlevels(0,1.6-0.006*AverageLuma(refine_luma),255,0,255,BrightSTR=7000,smode=0)")

still 90ish % slower even refine_luma is 1/4 of original size. Pixels between 21 and 240 seems not
a good choice, since pixels under 27 are very dark. Use pixels value from 30-220 seems better
contol, need more tests to get good range.

I think using refine_luma to moderate not only gamma, but DarkStr and output_low from smoothlevels
give even better result. When luma is low.. gradually decrease DarkStr, vice versa.

I tried these
filename = "b:\output.txt"
WriteFile(filename,"AverageLuma",append = true) #or
WriteFile(filename,"AverageLuma",append = false) #with ConditionalReader

ConditionalReader("b:\output.txt", "avgluma",true) # to do
smoothlevels(0,1.6-0.006*avgluma,255,0,255,BrightSTR=7000,smode=0)")
script refuse to load.. type float problems..

Avisynth seems to for forbid this! Am I mistaken?



Found sh0dan modified AGC averageluma version, not yet fully understand how it works, but
it is about 240% faster than ScriptClip("smoothlevels(...)")!.

Will try to combine my "refined_luma" and Smoothlevels into it, but don't know how it work out.
----------------------------------------------------
global gl_lum = 1
global gl_c = 0
global filterme = 0

function AGC (clip c, int "mode",float "multiplier", float "gamma", int "radius",int "scenechange", bool "luma")
{
global gl_radius = default(radius,4)
global gl_scenechange = default(scenechange,20)
global gl_multiplier = default(multiplier,.96)
gl_c = c
global gl_gamma = default(gamma,1)
mode= default(mode, 2)
luma = default(luma,true)

global gl_multiplier = (mode==2)? float(gl_multiplier*2) :
\ float(gl_multiplier)

global gl_method = (mode==1)? "averageluma(filterme)" :
\ (mode==2)? "YplaneMax(filterme)" : "YplaneMedian(filterme)"

filterme = gl_c.deleteframe(0).reduceby2().reduceby2().
\ temporalsoften(gl_radius,255,255,gl_scenechange,2).
\ levels(0,gl_gamma,255,0,255,coring=false)

gl_c=gl_c.frameevaluate("global gl_lum = gl_multiplier*128 / (" + string(gl_method + ")")
\ ,after_frame=false)

(luma==true)? gl_c.scriptclip("coloryuv(gain_y=round(gl_lum * 256)-256)") :
\ gl_c.scriptclip("converttorgb32().RGBadjust(gl_lum,gl_lum,gl_lum,0).converttoyv12()")

}
This works realtime on the material I've tested.

--------------------------------------------------------

[Gavino]

If frame no. 10 has luma 72,3, all frames get 72.3. :-(. I guess it is impossible to loop it.
That's why I said "for a specific frame".
For loops, see GScript. (But what would you do in the loop?)

I modified the script to this:
mask1=last.reduceby2()
refine_luma=mask1.mt_lut(expr=mt_polish("x > 21 & x < 240 ? x : 128"))
ScriptClip("smoothlevels(0,1.6-0.006*AverageLuma(refine_luma),255,0,255,BrightSTR=7000,smode=0)")
That doesn't look right.
Pixels outside of 22-239 are counted as 128? :confused:

ConditionalReader("b:\output.txt", "avgluma",true) # to do
smoothlevels(0,1.6-0.006*avgluma,255,0,255,BrightSTR=7000,smode=0)")
script refuse to load.. type float problems..

Avisynth seems to for forbid this! Am I mistaken?
ConditionalFilter sets the variable at run-time (for each frame), so the variable can only be used in a run-time filter.
Hence you need to call smoothlevels inside ScriptClip:
ConditionalReader("b:\output.txt", "avgluma")
ScriptClip("smoothlevels(0,1.6-0.006*avgluma,255,0,255,BrightSTR=7000,smode=0)", after_frame=true)

Also, are you setting "TYPE float" in your file?

Found sh0dan modified AGC averageluma version, not yet fully understand how it works
It doesn't work. :(
That function is broken following sh0dan's optimisation - the variable 'filterme' needs to be global.
Ironically, none of the existing globals are necessary.

Here is a working (+ cleaned-up and further optimised) version.
function AGC (clip c, int "mode",float "multiplier", float "gamma",
\ int "radius",int "scenechange", bool "luma")
{
radius = default(radius,4)
scenechange = default(scenechange,20)
multiplier = default(multiplier,.96)
gamma = default(gamma,1)
mode= default(mode, 2)
luma = default(luma,true)

multiplier = (mode==2) ? float(multiplier*2) : float(multiplier)

method = (mode==1)? "averageluma(filterme)" :
\ (mode==2)? "YplaneMax(filterme)" : "YplaneMedian(filterme)"

global filterme = c.deleteframe(0).reduceby2().reduceby2().
\ temporalsoften(radius,255,255,scenechange,2).
\ levels(0,gamma,255,0,255,coring=false)

luma ? c.scriptclip("coloryuv(gain_y=round(gl_lum * 256)-256)") :
\ c.converttorgb32().scriptclip("RGBadjust(gl_lum,gl_lum,gl_lum,0)").converttoyv12()

frameevaluate("gl_lum = "+string(multiplier*128)+" / (" + method + ")")
}
The need for filterme to be global can be removed if you use GRunT - you would then add args="filterme" to the frameevaluate call. Indeed, it could then also be tidied further to
frameevaluate("gl_lum = multiplier*128) / (" + method + ")", args="multiplier, filterme")

Note: the reason to avoid globals is not simply a stylistic one - they stop the function working properly if it is used more than once in a script.

[Ponder]

@Gavino
That doesn't look right.
Pixels outside of 22-239 are counted as 128?

You are absolutely right. I was too quick to think your 4 lines "used together"

mask = mt_lut(expr=mt_polish("x > 21 & x < 240 ? 255 : 0"))
masked = mt_lut(expr=mt_polish("x > 21 & x < 240 ? x : 0"))
a = AverageLuma(mask)
ravl = a > 0 ? 255*AverageLuma(masked)/a : 0

is mathematically equivalent to these 2 lines "used together"

refine_luma=mask1.mt_lut(expr=mt_polish("x > 21 & x < 240 ? x : 128"))
ravl=AverageLuma(refine_luma)

base on the line of thinking when making a pixel 255 will make it the brightest, 0 to make it the
darkest, then the middle 128 must equate to zero effect ="ignore such pixel" during an average
caculation. ie. When the average of a sample is known,any "new" members( pixels) whose value equal
to the "average" added to the sample to recalculate an average will not affect its outcome.

It is clear the source luma average is not 128 in practical case, but true only in theory at best.
It needed to be calculated first for every frame, and the pixels are not new either.

Kind of x-y axis bias, the middle is (0,0) or neutral. thus the middle value 128=neutral=zero
influences in an "averaging scenerio". The fun part was that during a quick browsing through Doom9,
read Didee commented on some clips filtering:

...Clip A minus clip B, all result are 128... meaning filter did nothing..
so I tried subtract(last,last) to verify...get all 128s.. Now my 128 = nothingness bias is really
deepen :-). From that line of thinking, new law should probably made such that all items on Amazon
=$128 should be free too. :-)

If someone ask me now what is 1 Commodore 64 + 1 Commodore 64?, my answer will definitely be one
Commodore 128. However, yesterday, I probably said Commodore Zero.

Will digest the script and learn something. Thanks again.

[Ponder]

@Gavino,

"Also, are you setting "TYPE float" in your file?"
Yes I did, after a 1st write. I add "TYPE float" to the header. But something broken at my side,
"output.txt" look like this
type float
86.263542 ---> this line is wrong 1st line, "not" in ColorYUV(Analyze=True)
46.263542 ---> this is right 1st line, in ColorYUV(Analyze=True)
46.263542
46.258179
46.235474
46.203499
The data seems valid, most lines.

If I ConditionalReader the file, ConditionalReader("b:\output.txt", "avgl", show=true)
it read some random no. all of them are 0.xxxxxx ie less than 1. Still investigating

Does ConditionalRead & write allow write 1st line, then read 1st line immediately right after
and put it in
ScriptClip("smoothlevels(0,1.6-0.006*avgluma,255,0,255,BrightSTR=7000,smode=0)", after_frame=true)?

sh0dan modified AGC flashed "ie. wrong luma used" at start of all scene changes. the fixed one flash
at end of all scene changes. Probably hard to fix due to temporalsoften(radius,255,255,scenechange,2)

Revisit:
"That doesn't look right. Pixels outside of 22-239 are counted as 128?"

Hate to see good thing goes wasted :-)
Today, I discovered a few very interest things after extensive tests on very bright, dark,
very high, low contrast and normal scenes on Aeon Flux; tons of extreme color variation scenes.

I was kind of surprise to see ("x > 21 & x < 240 ? x : 128") normalized the pictures well.
so with some more tests, changing mt_lut(expr=mt_polish("x > 21 & x < 240 ? x : 128"))
to mt_lut(expr=mt_polish("x > 21 & x < 195 ? x : 99")) pick 99, it looks so much better.

Reason goes like this:
Imagine this, a 1920x hdtv TV show clip ends, a SDTV commercial (seen alot) with thick 240 black
pixels at each sides starts, since commercials are by nature very bright, a variable gamma control
Levels() will be influenced by these 2 thick blocks of pixels with value < 16, the Levels() will
bright up the SDTV commercial to crazily bright. Some SDTV commercial even have additional 120 top
and bottom black block, brightness go nut...

My original goal (1st post) was "Do not let "very" dark or bright objects (especially big ones)
to fool the levels() functions to misinterpret normal scenes as dark or bright scenes.
mt_lut(expr=mt_polish(("x > 16 ? x : 128")) cures the above problem. The assignment of pixels
0->16 to 128 is like telling Levels(), heys, these black blocks do not exist, they are "normal",
"middle 128" value, don't let them fool you to brighten other parts of the frame. In real world,
TV, 'Movies, pixel value 80->105 are likely "more middle" in most frames, thus truer average.

So mt_lut(expr=mt_polish(("x > 16 ? x : 90ish")) is better than 128ish. ie.real life luma average.
By the same logic, don't wanted Levels() to be fool by very bright objects -->
mt_lut(expr=mt_polish(("x > 16 & x < 240 ? x : 90ish"))

with some real world tests, try this mt_lut(expr=mt_polish("x > 21 & x < 195 ? x : 99"))
It gave very good viewing result, on all Aeon Flux Clips:

What if you want big dark block scenes brighten, the varying gamma and Darkstr do their work
nicely already, while refined luma kill the darkest and brightess type problems.

When you said "That doesn't look right. Pixels outside of 22-239 are counted as 128?" I kind of
forget my original goal and focus on all the syntaxs new to me, that line did look out of whack
by itself, in this case, to refine the luma average, it works as intended. Look like it is only
the Levels() function gets fooled, I was fooled more than you did, because I defined the goal,
and in half way kind of forget this.

To compare:
mask = mt_lut(expr=mt_polish("x > 21 & x < 220 ? 255 : 0")) # method 1,theoretically accurate
masked = mt_lut(expr=mt_polish("x > 21 & x < 220 ? x : 0")) # as my original intend, help by Gavino

m1 = mt_lut(expr=mt_polish("x > 21 & x < 195 ? x : 99"))# method 2, pick a normal scene and luma

average visually from the video interested. eg. 80-105, not 128 (theoretical mean), as I chosed
before. Or 2 more ways to calculate this. Write a scriptClip to get an luma average of the whole
video, eg. choose every 300 frames, 2000 frames.. can be bias for short clips, or
assign_luma_avg =(1.6-1.00) / 0.006 =100 here #1.00 since flat gamma is wanted for bright scene.

ScriptClip("""
a = AverageLuma(mask)
ravl = a > 0 ? 255*AverageLuma(masked)/a : 0
smoothlevels(0,1.6-0.006*ravl,255,0,255,darkSTR=17,BrightSTR=7000,smode=0)
diff=ravl-AverageLuma(m1) #test
Subtitle(String(AverageLuma(m1)/ravl)) #test
#Subtitle(String(diff))
""")

comparings both Methods:
stackhorizontal(last,ScriptClip("smoothlevels(0,1.6-0.006*AverageLuma(m1),255,0,255,darkSTR=17,BrightSTR=7000,smode=0)"))

observations: Method 1, better contrast, excellent at normal and bright scenes,good at
dark scenes. Method 2, excellent at normal and dark scenes, good at bright scenes, it always
normalize more by its nature.

Both methods look great given all these controls. Will use contrast from frame to control gamma and
brightness later. But I need ChromaU,V average min max YplaneMedian Max... to test as well some
others brewing ideas I am having.

[Dogway]

Is this like some kind of advanced dynamic contrast?
Also if this is used on video, shouldnt be treated as in TV levels?

[Gavino]

"output.txt" look like this
type float
86.263542 ---> this line is wrong 1st line, "not" in ColorYUV(Analyze=True)
46.263542 ---> this is right 1st line, in ColorYUV(Analyze=True)
...
If I ConditionalReader the file, ConditionalReader("b:\output.txt", "avgl", show=true)
it read some random no. all of them are 0.xxxxxx ie less than 1.
Each line of the file needs to start with the frame number. See ConditionalReader (http://avisynth.org/mediawiki/ConditionalReader) docs.
I expect it is taking 46 as the frame number and returning .263542 as the value of the variable.
As for the wrong first line, how are you creating the file? What is your script?

Does ConditionalRead & write allow write 1st line, then read 1st line immediately right after
and put it in
ScriptClip("smoothlevels(0,1.6-0.006*avgluma,255,0,255,BrightSTR=7000,smode=0)", after_frame=true)?
It depends how you do the writing.
WriteFileStart closes the file on each write so it should allow a later read. With plain WriteFile, you can use flush=true to force this behaviour. However, WriteFile does its work 'per-frame' during frame serving so you can't use it to write the entire file before starting to read it.

sh0dan modified AGC flashed "ie. wrong luma used" at start of all scene changes. the fixed one flash at end of all scene changes.
Is this message something you have put in your script or does it come from one of the internal filters?

[Ponder]

@Dogway
Is this like some kind of advanced dynamic contrast?
Seeing refined luma already helps a ton on too dark, too bright , fake dark scenes: SDTV
commercial; someone walk across or toward a camera or lights scenerio". Or fake bright scenerio,
when beam of light on someone face, infact anywhere; or dancing scenes in Chicago, Moulin Rough,
bright lights jump all over the places on dancers. The idea is perhaps to extend it to a
"refined contrast average" to guide levels() functions to start in a right direction. The
improvement will likely be much less dramatic than from "refined luma average"

So far I am very pleased many problematic scenerios faced by the old autolevel are fixed by
the goal of refined luma average. Now SDTV commercial wont ruin my viewing.

Very likely, leapfrog improvement of scene detection algorithm in these cases can be achieved
here, since "movements" of bright lights or dark objects kill scene detections in Virtualdub
easily, likely in other scene detection plugins as well, but I haven't use scene detections yet,
so someone has to test it out. We should ask Avery Lee to test it out :-) so we can all find
scene changes (scroll) much better in stead of every couple of frames search will end in a screen
pause (ie. fake scene change spotted) in these common yet difficult scenes.

Also if this is used on video, shouldnt be treated as in TV levels?

It has nothing to do with TV <--> PC conversion, refined luma is meant to improve the atmosphere,
mood, of the whole clip to your personal taste meanwhile avoid other pitfalls.

[Ponder]

@Gavino

Each line of the file needs to start with the frame number

But When I used this
WriteFile(filename,"current_frame","AverageLuma")

it wrote this
046.263542 all correct values ,except with no space between "current_frame","AverageLuma"
146.263542
246.263542
346.258179
446.235474
546.203499
646.172165
746.202290
846.258835
946.271378
1046.276028
1146.251068
1246.247154

so I used WriteFile(filename,"AverageLuma") # without "current_frame" to single out AverageLuma
46.263542 now show correct values
46.263542
46.263542
46.258179
46.235474

Next, I manually add the header "type float" or else
ConditionalReader("b:\output.txt","AverageLuma", show=true) refuse to read. It did not simple
truncate as thought, else easy to spot. because the values shown from

frame 0 to 2 show on virtualdub are not 0.263542,0.263542,0.263542, but 0.xxxxxx all random.
The truncated 0.xxxxxx. They are likely from frame 046,146, 246, 346... To make matter worse,

Some of luma average written to the files came from no where, I realize later during browsing,
click here and there, scroll the script, or F5 to refresh, luma average from all these frames
will be included in the output files as well. Only a fresh open file from virtualdub will make
WriteFile to start from frame 0 and onward. It drove me nut pass few days before figuring it
out.

Is it a bug? I am using win2k.

Finally, have to pair this to make it work
WriteFile(filename,"current_frame",""" " " ""","AverageLuma")
ConditionalReader("b:\output.txt","AverageLuma", show=true) to get this

0 46.263542
1 46.263542
2 46.263542
3 46.258179
4 46.235474
5 46.203499
6 46.172165
7 46.202290
8 46.258835
9 46.271378
10 46.276028
11 46.251068
12 46.247154

[Dogway]

what I mean is that, you are raising/lowering gamma based on black is 0, and white 255 in a more than probably YUV video source where black is 16 and white 235.
If you raise gamma from 0, yuv black value of 16 will also be raised, (same for white) is this correct?

[Ponder]

@Dogway

For the same material, DGDecode, MPEG2Dec3 decode to yv12, while ffmpeg tend to output YUV,
dont know who is right or why. ffmpeg is not stable at my side, so I use DGDecode, hence get yv12
, I dont have have much experience or knowledge on YUV in this respect. Maybe run 2 tests on same
the file ,but convert to these 2 colorspaces before encoding, and then stackhoriz both clips to
visualize the differences. The accruate technical scaling or conversion is beyond my present
knowledge.

[Ponder]

@Gavino
sh0dan modified AGC flashed "ie. wrong luma used" at start of all scene changes. the fixed one flash at end of all scene changes.

Is this message something you have put in your script or does it come from one of the internal filters

"wrong luma used" was an observation, AGC function picked luma either from previous or next
frame and apply it to current frame, at scene change, luma average can differ a lot, so cause
one flame flash at all scene changes.

I hope avisynth developers can find some time to patch all these colorYUV variables, luma average,
min max, medians etc. I have some good ideas using them to enhance scene detection algorithm in
avisynth. What do you think? :)

[leeperry]

1.27 gamma on a perfectly D65/2.4 calibrated display? sounds too me like you're trying to fix a calibration deficiency.

[Ponder]

@leeperry

Comedies are bright,so gamma are 1.0, some other are dark, hence 1.27 and vary. :-)