Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
5th April 2019, 23:36 | #121 | Link |
Registered User
Join Date: Jul 2010
Posts: 132
|
@WorBry: I'm glad u finally woke up and entertain the idea of "weights" - a concept used in scientific formulas and equations since the dawn of time, and that includes the field of color science.
This is good, this could indicate progress ! Maybe next time before u have ur temper tantrum, u can put the bottle aside, and read posts properly. Zorr did directly mention weights to u in regards to ffmpeg's implementation but u seem to have chosen to ignore that... until u remembered. well, to quote u: what gives ? yeah, hence me throwing it out there and asking for opinions... ;-) |
6th April 2019, 00:02 | #122 | Link | |
Registered User
Join Date: Jul 2010
Posts: 132
|
Quote:
this was my pretty much my first approach. so what about the idea - in case of src/ref and dist/enc having different css - of flipping that table and the more css the distorted clip has (compared to src/ref), to give chroma score more weight than luma ? that would bring the total score down, but with a 420 dist clip, the chroma drift/delta will have a larger perceived impact than with a 444 dist clip... for example: source is 444 and the dist is 420... we could consider giving the chroma score more weight than luma, b/c that color drift will have a larger impact for WorBry: no, just b/c u put the 420 dist in a 444 clip to run the metric does not make the 420 data inside that new clip a "444" encode... it's resampled 420 data |
|
6th April 2019, 00:48 | #123 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
I think the dist. should always be converted to the ref. pixel format
The metric should take into account the results of resizing the data - that's the whole idea of metrics measuring the effect of chroma subsampling . It should be a measureable phenomenon (and it is with standard metrics) eg a) 444 source reference b) a is converted to "b" 4:2:0 by algorithm "z" (this means the U,V planes are resized by 1/2 width, 1/2 height) You need to convert b back to 444 to compare against "a" . ie. resize back the U,V planes *2 width/height . - you expect 422 to do better than 420 - and you do with ssim, psnr - you expect to get slightly different results with different resize algorithms (e.g. sharper isn't always "better" ; sharper actually tends to get "penalized" by some metrics like ssim/psnr) - serial conversions get blurrier colors, and worse results, as expected (because really you're up/down scaling the chroma planes) Or if you're starting with a 420 reference ; and you're testing against something at got converted to 444 . That up/down conversion should be reflected in the scores as a larger deviation from the original reference. Don't mix in "weights" ; it's a separate concept dealing with human perception of color vs. black/white . Your perception doesn't change , based on different pixel format of videos - it's the source that is changing . Weighting should be the same whatever you decide the formula is . You don't become less sensitive to color with 444 vs 420 . The effect of chroma subsampling should be measured and reflected by the metric Last edited by poisondeathray; 6th April 2019 at 01:07. |
6th April 2019, 01:45 | #124 | Link | |
Registered User
Join Date: Jul 2010
Posts: 132
|
Quote:
so when u combine metric score for luma and chroma planes, one could consider that... or are u saying the chroma metric scores already state that and u would just pull the avg ? Btw, weights weren't mixed in (in my posts) - weights are constants - luma vs. chroma perception is one, but u can have additional weights for other effects... for example, the luma vs. chroma weight also only kicks in if you're actually dealing w/ color footage (so it is a conditional factor)... |
|
6th April 2019, 01:46 | #125 | Link | ||||
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Quote:
https://forum.doom9.org/showthread.p...63#post1870863 And your original question about 'weights' here was: Quote:
Quote:
Quote:
@VS_Fan and Poisondeathray. Thanks. Alot to think about there.
__________________
Nostalgia's not what it used to be Last edited by WorBry; 6th April 2019 at 02:12. |
||||
6th April 2019, 02:03 | #126 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
Quote:
The idea of "weights" for a combined Y/U/V aggregate metric score, should reflect that the Y plane should recieve a proportionally higher weighting due to human perceptions - I think everyone will agree on the general idea, but might disagree on the actual formula for the weighting All I'm saying is the relative weighting shouldn't change because of subsampling . Your perception of the proportion of black/white vs. color importance doesn't suddenly change if you watch a 4:4:4 video or a 4:2:0 video. That lower quality of 4:2:0 should already be reflected in the lower U, V scores for 4:2:0 . That up/down converison is the "penalty" already incurred . The "different treatment" of chroma is exactly what you're measuring in the first place when you measure U-SSIM, V-SSIM, or U-PSNR, V-PSNR or whatever metric Yes you can have other weights, other categories, combine /mix/match in any way you want , analyze it in whatever way you want, call it whatever you want ; but eitherway you're measureing Y,U,V separately - so you should have the "raw" scores |
|
6th April 2019, 12:17 | #127 | Link | |
Registered User
Join Date: Jul 2010
Posts: 132
|
Quote:
now stop dancing around the subject, what would be your weights/formula for a combined metric score of all planes ? |
|
6th April 2019, 16:19 | #128 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
I don't think there is a commonly accepted formula/value for all planes. There are no scientific studies that conclusively measure this value to be "x/y/z"
Just pick one and as long as you state your assumptions, criteria, and reasoning- it's ok . e.g if you decide 0.8/0.1/0.1 , say so What's not ok - is if you post results, but no details - ie. lack of transparency . e.g. if you measure a black/white movie - you might still decide to look at U/V . There are old movies that have discoloration and chroma noise / rainbows due to the transfer process for example . Everyone knows (or should know) , that all metrics have various pros/cons and are context dependent. But the trends can still be useful to look at |
21st April 2019, 17:46 | #130 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
I have a small feature request regarding cases where colorspace conversion to RGB is required. It would be nice if Zopti as an option could do the conversion just once and save the resulting file as an intermediate file to use in all the subsequent iterations. I don't know how much time consuming it actually is, but I'd expect that the number of iterations is usually so big that over a long test run, it would same a nice amount of time.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
22nd April 2019, 22:07 | #131 | Link |
Registered User
Join Date: Mar 2018
Posts: 447
|
That's a bit tricky, currently Zopti doesn't know what the input file is so it's unable to change it. I think it could save the converted file using clip.output() (someone can correct me here if I'm wrong) and then read that one instead, but I'm not sure if it's any faster if the file is in uncompressed format which the output() supports. Does someone have experience on using output() and reading the resulting file?
|
29th October 2020, 10:39 | #132 | Link |
Registered User
Join Date: Dec 2005
Location: Germany
Posts: 1,795
|
Btw Asd-g ported some metrics like MDSI, GMSD or vsSSIM to avs https://github.com/Asd-g/AviSynthPlus-Scripts
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth VapourSynth Portable FATPACK || VapourSynth Database |
19th November 2020, 18:11 | #133 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
I was trying to run Zopti with these parameters (rest of the script is not there):
Code:
zopti = Zopti(r'results.txt', metrics=['mdsi'], matrix='709') b = -75/100.0 # optimize b = _n_/100.0 | -150..50 | b c = 15/100.0 # optimize c = _n_/100.0 | -100..100 | c Code:
java.lang.NumberFormatException: For input string: "b=-75" at sun.misc.FloatingDecimal.readJavaFormatString(Unknown Source) at sun.misc.FloatingDecimal.parseFloat(Unknown Source) at java.lang.Float.parseFloat(Unknown Source) at java.lang.Float.<init>(Unknown Source) at avisynthoptimizer.Result.parseValues(Result.java:93) at avisynthoptimizer.Result.<init>(Result.java:240) at avisynthoptimizer.LogFile.read(LogFile.java:276) at avisynthoptimizer.AviSynthOptimizer.evaluateResults(AviSynthOptimizer.java:3564) at avisynthoptimizer.AviSynthOptimizer.main(AviSynthOptimizer.java:1872) ERROR: For input string: "b=-75" This is the command line I've used: for %f in (*.vpy) do zopti "%f" -alg mutation -iters dyn -dyniters 15 -dynphases 2 -pop 1 -runs 1 -mutcount 1 -mutamount 0.1 0.01 -initial script
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
19th November 2020, 22:13 | #134 | Link | |
Registered User
Join Date: Mar 2018
Posts: 447
|
Quote:
|
|
20th November 2020, 06:12 | #135 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Quote:
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
20th November 2020, 19:51 | #137 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
That's what I have, it looks like the application just reports 1.0-beta. I verified that the files in the latest archive are the same as what I have in my Zopti folder.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
20th November 2020, 20:56 | #138 | Link | |
Registered User
Join Date: Mar 2018
Posts: 447
|
Quote:
Code:
# output out1="SSIM: MAX(float)" file="results.txt" 7.86225 b=0 c=0 7.862938 b=1 c=1 7.854728 b=1 c=0 # phase=0,00 7.889888 b=-4 c=1 7.8532143 b=-18 c=1 7.8917427 b=-4 c=6 7.8901386 b=-4 c=7 |
|
21st November 2020, 10:05 | #139 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Yes, looks similar:
Code:
# output out1="MDSI: MIN(float)" file="results.txt" 30.7859 b=-60 c=30 31.428144 b=-47 c=12 30.756887 b=-63 c=30 # phase=0,00 30.797626 b=-59 c=30
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
24th March 2021, 19:38 | #140 | Link | |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Quote:
__________________
Nostalgia's not what it used to be Last edited by WorBry; 24th March 2021 at 20:25. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|