SweetFX Video Shaders [Archive]

View Full Version : SweetFX Video Shaders

Pages : [1] 2

CeeJay.dk

16th March 2014, 16:41

On request I have ported over all the shaders from SweetFX (http://forums.guru3d.com/showthread.php?t=381912)so that they can now run in MPC-HC (http://mpc-hc.org/).

Download mirrors:

Ge.tt (http://ge.tt/64SMJpf/v/61)
Dropbox (https://www.dropbox.com/s/5eum2ry58o0gy7o/SweetFX%20Video%20Shaders.7z)
Dropcanvas (http://dropcanvas.com/l46x9/29)

Instructions
1) Install the latest MPC-HC (http://mpc-hc.org/) - you will need at least version 1.7.2 (current version as I write this is 1.7.3)
2) Extract the shaders to the Shaders folder in the MPC-HC folder.
3) You can edit settings in the .hlsl files you just extracted.

I assume you know how to add and enable shaders in MPC-HC.

I'd make editing the settings easier if I could but MPC-HC doesn't have an interface for editing shader settings.

This is the first release, and I haven't taken the time to tweak the default settings so they are more suited for watching videos - if you find some better default settings please suggest them to me so I can update the shader package.

All of the code for the effect follows the settings, but in the next version I'll probably separate them and just use a template to include the code from the untouched SweetFX shader in the SweetFX package for games as this makes porting over new versions of the effect a simple drag and drop of the new file so I don't have to port it again.

raffriff42

16th March 2014, 17:08

Sweet, thanks! But nothing happens when I click on "download" :o

I'm on FF27.01 if that matters.NoScript? :p

CeeJay.dk

16th March 2014, 17:54

I disabled Ghostery, enabled Flash and that didn't help.

Adblock Plus mistakenly classifies ge.tt as a malware domain if you have the malware list enabled.

I'll try to host it some other places as well.

CeeJay.dk

16th March 2014, 18:11

I don't use Adblock, mediafire or mega would be great :)

It's also up on dropcanvas and dropbox now. I hope one of them works for you.

leeperry

16th March 2014, 23:33

That did the trick, thanks!

Vignette is fun and Borders is useful to hide TV channel logos :)

They work just fine in PotPlayer BTW.

CeeJay.dk

17th March 2014, 00:07

Nice, I was going to look into porting them to the other shader capable media players next but that is one crossed off my list then.

I'm looking forward to hearing feedback on the shaders from this forum .. lots of people here that know much more about video filters than myself.

JanWillem32

17th March 2014, 02:49

I can perhaps help with some parts. To start off with one shader, for the DPX shader I see that you've tried to use the XYZ color space. The XYZ color space is the both the easiest and the hardest color space to manipulate. It demands linear light input, and also filters in linear light mode. That means that it's great for linear scaling, but will not work for any filter that expects non-linearity at all. It's also all-positive, and can encode all colors in the human-visable spectrum. The down-side to that is that it also encodes non-existing colors (which are actually not that hard to deal with).
Assuming R'G'B' input, the first conversion step is done by converting R'G'B' to RGB: "s1 = sign(s1)*pow(abs(s1), 2.4);// to linear RGB, negative input compatible". (The pow instructions will produce a NaN on all negative inputs. This method isn't the cleanest way to deal with exponentiation, but it does the job.) Note the standard 2.4 factor. This is correct for all consumer-grade digital video. For some reason the standards do specify all sorts of weird OECF formats, but those are usually not even close to the image reproduction reference.
After converting to RGB, you can convert to XYZ by matrix multiplication. There are four matrices in use for consumer-grade digital video (see code box at the bottom of this post). The line "c0 = mul(XYZ, c0);" as already in the shader will work fine, but breaking it up into multiply-add operations may be faster. (To try that: transpose() the matrix, use "s1 = s1.x*matrix[0]+s1.y*matrix[1]+s1.z*matrix[2];" and read the report from GPU ShaderAnalyzer or similar to determine if it's faster.)
Note that conversion to plain XYZ will yield a color space based on white point E. This means that the input white point will not be {1, 1, 1} on output when using these (unless the input white point was already E, but that's not the case for consumer-grade digital video). There are also white-point adapted matrices, that will fully or partially adapt the input white point. Different methods of these will yield different XYZ conversion matrices.
The line "float luma = dot(c0, float3(0.30, 0.59, 0.11)); //Use BT 709 instead?" is odd. XYZ doesn't describe luma at all. It does store luminance in the Y channel. If you denormalize the Y channel you actually get values expressed in cd/m². Of course it's linear-light, and if you scale Y, you have to scale X and Z as well. XYZ is mostly good at encoding color, but not so much at describing it. Scaling in XYZ works fine, as long as you scale the three channels with the same factor. For describing actual color, by all means look beyond Y'CbCr, R'G'B', HSV, HSL, RGB and XYZ for a CAM (color appearance model). I achieved good results with CIECAM02 and at the moment I'm testing XLRCAM. These do specify lots of conversions and parameters to deal with, but these are totally worth it.

Some technical issues:
-"static float3x3 RGB" and "static float3x3 XYZ" are not marked const, even though their intention is so.
-"float4 DPXPass(float4 InputColor){" in this case it won't be a problem, but the compiler is horrible at inlining functions (even using a #define as a function will usually optimize better).
-As I already noted, check the usage of mul() intrinsics, as the compiler generally won't optimize by multiplying matrices with consecutive scalars and vectors.
-As I already noted, check the usage of pow() intrinsics where negative inputs can be expected, as NaN outputs will cause artifacts.

The notes that I made to construct the basis XYZ and LMS matrices:BT.709 RGB to XYZ matrix
506752./1228815., 87881./245763., 12673./70218.,
87098./409605., 175762./245763., 12673./175545.,
7918./409605., 87881./737289., 1001167./1053270.
BT.709 RGB to LMS matrix
722868859153469683239595115393861./2255010826531620584211453297294600., 2585192674261804536498018473512337./4059019487756917051580615935130280., 431657167547167713128315634772483./10147548719392292628951539837825700.,
12180008436477856247752895389891./75167027551054019473715109909820., 307102197566215335489903665465341./405901948775691705158061593513028., 82569264131239864825730732355689./1014754871939229262895153983782570.,
53058419719444384066923671296./3075014763452209887561072678129., 111365697442061984458791034130./1025004921150736629187024226043., 2687859251406579550117775904443./3075014763452209887561072678129.
LMS to BT.709 RGB matrix
25377313278362757037750367./4668794666720483257968250., -214723657934986669707431539./46687946667204832579682500., 7638471818563931909610369./46687946667204832579682500.,
-605343464019237999732424841./518184319406495060865758750., 12063681187144308402184664197./5181843194064950608657587500., -828403352886977796202828287./5181843194064950608657587500.,
396581977151187822859327./10461567155328133121940425., -20775485687965286836237859./104615671553281331219404250., 121425337469734739827048839./104615671553281331219404250.

SMPTE 170M/SMPTE 240M/SMPTE C (NTSC) RGB to XYZ matrix
401584./932715., 2548549./7461720., 88721./497448.,
276089./1243620., 87881./124362., 88721./1243620.,
25099./1243620., 966691./7461720., 7008959./7461720.
SMPTE 170M/SMPTE 240M/SMPTE C (NTSC) RGB to LMS matrix
4582795022958559125948622834369921./13693077790023334631838222431764800., 465527727195754310063646435959647./746895152183090979918448496278080., 431705826356959866042061203601013./10269808342517500973878666823823600.,
77217992358463681223124506539751./456435926334111154394607414392160., 56048129428711216246386203396963./74689515218309097991844849627808., 82578571800427591248026245959679./1026980834251750097387866682382360.,
42047021865948932675414158432./2334047350572159312245151550869., 1103514589028385241176926280029./9336189402288637248980606203476., 2688162241932152092367341096573./3112063134096212416326868734492.
LMS to SMPTE 170M/SMPTE 240M/SMPTE C (NTSC) RGB matrix
763198626475360358257813253./147994540717374853866816250., -6373975142277374689886058001./1479945407173748538668162500., 221934284697519645976087971./1479945407173748538668162500.,
-605343464019237999732424841./518184319406495060865758750., 12063681187144308402184664197./5181843194064950608657587500., -828403352886977796202828287./5181843194064950608657587500.,
27361298410291889828212027./523137322083995952425108750., -1196635193693957989329923759./5231373220839959524251087500., 6154395430430998615298890989./5231373220839959524251087500.

BT.470-2 System M RGB to XYZ matrix
43349./71416., 12387./71416., 3581./17854.,
21351./71416., 293159./499912., 7162./62489.,
0., 4129./62489., 139659./124978.
BT.470-2 System M RGB to LMS matrix
4849241781348846485632006241./10503846560761984531342857600., 34978470582276588065997919961./73526925925333891719400003200., 35966897450120142609203434./574429108791671029057812525.,
1160596510009705046375091833./5251923280380992265671428800., 24013221393818167547899894193./36763462962666945859700001600., 72282281230950671674601009./574429108791671029057812525.,
-76116568237764117836011./65649041004762403320892860., 25082445529946839408599149./459543287033336823246250020., 108748414370263583165625737./114885821758334205811562505.
LMS to BT.470-2 System M RGB matrix
6356039832931337684547833./1907495674013736213630625., -9291369607363479369136241./3814991348027472427261250., 15771251581131057092073./152599653921098897090450.,
-13887055372386146338232481./12173183366310226933664375., 57992533744044875121627737./24346366732620453867328750., -234882250666085143113361./973854669304818154693150.,
737565350893551523311808./10557561064363507544066875., -1481563549980151961947408./10557561064363507544066875., 452062370538004319308099./422302442574540301762675.

BT.470-2 System B,G/EBU 3213 (PAL/SECAM) RGB to XYZ matrix
51177./130049., 4987652./13655145., 5234753./27310290.,
82858./390147., 1367582./1950735., 168863./1950735.,
2437./130049., 1528474./13655145., 5234753./5462058.
BT.470-2 System B,G/EBU 3213 (PAL/SECAM) RGB to LMS matrix
782910914364235953227073443841197./2505869460647788817876743483379180., 47437201892727083793508359035427793./75176083819433664536302304501375400., 4251554495779502145981742150711697./75176083819433664536302304501375400.,
124459316400474051550350235432343./751760838194336645363023045013754., 5551656166817314597571817932574949./7517608381943366453630230450137540., 240453017040437113518303387746387./2505869460647788817876743483379180.,
190503071007861562472684780870./11390315730217221899439743106269., 3484707111371743136520220253336./34170947190651665698319229318807., 30114730866256337874380954722861./34170947190651665698319229318807.
LMS to BT.470-2 System B,G/EBU 3213 (PAL/SECAM) RGB matrix
5889610677243193337436144851./1005872293755806060844662500., -50563246336667155788637763367./10058722937558060608446625000., 1725862501793283022722939857./10058722937558060608446625000.,
-156299752813513892312443129./118586087319713310233175625., 2972168594434151167364839293./1185860873197133102331756250., -223310193101879141908651753./1185860873197133102331756250.,
41217384068187972753550441./995689156108134584983951250., -1937830199233462093713839397./9956891561081345849839512500., 11482547919632928216017847487./9956891561081345849839512500.

JanWillem32

17th March 2014, 02:49

used tools:
(construct the RGB to XYZ matrices first)
matrix math

BT.709 RGB to XYZ matrix
{{506752./1228815., 87881./245763., 12673./70218.},
{87098./409605., 175762./245763., 12673./175545.},
{7918./409605., 87881./737289., 1001167./1053270.}}
XYZ_w
{{3127/3290},{1},{3583/3290}}
iLMSCAT02_w
{{3903713/4112500},{34064741/32900000},{4472059/4112500}}
iLMSCAT02_wr
{{4112500/3903713},{32900000/34064741},{4112500/4472059}}
{{4112500/3903713,0,0},
{0,32900000/34064741,0},
{0,0,4112500/4472059}}
// white point adaptation and LMSCAT02 to XYZ to LMS
{{464053391886875/594479206165966,546172937177000/2593784454432131,25677829793875/681030107553338},
{89354738755625/297239603082983,1563686005000000/2593784454432131,28321738606875/340515053776669},
{-274069337500/27021782098453,-14274125600000/2593784454432131,317936256400000/340515053776669}}
// XYZ to LMSCAT02, white point adaptation and LMSCAT02 to XYZ to LMS
{{1535883035237967283712368316373/3622507351858025034877836622160,313936929155525071434095214423/452813418982253129359729577770,-320255941654937541603650371757/3622507351858025034877836622160},
{-73765545839823421271159289111/362250735185802503487783662216,52237841914778168455574637779/45281341898225312935972957777,13276522859463209890873256879/362250735185802503487783662216},
{-3125719934910748888276760/4116485627111392085088450707,-4119398094368106819832290/4116485627111392085088450707,3786370264907456584747946550/4116485627111392085088450707}}
// RGB to XYZ to LMSCAT02, white point adaptation and LMSCAT02 to XYZ to LMS
{{722868859153469683239595115393861/2255010826531620584211453297294600,2585192674261804536498018473512337/4059019487756917051580615935130280,431657167547167713128315634772483/10147548719392292628951539837825700},
{12180008436477856247752895389891/75167027551054019473715109909820,307102197566215335489903665465341/405901948775691705158061593513028,82569264131239864825730732355689/1014754871939229262895153983782570},
{53058419719444384066923671296/3075014763452209887561072678129,111365697442061984458791034130/1025004921150736629187024226043,2687859251406579550117775904443/3075014763452209887561072678129}}
// reverse
{{25377313278362757037750367/4668794666720483257968250,-214723657934986669707431539/46687946667204832579682500,7638471818563931909610369/46687946667204832579682500},
{-605343464019237999732424841/518184319406495060865758750,12063681187144308402184664197/5181843194064950608657587500,-828403352886977796202828287/5181843194064950608657587500},
{396581977151187822859327/10461567155328133121940425,-20775485687965286836237859/104615671553281331219404250,121425337469734739827048839/104615671553281331219404250}}

SMPTE 170M/SMPTE 240M/SMPTE C (NTSC) RGB to XYZ matrix
{{401584./932715., 2548549./7461720., 88721./497448.},
{276089./1243620., 87881./124362., 88721./1243620.},
{25099./1243620., 966691./7461720., 7008959./7461720.}}
XYZ_w
{{3127/3290},{1},{3583/3290}}
iLMSCAT02_w
{{3903713/4112500},{34064741/32900000},{4472059/4112500}}
iLMSCAT02_wr
{{4112500/3903713},{32900000/34064741},{4112500/4472059}}
{{4112500/3903713,0,0},
{0,32900000/34064741,0},
{0,0,4112500/4472059}}
// white point adaptation and LMSCAT02 to XYZ to LMS
{{464053391886875/594479206165966,546172937177000/2593784454432131,25677829793875/681030107553338},
{89354738755625/297239603082983,1563686005000000/2593784454432131,28321738606875/340515053776669},
{-274069337500/27021782098453,-14274125600000/2593784454432131,317936256400000/340515053776669}}
// XYZ to LMSCAT02, white point adaptation and LMSCAT02 to XYZ to LMS
{{1535883035237967283712368316373/3622507351858025034877836622160,313936929155525071434095214423/452813418982253129359729577770,-320255941654937541603650371757/3622507351858025034877836622160},
{-73765545839823421271159289111/362250735185802503487783662216,52237841914778168455574637779/45281341898225312935972957777,13276522859463209890873256879/362250735185802503487783662216},
{-3125719934910748888276760/4116485627111392085088450707,-4119398094368106819832290/4116485627111392085088450707,3786370264907456584747946550/4116485627111392085088450707}}
// RGB to XYZ to LMSCAT02, white point adaptation and LMSCAT02 to XYZ to LMS
{{4582795022958559125948622834369921/13693077790023334631838222431764800,465527727195754310063646435959647/746895152183090979918448496278080,431705826356959866042061203601013/10269808342517500973878666823823600},
{77217992358463681223124506539751/456435926334111154394607414392160,56048129428711216246386203396963/74689515218309097991844849627808,82578571800427591248026245959679/1026980834251750097387866682382360},
{42047021865948932675414158432/2334047350572159312245151550869,1103514589028385241176926280029/9336189402288637248980606203476,2688162241932152092367341096573/3112063134096212416326868734492}}
// reverse
{{763198626475360358257813253/147994540717374853866816250,-6373975142277374689886058001/1479945407173748538668162500,221934284697519645976087971/1479945407173748538668162500},
{-605343464019237999732424841/518184319406495060865758750,12063681187144308402184664197/5181843194064950608657587500,-828403352886977796202828287/5181843194064950608657587500},
{27361298410291889828212027/523137322083995952425108750,-1196635193693957989329923759/5231373220839959524251087500,6154395430430998615298890989/5231373220839959524251087500}}

BT.470-2 System M RGB to XYZ matrix
{{43349./71416., 12387./71416., 3581./17854.},
{21351./71416., 293159./499912., 7162./62489.},
{0., 4129./62489., 139659./124978.}}
XYZ_w
{{155/158},{1},{187/158}}
iLMSCAT02_w
{{37773/39500},{1602877/1580000},{233137/197500}}
iLMSCAT02_wr
{{39500/37773},{1580000/1602877},{197500/233137}}
{{39500/37773,0,0},
{0,1580000/1602877,0},
{0,0,197500/233137}}
// white point adaptation and LMSCAT02 to XYZ to LMS
{{4457169356725/5752283288886,26229581785400/122047528409707,1233160215025/35503403730734},
{858240043975/2876141644443,75094951000000/122047528409707,1360132127625/17751701865367},
{-28956383500/2876141644443,-685505120000/122047528409707,15268671280000/17751701865367}}
// XYZ to LMSCAT02, white point adaptation and LMSCAT02 to XYZ to LMS
{{4841799350800837556394979/11619299292878301472724400,169003540689637258532741/242068735268297947348425,-1050013174810519557556547/11619299292878301472724400},
{-1243396960144830232381973/5809649646439150736362200,284114598684068163097666/242068735268297947348425,178013982619508170577989/5809649646439150736362200},
{-122785085978668174408/145241241160978768409055,-104660313950594725082/48413747053659589469685,123084260858684068852154/145241241160978768409055}}
// RGB to XYZ to LMSCAT02, white point adaptation and LMSCAT02 to XYZ to LMS
{{4849241781348846485632006241/10503846560761984531342857600,34978470582276588065997919961/73526925925333891719400003200,35966897450120142609203434/574429108791671029057812525},
{1160596510009705046375091833/5251923280380992265671428800,24013221393818167547899894193/36763462962666945859700001600,72282281230950671674601009/574429108791671029057812525},
{-76116568237764117836011/65649041004762403320892860,25082445529946839408599149/459543287033336823246250020,108748414370263583165625737/114885821758334205811562505}}
// reverse
{{6356039832931337684547833/1907495674013736213630625,-9291369607363479369136241/3814991348027472427261250,15771251581131057092073/152599653921098897090450},
{-13887055372386146338232481/12173183366310226933664375,57992533744044875121627737/24346366732620453867328750,-234882250666085143113361/973854669304818154693150},
{737565350893551523311808/10557561064363507544066875,-1481563549980151961947408/10557561064363507544066875,452062370538004319308099/422302442574540301762675}}

BT.470-2 System B,G/EBU 3213 (PAL/SECAM) RGB to XYZ matrix
{{51177./130049., 4987652./13655145., 5234753./27310290.},
{82858./390147., 1367582./1950735., 168863./1950735.},
{2437./130049., 1528474./13655145., 5234753./5462058.}}
XYZ_w
{{3127/3290},{1},{3583/3290}}
iLMSCAT02_w
{{3903713/4112500},{34064741/32900000},{4472059/4112500}}
iLMSCAT02_wr
{{4112500/3903713},{32900000/34064741},{4112500/4472059}}
{{4112500/3903713,0,0},
{0,32900000/34064741,0},
{0,0,4112500/4472059}}
// white point adaptation and LMSCAT02 to XYZ to LMS
{{464053391886875/594479206165966,546172937177000/2593784454432131,25677829793875/681030107553338},
{89354738755625/297239603082983,1563686005000000/2593784454432131,28321738606875/340515053776669},
{-274069337500/27021782098453,-14274125600000/2593784454432131,317936256400000/340515053776669}}
// XYZ to LMSCAT02, white point adaptation and LMSCAT02 to XYZ to LMS
{{1535883035237967283712368316373/3622507351858025034877836622160,313936929155525071434095214423/452813418982253129359729577770,-320255941654937541603650371757/3622507351858025034877836622160},
{-73765545839823421271159289111/362250735185802503487783662216,52237841914778168455574637779/45281341898225312935972957777,13276522859463209890873256879/362250735185802503487783662216},
{-3125719934910748888276760/4116485627111392085088450707,-4119398094368106819832290/4116485627111392085088450707,3786370264907456584747946550/4116485627111392085088450707}}
// RGB to XYZ to LMSCAT02, white point adaptation and LMSCAT02 to XYZ to LMS
{{782910914364235953227073443841197/2505869460647788817876743483379180,47437201892727083793508359035427793/75176083819433664536302304501375400,4251554495779502145981742150711697/75176083819433664536302304501375400},
{124459316400474051550350235432343/751760838194336645363023045013754,5551656166817314597571817932574949/7517608381943366453630230450137540,240453017040437113518303387746387/2505869460647788817876743483379180},
{190503071007861562472684780870/11390315730217221899439743106269,3484707111371743136520220253336/34170947190651665698319229318807,30114730866256337874380954722861/34170947190651665698319229318807}}
// reverse
{{5889610677243193337436144851/1005872293755806060844662500,-50563246336667155788637763367/10058722937558060608446625000,1725862501793283022722939857/10058722937558060608446625000},
{-156299752813513892312443129/118586087319713310233175625,2972168594434151167364839293/1185860873197133102331756250,-223310193101879141908651753/1185860873197133102331756250},
{41217384068187972753550441/995689156108134584983951250,-1937830199233462093713839397/9956891561081345849839512500,11482547919632928216017847487/9956891561081345849839512500}}

preccalc64.exe
construct the RGB to XYZ matrices

/*
// these are for SMPTE 170M/SMPTE 240M/SMPTE C (NTSC)
ix_r = .63;
iy_r = .34;
ix_g = .31;
iy_g = .595;
ix_b = .155;
iy_b = .07;
ix_w = .3127;
iy_w = .329;
*/
/*
// these are for BT.470-2 System M
ix_r = .67;
iy_r = .33;
ix_g = .21;
iy_g = .71;
ix_b = .14;
iy_b = .08;
ix_w = .31;
iy_w = .316;
*/
/*
// these are for BT.470-2 System B,G/EBU 3213 (PAL/SECAM)
ix_r = .64;
iy_r = .33;
ix_g = .29;
iy_g = .6;
ix_b = .15;
iy_b = .06;
ix_w = .3127;
iy_w = .329;
*/
// these are for BT.709
ix_r = .64;
iy_r = .33;
ix_g = .3;
iy_g = .6;
ix_b = .15;
iy_b = .06;
ix_w = .3127;
iy_w = .329;

X_r = ix_r / iy_r;
Z_r = (1. - ix_r - iy_r) / iy_r;
X_g = ix_g / iy_g;
Z_g = (1. - ix_g - iy_g) / iy_g;
X_b = ix_b / iy_b;
Z_b = (1. - ix_b - iy_b) / iy_b;
X_w = ix_w / iy_w;
Z_w = (1. - ix_w - iy_w) / iy_w;

Mdetr = 1. / (X_r * (Z_b - Z_g) - X_g * (Z_b - Z_r) + X_b * (Z_g - Z_r));
S_r = (X_w * (Z_b - Z_g) + X_b * Z_g - X_g * Z_b + Z_w * (X_g - X_b)) * Mdetr;
S_g = (X_w * (Z_r - Z_b) + X_r * Z_b - X_b * Z_r + Z_w * (X_b - X_r)) * Mdetr;
S_b = (X_w * (Z_g - Z_r) + X_g * Z_r - X_r * Z_g + Z_w * (X_r - X_g)) * Mdetr;

MX_r = S_r * X_r;
MX_g = S_g * X_g;
MX_b = S_b * X_b;
MY_r = S_r;
MY_g = S_g;
MY_b = S_b;
MZ_r = S_r * Z_r;
MZ_g = S_g * Z_g;
MZ_b = S_b * Z_b;

print MX_r, ",", MX_g, ",", MX_b, ",", MY_r, ",", MY_g, ",", MY_b, ",", MZ_r, ",", MZ_g, ",", MZ_b;

turbojet

17th March 2014, 07:13

Thanks CeeJay.dk, I have a few questions about lumasharpen:

1. Is the lumasharpen you posted the same as v1.41 in my signature?
2. What allows pattern 3 to use very high strength with very few artifacts while the other patterns have all sort of artifacts? Is it taps?
3. Do all of your scripts have versions? It would be nice to have a version near the top like the translations on guru3d have.

The general consensus for lumasharpen defaults seem to be pattern 3, strength 1.5, clamp 0.05. It's not quite what I use (3, 1.0, 0.5) but I use it pre-resize (effects lower contrast edges) and post-resize (high contrast edges) for the more 'even sharpening' it gives.

I wouldn't worry about coming up with an editor, editing a text is simple enough. One thing that might be nice is having 2 sets of files, one .hlsl in a mpc-hc dir and another with .txt in another directory for all other players.

CeeJay.dk

17th March 2014, 13:06

1. Is the lumasharpen you posted the same as v1.41 in my signature?
2. What allows pattern 3 to use very high strength with very few artifacts while the other patterns have all sort of artifacts? Is it taps?
3. Do all of your scripts have versions? It would be nice to have a version near the top like the translations on guru3d have.

1. Yes. It's v1.4.1
2. It uses a wider sampling pattern which is more resistant to noise, but also doesn't pick up very small details as well as pattern 2. Pattern 2 is the default for the normal SweetFX release because games almost never have noise and never has artifacts - movies however do so pattern 3 is probably best for those. So yes .. taps.

From the sourcecode :

// -- Pattern 2 -- A 9 tap gaussian using 4+1 texture fetches.
#if pattern == 2

// -- Gaussian filter --
// [ .25, .50, .25] [ 1 , 2 , 1 ]
// [ .50, 1, .50] = [ 2 , 4 , 2 ]
// [ .25, .50, .25] [ 1 , 2 , 1 ]

// -- Pattern 3 -- An experimental 17 tap gaussian using 4+1 texture fetches.
#if pattern == 3

// -- Gaussian filter --
// [ , 4 , 6 , , ]
// [ ,16 ,24 ,16 , 4 ]
// [ 6 ,24 , ,24 , 6 ]
// [ 4 ,16 ,24 ,16 , ]
// [ , , 6 , 4 , ]
3. Not all of them but perhaps they should have. I'll try to remember to include a version more often.

CeeJay.dk

17th March 2014, 13:17

Jan , the DPX effect was originally written by Loadus (http://forum.doom9.org/member.php?u=113031).

All I did was port it to SweetFX and improve the performance of it a bit. I don't fully understand why it is written the way it is.
Maybe we can get Loadus to shed some more light on it?

JanWillem32

17th March 2014, 19:52

Tracing Loadus' tracks revealed that he's mostly an artist, and to a much lesser extent a programmer. http://forum.doom9.org/showthread.php?p=1400044 http://forum.doom9.org/showthread.php?p=1399491
The reference page is: http://www.loadusfx.net/virtualdub/filmfxguide.htm .
The idea for this effect is nice enough, but it's implemented in a primitive way. For an example of improvements to consider, replace the ''grayscale'' (a name only suitable for representations from Y' (luma) in Y'CbCr or maybe even R'G'B' components) filtering to proper achromatic response, lightness or brightness filtering.

James Freeman

18th March 2014, 13:48

@CeeJay.dk

Thank you very much.
I really love LumaSharpen 1.4.1.

toniash

18th March 2014, 14:55

after resize (softcubic sharpness 70)
#define sharp_strength 2.65
#define sharp_clamp .019
#define pattern 3
#define offset_bias 1.6
#define show_sharpen 0

turbojet

18th March 2014, 23:07

CeeJay.dk: I'd like to experiment with even more taps and possibly more texture fetches, do you have an example of how to adjust these? Is there a math program that's helpful for this?

CeeJay.dk

19th March 2014, 22:54

CeeJay.dk: I'd like to experiment with even more taps and possibly more texture fetches, do you have an example of how to adjust these? Is there a math program that's helpful for this?

You can modify pattern 8 or 9 in the code .. I only use them for debugging, but they have 9 fetches.

That should be enough to do a 5x5 blur kernel if you use exploit bilinear filtering to capture 4 taps with each texture fetch.

You can add more fetches if you want.

As for what kernel you want that is up to you.
I don't know of a good tool to design convolution kernels but if anyone knows please share. I use quad paper myself.

To do a sharpen you to find the contrast of the center pixel and enhance that. To find the contrast you need to find the difference between the average of the surrounding pixels and the center pixel.
I use a gaussian blur kernel to get a weighted average, but you can also do a mean or a median (although that requires a lot of math instructions) or some sort of hybrid like discarding the brightest and darkest pixels and doing a mean of the remainders or do a median in one pass and then do a gaussian on the result in a second pass.

I prefer to use gaussians derived from pascals triangle (http://prideout.net/archive/bloom/) simply because they are easy to calculate (anyone know of a good program to calculate gaussians?)

You could start with a 5x5 gaussian kernel like

// [ 1 , 4 , 6 , 4 , 1 ]
// [ 4 ,16 ,24 ,16 , 4 ]
// [ 6 ,24 ,36 ,24 , 6 ]
// [ 4 ,16 ,24 ,16 , 4 ]
// [ 1 , 4 , 6 , 4 , 1 ]

(Pattern 3 is a reduced version of this that leaves out certain taps for performance reasons)

This can be achieved with just 9 texture fetches in one pass or even fewer in 2 passes (but doing 2 passes in MPC is tricky and requires you to make two shaders and pass the data from the first to the second in the alpha channel .. or at least that's my theory - I have yet to try it)

turbojet

21st March 2014, 08:19

Thanks, I'll try playing around with it but afraid it's over my head.

CeeJay.dk

22nd March 2014, 00:10

Thanks, I'll try playing around with it but afraid it's over my head.

What parts do you struggle with?

Do you know how convolutions work?

Do you understand what
float3 blur_ori = myTex2D(s0, tex + float2(px,-py) * 0.5 * offset_bias).rgb; // South East
does?

EncodedMango

23rd March 2014, 20:27

Well well, fancy seeing you here CeeJay :p

I'm gonna try these out, thanks!

turbojet

23rd March 2014, 21:31

StinDaWg

24th March 2014, 07:58

For 720p->1080p upscaling I'm currently using LumaSharpen pre-resize with nnedi image doubling in madVR. I have it set to low levels. Just enough to take out the softness from upscaling but still being a noticeable improvement. nnedi is a really great upscaler, I highly recommend it if your card can handle it. It's very sharp with basically no ringing or aliasing.

#define sharp_strength 0.5
#define sharp_clamp 0.05
#define pattern 3

CeeJay.dk

24th March 2014, 14:22

CeeJay.dk: I struggle with most parts of it, no clue how convolutions work. I don't understand what the code does. I'll just stay happy with pattern=3 it's plenty good, maybe at some point trying a pattern with more taps could be an improvement for film content or it might be interesting to see if more texture fetches has any effect with many taps.

A convolution kernel (also called a convolution matrix) is a map of the center pixel and the pixels around it

For a area that is 3 x 3 pixels you could have a kernel like this :
000
010
000

The number tells you how much you should sample and from what pixels.

The above kernel samples 1 time from the center pixel and nothing from the surrounding 8 pixels. This yield the exact same picture as before.

000
100
000

The above kernel samples 1 time from the pixel to the left of the center and nothing from the others.
Since the kernel is applied to every pixel in the image, you have just moved the entire image one pixel to the left.

Easy enough but not that useful

111
111
111

The kernel above samples 1 time from each pixel. All the samples are added and then you need to divide by the number of samples you took (9 in this case) or you will make the image brighter.
Adding 9 numbers together and dividing by 9 is just averaging them together - and averaging the center pixel by it's surrounding 8 pixels like this blurs the image.

This link explains it well (http://beej.us/blog/data/convolution-image-processing/) and comes with a tool you can play with to make your own convolution kernels

For pattern 2 i use a kernel that is :
121
141
121

This blurs the image smoothly. I then subtract the original image to get the difference (the contrast), which i then increase and add back to the original.

In the link above try the kernel :
-1, -2, -1
-1, 21, -1
-1, -2, -1

To get a similar sharpening.

This looks much too sharp which I why I limit the sharpening so it never goes above a certain amount.

I think the most important part of a sharpening filter is not so much how you sharpen, but how you decide how much to sharpen.

Ge'in

24th March 2014, 22:31

Many thanks for your LumaSharpen on MPC-HC.
With pattern 8 and the experimental limiter, it's just awesome.

toniash

25th March 2014, 07:42

Many thanks for your LumaSharpen on MPC-HC.
With pattern 8 and the experimental limiter, it's just awesome.

How do you activate "the experimental limiter"?

CeeJay.dk

25th March 2014, 14:31

Many thanks for your LumaSharpen on MPC-HC.
With pattern 8 and the experimental limiter, it's just awesome.

How do you activate "the experimental limiter"?

Pattern 8 is just a slower implementation of Pattern 2. I used it with earlier versions of MPC because it seemed to have a bug where the image would be slightly stretched along the diagonal if I used the faster method of sampling several taps with one texture sample (used in pattern 2). Pattern 8 worked with older version.

However with the newer MPC builds this problem have gone away and I no longer use it, because other than speed the two patterns (2 and 8) are identical. Pattern 9 is likewise just a slower version of pattern 4.

I keep them in the code because it easy to prototype new convolution kernels when you just need to change a few numbers rather than write that code again.
Once I'm satisfied with a kernel I can always find the most optimal way to take those samples at a later time.

To activate the new limiter you need to modify the code.

Looking at it quickly it looks like you can change :
#if 0 //New experimental limiter .. not yet finished

to
#if 1 //New experimental limiter .. not yet finished

The idea with the new limiter is to give the pixels with very little contrast very little sharpening because they might be gradients.
Pixels with some contrast are given more sharpening because these are details we want to enhance.
And finally pixels with a lot of contrast, we don't wan't to sharpen very much or not at all because they already have plenty of contrast and giving them more makes the image look fake and over-sharpened.

Here is a graph of the sharpening (http://i.imgur.com/m0xyEk7.png) with the old clamp (f4) and the new limiter (f2)

The X-axis shows difference in brightness to the original and the Y-axis is the sharpening strength.

Pixels that are brighter than their surroundings are made even brighter and pixels that are darker are made even darker.
Pixel with the same brightness (0,0 in the graph) are not touched

It's experimental because I want to find a good formula that allows the user to tweak the max sharpening, when it slopes up in strength and when it slopes down but a good tweakable formula is hard to find. The best I can currently do is tell you to change the / 16 at the end. A smaller divider gives a greater max strength and a greater gives a small max strength.

A good limiter formula should be easy to tweak and understand - this one is not (yet).

I wonder what limiter formula Didee uses for his LimitedSharpen (I can look at the code but I don't understand avisynth code).

In case you are curious - the #elif 0 //SweetFX 1.4 code and #else //SweetFX 1.5.1 code do the same thing. It clamps the sharpening. The 1.5.1 code just does it using 1 instruction less, by moving some of the math into other parts of the code to utilize the available instruction lanes better. I kept the older code around for reference because the new code while faster is also harder to comprehend for anyone trying to understand what the code does.

CeeJay.dk

25th March 2014, 20:26

Well well, fancy seeing you here CeeJay :p

I've been a member here for over 10 years now - Welcome to the forum Sidspyker.

turbojet

25th March 2014, 21:55

Thanks for the info on convolutions CeeJay.dk I'll play around with it when I find some more time in the next few weeks.

After a quick initial test with experimental limiter it doesn't seem right for me, it's noticeably softer and low contrast edges (mainly faces) is what I notice most. I've noticed banding shows much more with lumasharpen because of it but debanding can solve that mostly. What about if there's very small differences in edges within a large radius don't sharpen, otherwise do?

StinDaWg

28th March 2014, 16:34

turbojet

28th March 2014, 22:48

StinDaWg have you tried the experimental limiter? It noticeably reduces sharpening of high contrast edges. I don't notice an overall contrast increase but the high contrast edges are definitely higher contrast with the default clamping.

StinDaWg

29th March 2014, 03:54

I tried it, that didn't change the brightness/contrast boost for me. Like I said it's not severe like MPC Sharpen Complex, but it's still quite noticeable. I don't know if this is just a side effect of doing this method of sharpening (unsharp mask), or if there are other methods (Darbee?) that do it without the contrast boosts.

yok833

30th March 2014, 18:35

Hello I really would like to try the lumasharpen shader as it has so many good feedback... However I am not sure that I do it correctly as I do not see a huge difference with or without it.... For example if I select it 5 or 6 times consecutively in pre resize there is no difference and it offer the same results than if I would have selected it only once??? Is it normal? If a do the same with sharpen complex the sharpen is so strong that the picture is unwatchable....

Envoyé de mon GT-I9300 en utilisant Tapatalk

Guest

30th March 2014, 19:29

@yok833

You are posting this question in multiple places. That is called cross-posting and it is not allowed here, per forum rules. Please read and follow our rules to avoid strikes. Thank you for your understanding. Follow up to PM if needed, please.

CeeJay.dk

30th March 2014, 21:22

I've noticed that using this shader boosts contrast, and makes the picture brighter overall. It's especially noticeable on white text, there is a glowing effect. I don't like that. Is there anyway to modify the values to reduce or eliminate the contrast boost while still sharpening? It's not nearly as bad as the Sharpen Complex MPC-HC shader, or even unsharp mask, but it's something that really bothers me and is putting me off from using this full time.

It sounds like you are talking about haloing.

The dark or bright edges that strong edges get sometimes.

Sharpen Complex and SweetFX both do an unsharp mask filter, but SweetFX limits this using the sharp_clamp.

Try lowering the clamp until it no longer annoys you.

The idea with the experimental limiter was to reduce that even further but I don't think i have the formula right yet, judging from the feedback. More work is needed in this area.

It would also be possible to limit the sharpening in other ways.
LimitedSharpen by didee has a min/max option where the filter finds the minimum and maximum values of the surrounding pixels and uses those values as the clamp values that the sharpening is not allowed to go beyond.

This is not as fast (SweetFX is written primarily for games so speed is important to me) and it also limits the sharpening, but it should eliminate the possibility of halos.

CeeJay.dk

30th March 2014, 21:26

XRyche

31st March 2014, 02:39

I
The idea with the experimental limiter was to reduce that even further but I don't think i have the formula right yet, judging from the feedback. More work is needed in this area.

Agreed, it looks a little surreal in both games and video. It's seems to emphasize bright whites too much. The limiter seems to be a good idea though. I always tend to think sharpeners rely too heavily on higher contrasts. It reminds me of the early SD to BD resizing attempts.

StinDaWg

31st March 2014, 07:15

It sounds like you are talking about haloing.

The dark or bright edges that strong edges get sometimes.

Sharpen Complex and SweetFX both do an unsharp mask filter, but SweetFX limits this using the sharp_clamp.

Try lowering the clamp until it no longer annoys you.

The idea with the experimental limiter was to reduce that even further but I don't think i have the formula right yet, judging from the feedback. More work is needed in this area.

It would also be possible to limit the sharpening in other ways.
LimitedSharpen by didee has a min/max option where the filter finds the minimum and maximum values of the surrounding pixels and uses those values as the clamp values that the sharpening is not allowed to go beyond.

This is not as fast (SweetFX is written primarily for games so speed is important to me) and it also limits the sharpening, but it should eliminate the possibility of halos.

I changed the clamp to .015. This seems to help out with the blooming while still allowing enough sharpening for my tastes. I'm sure it could be improved some more. Looking forward to what you can do with the experimental limiter. You might want to consider changing default settings for both gaming and movie watching. As we've seen pattern 3 works better for movies and the two types of video are so different it doesn't really make sense to recommend the same settings for both.

Post-resize
#define sharp_strength 1.5
#define sharp_clamp 0.015
#define pattern 3
#define offset_bias 1.0
#define show_sharpen 0

turbojet

31st March 2014, 21:39

Has anyone else raised offset_bias and reduced strength?

Currently using strength 1.0, clamp 0.5, pattern 3, bias 3.0 and getting good results. Raising bias seems to have a great effect on lower contrast edges with little effect on high contrast edges. Just what I've been looking for.

yok833

31st March 2014, 21:56

@turbojet Are you using lumasharpen pre or post resize?

Envoyé de mon GT-I9300 en utilisant Tapatalk

turbojet

31st March 2014, 22:05

I've been using it pre and post resize for a few months now but trying to switch to post-resize only because on sharpening dirty SD sources pre-resize sharpening creates artifacts. In order to get the sharpening I was able to get from pre+post with post only I have to turn the strength up to 8.0+ which shows a lot of high contrast artifacts until I raised offset_bias and dropped strength.

kasper93

1st April 2014, 02:25

I'm using post-resize
Strength 1.55
Pattern 3
Bias 1.0
experimental limiter with "12" at the end :) 16 was limiting to much for sources that I need sharpen.

yok833

1st April 2014, 19:59

@kasper93 are you using the default setting for clamp?

Envoyé de mon GT-I9300 en utilisant Tapatalk

CeeJay.dk

2nd April 2014, 14:00

For future versions I think I can separate the settings from the shader files just like I have with the regular SweetFX release, so you have all the SweetFX settings in one place and you can even download SweetFX presets from the SweetFX Settings Database (http://sfx.thelazy.net/games/) and use them.

I think it's a good idea but what do you guys think?

turbojet

2nd April 2014, 22:08

Sounds like it could just complicate things but maybe worth a try. When it comes to preferred settings there seems to be a pretty wide range on strength, clamp and offset but pattern 3 seems to be the general consensus for film. I don't know how the settings db could help in this case.

BetA13

3rd April 2014, 18:17

turbojet

4th April 2014, 06:58

CeeJay.dk

4th April 2014, 08:00

What exactly does offset_bias do? Raising it to 2.0 makes a huge difference. Is it essentially doubling the taps or something else?

Also do any of these shaders do antialiasing? None of the names looked obvious. I would think aliasing would be pretty prominent in games after sharpening but I guess there's various methods to do it in games but nothing but avisynth for videos. In most situations (madvr ivtc) I can't use avisynth when playing.

offset_bias is a multiplier for the position of the samples.
Raising it moves the samples further away from the center pixel.

In hindsight a better name for it would have been sharp_radius , because it controls the radius of the sampling pattern.

Note that some of the patterns are created to have overlapping samples that are placed exactly where they give the right weight - moving them also changes the weighting.

I did not port the AA shaders. SMAA could not be ported because it requires features like multipass and it needs to load textures - these are features that MPC's limited shader support sadly does not provide.

FXAA can be ported if I rework it a bit - it's multipass too but can be made to function (only slower) in a single pass but I did not see the need for it. Movies do not have aliasing. Aliasing occurs because 3D hardware only samples the color of a point once per pixel - IRL however every photon that reaches the lens has color and a pixel will receive many, many, many! photons.

AA makes sense if you have recorded gameplay footage though and you don't downscale before encoding it, as downscaling will typically also remove aliasing.

turbojet

5th April 2014, 00:16

StinDaWg

5th April 2014, 10:53

Since sources have different amounts of 'sharpness' is it possible to sharpen to a certain factor? For example, a video with a theoretical sharpness of 7 and another video of 5, want to sharpen to 10, would add 3 to first video and 5 to second. I know 'values' is kind of silly but I can't think of another way to express it.
I'd be interested to know this as well. Some videos even of the same resolution have different sharpness levels. A 1080p video downscaled to 720p during encoding using Lanczos vs bilinear is going to look totally different. I'm finding it hard to pick a "one size fits all setting" because something that is good on soft videos might be oversharpened on others and vice versa.

I also have this problem in that if I use sharpen post-resize 1080p videos all end up looking oversharpened and I don't like that look. I'm only using sharpen in the first place because videos upscaled to 1080p end up looking soft, but native 1080p videos look fine 99% of the time with no sharpen needed. There's no way to set up profiles in MPC-HC so you have to use one setting for all videos, unless you want to constantly change shaders for every video, I know I don't. I wish there was a way to use shaders directly in madVR so we could set up profiles based on resolution, ect.

CeeJay.dk

7th April 2014, 00:17

Is pattern 3 a pattern that overlaps? Offset 2.0 looks fantastic with it, 3.0 was kind of ugly though.

What are the line artifacts in this video (http://www.mediafire.com/download/c5intfm6sykkcm8/sharplines.mkv) and http://www.mediafire.com/download/29q2qt9qpujsf8n/sharplines2.mpg? It's the type of artifacts that are really exaggerated by sharpeners and it would be nice to be able to fix such lines before sharpening, I don't think it has to be very complex. After looking at some pics of FXAA I'm not impressed, while it gets rid of the aliasing it removes way too many details in the process, probably very bad for film but it might be worth a try if it's not much work.

Since sources have different amounts of 'sharpness' is it possible to sharpen to a certain factor? For example, a video with a theoretical sharpness of 7 and another video of 5, want to sharpen to 10, would add 3 to first video and 5 to second. I know 'values' is kind of silly but I can't think of another way to express it.

Pattern 1 and 2 overlaps but 3 and 4 does not. Changing offset_bias still changes the weights though.

You're right about aliasing being in that clip - I didn't think movies or tv show would have aliasing, but it must have been introduced later in the, postprocessing, encoding or scaling of the video.
FXAA does have an annoying tendency to blur details - SweetFX (the edition for games) can do SMAA which is much better at preserving details but MPC-HC doesn't offer the features it would require to port the shader to MPC-HC (specifically it needs multiple passes and the ability to load textures)

I'd be interested to know this as well. Some videos even of the same resolution have different sharpness levels. A 1080p video downscaled to 720p during encoding using Lanczos vs bilinear is going to look totally different. I'm finding it hard to pick a "one size fits all setting" because something that is good on soft videos might be oversharpened on others and vice versa.

I also have this problem in that if I use sharpen post-resize 1080p videos all end up looking oversharpened and I don't like that look. I'm only using sharpen in the first place because videos upscaled to 1080p end up looking soft, but native 1080p videos look fine 99% of the time with no sharpen needed. There's no way to set up profiles in MPC-HC so you have to use one setting for all videos, unless you want to constantly change shaders for every video, I know I don't. I wish there was a way to use shaders directly in madVR so we could set up profiles based on resolution, ect.

I can't make SweetFX auto detect the sharpness for a full frame. To do that you'd have to store the sharpeness as a texture (which MPC cannot do), downscale that in another pass to get the average sharpness (which MPC cannot do), then compare with the sharpness from previous frames (which MPC cannot do) and also figure out the right way to adapt to the new sharpeness (doable but a ton of work)

I can adjust the adjust the sharp_strength depending in the resolution - it would need the resolution of the image before it was scaled though so it would only really work well with a post-resize shader.
Would you like that feature?

Madshi is working on shader support for MadVR so hopefully your last idea will be possible in the future. Ask Madshi for details.

StinDaWg

8th April 2014, 00:19

I can adjust the sharp_strength depending in the resolution - it would need the resolution of the image before it was scaled though so it would only really work well with a post-resize shader.
Would you like that feature?
Yes, if it is still user editable. For instance, if I could set it to use a different strength for videos with a horizontal resolution of 720 or lower (SD), 1280 or lower (720p) and 1920 or lower (1080p). I'm assuming if I just set strength to 0, it would turn off sharpening for 1080p videos, which is exactly what I'm looking for. The "one setting for all" approach doesn't really work, because the right settings for 720p videos can really bring out artifacts in low quality 480p videos, and also over-sharpen 1080p videos. If we could customize settings for different resolutions that would be great, kind of like what you can do now in ffdshow.