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. |
19th March 2019, 11:03 | #101 | Link | |
Registered User
Join Date: Jul 2010
Posts: 132
|
Quote:
is this in regards to the RGB conversion for MDSI/Butteraugly ? Also, running Butteraugly via Zopti takes quite a while on my system... way longer than VMAF, GMSD, SSIm etc... is this normal ? Any settings to speed this up ? Thanks. |
|
19th March 2019, 11:17 | #102 | Link |
Registered User
Join Date: Dec 2005
Location: Germany
Posts: 1,795
|
Yes, it doesn't pass the rgb converted clip but instead it copies the clip props to the old clip now.
Butteraugli is sloooow, can't do much about it.
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth VapourSynth Portable FATPACK || VapourSynth Database |
19th March 2019, 11:31 | #104 | Link |
Registered User
Join Date: Dec 2005
Location: Germany
Posts: 1,795
|
Yes and yes and the "auto-rgb-convert" is still present for mdsi and butter.
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth VapourSynth Portable FATPACK || VapourSynth Database Last edited by ChaosKing; 19th March 2019 at 11:34. |
5th April 2019, 00:05 | #106 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
No it does not. That was the whole point of my last post in the 'SSIM/GMSD metrics thread':
https://forum.doom9.org/showthread.p...63#post1870863 You posted the same question there and before I could answer, deleted it and are now asking it here. What gives ? No resize or weights are applied to the 'processed-as-luma' chroma planes. That combination would throw an error irrespective of the plane being processed. Code:
"clip1" and "clip2" must be of the same format!
__________________
Nostalgia's not what it used to be Last edited by WorBry; 5th April 2019 at 00:24. |
5th April 2019, 00:16 | #107 | Link | |
Registered User
Join Date: Jul 2010
Posts: 132
|
Quote:
well, Brian... take a really hard guess why I opted to move this to the ZOPTI thread instead of leaving it in the GMSD thread.... ? considering we're using Zopti as a wrapper... in any case - back to the point - so in case of GMSD/SSIM scoring planes 1/2 of a 444 src vs 420 dist, is Zopti/muvsfunc downscaling the src to the dist resolution or does the GMSD/SSIM metric not require both clips to be in the same resolution ? |
|
5th April 2019, 00:33 | #109 | Link |
Registered User
Join Date: Jul 2010
Posts: 132
|
yeah, that's why I ask here in the Zopti thread...
I just ran a 444 ref against a 420 dist, scored GMSD/SSIM in planes 1|2 and it did not throw an error (meaning: chroma resolution of src/dist was NOT the same)... also (as far as I understand it), vs.format does not include src/Y resolution... so, question remains... |
5th April 2019, 00:46 | #110 | Link | |
Registered User
Join Date: Dec 2005
Location: Germany
Posts: 1,795
|
Quote:
My test Code:
#c is 420 a = mvf.GetPlane(c, 1) c = core.fmtc.resample(c, css="444") b = mvf.GetPlane(c, 1)#.fmtc.resample(css="444") c = muf.SSIM(a,b)
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth VapourSynth Portable FATPACK || VapourSynth Database |
|
5th April 2019, 02:21 | #112 | Link | |
Registered User
Join Date: Jul 2010
Posts: 132
|
Quote:
so what are opinions about how to weigh the GMSD/SSIM results if the css of the dist differs ? |
|
5th April 2019, 03:56 | #113 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
You don't. You either convert the css of the 'distorted' clip to that of the reference or vice versa. They must be the same format - period. It's the fundamental requirement of Full Reference Image Quality Assessment. You seem to be laboring under this notion that it should somehow be different. 'Full Reference' - think about it.
__________________
Nostalgia's not what it used to be Last edited by WorBry; 5th April 2019 at 04:26. |
5th April 2019, 04:27 | #114 | Link | |
Registered User
Join Date: Jul 2010
Posts: 132
|
Quote:
I was referring to weighing the chroma plane results (if dist had different css than ref) when combining them with the Y plane result for a total GMSD/SSIM score based on all three planes............... in addition... chroma plane results can also be (optionally) weighed (in a combined score) even if both ref/dist have the exact same css considering the fact that color drift has less perceived impact in human vision... whatever it is that u're mumbling in regards to "format" has nothing to do with any of it... just because u're matching a format so u can run the metric does not mean the data is (or should be considered) equal........ Last edited by Iron_Mike; 5th April 2019 at 04:33. |
|
5th April 2019, 04:35 | #115 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Someone else deal with this please. I'm done with this nonsense.
Also Iron_Mike, please desist in referring to me by anything other than my forum user name. I don't know what you are trying to convey, but it's rather creepy and smacks of trollism.
__________________
Nostalgia's not what it used to be Last edited by WorBry; 5th April 2019 at 05:43. |
5th April 2019, 12:27 | #116 | Link | |
Registered User
Join Date: Dec 2005
Location: Germany
Posts: 1,795
|
Quote:
hmm a score based on all three planes... For that I tried to see how the video looks like if you extremely blur the chroma plane. Surprisingly only the colors are a bit off. I guess the final score could be as simple as Plane1 80% + P2 10% + P3 10% ... I don't know what a good weighted total score should look like. Code:
c2_1 = mvf.GetPlane(c2, 1).std.BoxBlur(hradius=5, vradius=5) c2_2 = mvf.GetPlane(c2, 2).std.BoxBlur(hradius=5, vradius=5) c2 = core.std.ShufflePlanes(clips=[mvf.GetPlane(c2, 0), c2_1, c2_2], planes=[0, 0, 0], colorfamily=vs.YUV) a = mvf.GetPlane(c, 1) b = mvf.GetPlane(c2, 1) #a=c #b=c2 c = muf.SSIM(b,a).text.FrameProps() c.set_output()
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth VapourSynth Portable FATPACK || VapourSynth Database |
|
5th April 2019, 15:31 | #117 | Link | |||||
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Quote:
Quote:
Quote:
Quote:
Quote:
So the ffmpeg variant applies different weights according to pixel format of the clips being tested, but they must have the same pixel format and resolution https://ffmpeg.org/ffmpeg-filters.html#ssim Of course the FFMPEG metric can also be run on RGB clips, generating scores for the individual R,G,B channels and an overall aggregate score. But it's still using the 'fast' and less precise 'standard approximation of overlapped 8x8 block sums'. Is there provision in the original Matlab SSIM code for measuring and weighting the chroma or some other reference where this is defined - I don't know ? I checked out the demo 'Pro' version of the MSU-QMT, btw - the demo version intentionally generates incorrect results as a kind of 'metric watermark' but it shows the options that are available for the different measures. Looks like the 'precise' (gauss blur) and 'fast' SSIM variants are measuring Y luma only. And then there are these other 'SSIM algorithm-based' variants - DSSIM and SSIMULACRA - intended (like Butteraugli) primarily for measuring differences in still images, which process in CIE Lab* color space and apply weights to the L, a and b channels to derive an overall score: https://github.com/kornelski/dssim https://github.com/cloudinary/ssimulacra https://cloudinary.com/blog/detectin...ing_ssimulacra Personally, I'd be more interested in deriving a composite SSIM score for the combined chroma channels, rather than (or in addition to) an 'overall' score, but that would also require consideration of the weightings.
__________________
Nostalgia's not what it used to be Last edited by WorBry; 5th April 2019 at 18:56. |
|||||
5th April 2019, 21:22 | #118 | Link | |
Registered User
Join Date: Jan 2016
Posts: 98
|
Quote:
I would expect the result to be very close to averaging the results of the individual u and v planes. |
|
5th April 2019, 21:37 | #119 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Now that's a novel idea. I was thinking of maybe merging the luma-converted U and V planes.
__________________
Nostalgia's not what it used to be Last edited by WorBry; 5th April 2019 at 21:47. |
5th April 2019, 23:33 | #120 | Link |
Registered User
Join Date: Jan 2016
Posts: 98
|
With the same general idea, one could obtain an “an 'overall' score” by stacking all the planes:
Code:
ret = some_video_source #This should work to preserve vertical resolution, and stacking all Y,U and V, no matter the css (chroma subsampling: 411, 420, 422, 444) retc = core.std.StackHorizontal(clips=[retU,retV]) if ret.format.subsampling_h == 0 else core.std.StackVertical(clips=[retU,retV]) ret = core.std.StackHorizontal(clips=[retY,retc]) Code:
sub- Y U V sampling ratio ratio ratio 4:1:1 2/3 1/6 1/6 4:2:0 2/3 1/6 1/6 4:2:2 1/2 1/4 1/4 4:4:4 1/3 1/3 1/3 |
Thread Tools | Search this Thread |
Display Modes | |
|
|