• 《国家人文历史》往期杂志汇总 2019-04-22
  • 一师一团土地确权登记颁证工作全面展开 2019-04-14
  • 德州扑克赌场披“俱乐部”外衣 打竞技旗号难掩赌博实质 2019-04-12
  • 自治区党委召开常委(扩大)会议 陈全国主持 2019-04-12
  • 17年来首次!塔利班组织宣布停火3天 与阿富汗民众自拍 2019-04-04
  • 2022年冬奥会筹备进行时 2019-04-03
  • 人家80年前就造航母,我们现在才造航母,基础不一样。 2019-04-03
  • 葡萄牙首都上演城市节狂欢 2019-04-01
  • RED EARTH红地球展现自我丝绒唇膏全新发布 2019-03-24
  • 龙船礼 有讲究 百岁龙 抖精神 2019-03-17
  • 新加坡航空将开通 全球最长商业航线 2019-03-17
  • 传说中的自由飞“翔” 当厕所被狂风吹上天 2019-03-12
  • 导游强迫交易获刑 曾辱骂威胁强迫游客消费上万元--旅游频道 2019-03-09
  • 北京正式推出租赁型职工集体宿舍 每间居住人数不超8人 2019-03-09
  • 美元短线拉升 随后回吐涨幅 2019-03-07
  • Welcome to

    Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

     

    Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

    Reply
     
    Thread Tools Search this Thread Display Modes
    Old 3rd April 2019, 04:30   #301  |  Link
    Registered User
     
    Join Date: Jul 2010
    Posts: 132
    Quote:
    Originally Posted by poisondeathray View Post
    For the other Iron_Mike tests, they were Y only , right ? For example, not SSIM-U , or SSIM-V . Because you would expect 444 to score better than 420 in terms of color in general . Or what was the point of 444,422,420 testing ?

    I don't think the netflix implementation can , but the muvsfunc can specify the plane processed
    Could you elaborate on this ?

    which SSIM implementation (libvmaf SSIM | libvmaf MS-SSIM | SSIM muvsfunc) processes Y plane only ?
    Iron_Mike is offline   Reply With Quote
    Old 3rd April 2019, 05:03   #302  |  Link
    Registered User
     
    Join Date: Sep 2007
    Posts: 3,758
    Quote:
    Originally Posted by WorBry View Post

    I encoded the clip to x264 and x265 but limited to CRF 1-5 range - I was more interested in seeing what fine differences the metrics could pick up in the near-lossless domain than quality efficiency at lower bitrates, and especially in light of the results obtained with Boulder's Black Sails clip, where x265 had the edge:

    Interesting CRF 1-5 results.

    For lossless encoding, x264 compresses better than x265 by few % ; at least for 8bit 4:2:0 . I've compared them head to head on about 30 sources over the last few years (different types of content), and 100% of the time x264 compresses better .

    For moderate to high bitrates , in scenarios where you have adequate bandwidth to attempt to preserve details, I would disable SAO for x265 . It tends to be a detail killer, acting like a smoothing filter. I always do this for my own usage.




    Quote:
    Originally Posted by Iron_Mike View Post
    Could you elaborate on this ?

    which SSIM implementation (libvmaf SSIM | libvmaf MS-SSIM | SSIM muvsfunc) processes Y plane only ?


    for muvsfunc, you specify the plane= . You might be able to do all 3 with plane=[0,1,2]

    Not sure about netflix libvmaf SSIM, but the earlier Netflix comments say color isn't looked at for VMAF. And you would expect the log should show U, V (or Cb,Cr) channel info - but it doesn't

    ffmpeg ssim log will print out SSIM-U, SSIM-V, SSIM-Y , so you know all 3 channels are measured

    Then, there are different weighting formulas for Y,U,V . ie. What is the "correct" way to weight the channels ? Simple mean? "Y" is much more important to human vision . You can optimize for some metrics by tweaking chroma offsets for encoders (stack the "Y" by underallocating, U,V) . Since you know Neflix VMAF doesn't look at color, you could allocate more bitrate into Y for example, and score higher




    Also I did 8bit/10bit 4:2:0,4:2:2,4:4:4 test on another source at CRF21 and the 4:2:2 was significantly larger , so that's another data point . Still not sure if it means anything, but still interesting
    poisondeathray is offline   Reply With Quote
    Old 3rd April 2019, 06:25   #303  |  Link
    Registered User
     
    Join Date: Jul 2010
    Posts: 132
    Quote:
    Originally Posted by poisondeathray View Post
    for muvsfunc, you specify the plane= . You might be able to do all 3 with plane=[0,1,2]
    Zoptilib and muvsfunc do not unfortunately, u have to do all three planes individually

    Quote:
    Originally Posted by poisondeathray View Post
    Also I did 8bit/10bit 4:2:0,4:2:2,4:4:4 test on another source at CRF21 and the 4:2:2 was significantly larger , so that's another data point . Still not sure if it means anything, but still interesting
    as of right now, I would assume this has to do with the way the encoder app is handling things...
    Iron_Mike is offline   Reply With Quote
    Old 3rd April 2019, 06:33   #304  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by poisondeathray View Post
    For moderate to high bitrates , in scenarios where you have adequate bandwidth to attempt to preserve details, I would disable SAO for x265 . It tends to be a detail killer, acting like a smoothing filter. I always do this for my own usage.
    Thanks, I'll look at that.

    Quote:
    Originally Posted by poisondeathray View Post
    for muvsfunc, you specify the plane= . You might be able to do all 3 with plane=[0,1,2]
    Not sure. The function definition only gives:

    Code:
    plane: (int) Specify which plane to be processed. Default is None.
    And looking at the function code, I can't see provision for other plane options. I got the impression that it's hard coded for luma only. Same goes for GMSD.

    Quote:
    Originally Posted by poisondeathray View Post
    Not sure about netflix libvmaf SSIM, but the earlier Netflix comments say color isn't looked at for VMAF. And you would expect the log should show U, V (or Cb,Cr) channel info - but it doesn't
    Simplest way to test is to convert the source and test clips to greyscale and see if it changes the scores. I did that in the Crowd Run 10bit 422 tests with ProRes and Cineform and the muvsfunc SSIM and GMSD scores were not affected at all. Didn't test VMAF on the greyscale clips in that instance, but I'm pretty sure all the component metrics are luma plane only.

    Quote:
    Originally Posted by poisondeathray View Post
    ffmpeg ssim log will print out SSIM-U, SSIM-V, SSIM-Y , so you know all 3 channels are measured
    Right. Zorr checked out the code for ffmpeg SSIM (AVISynth SSIM also) earlier in the thread. In essence, it's akin to the 'fast' SSIM metric in the MSU Quality Tool:

    //www.zs-x.com/showthread.p...30#post1866030

    //www.zs-x.com/showthread.p...62#post1866162

    Couple of examples where I plotted out the Y,U,V channel scores.



    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 3rd April 2019 at 06:50.
    WorBry is offline   Reply With Quote
    Old 3rd April 2019, 06:36   #305  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by Iron_Mike View Post
    Zoptilib and muvsfunc do not unfortunately, u have to do all three planes individually
    How have you tested that ???
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 3rd April 2019 at 06:59.
    WorBry is offline   Reply With Quote
    Old 3rd April 2019, 06:46   #306  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by Iron_Mike View Post
    source/ref resolution and encoding resolution was 1920x1080p.

    Model was 0.6.1 as stated on the pics - I used the exact same model in both VS|ffmpeg tests, meaning: the exact same .pkl file.
    OK thanks.
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 3rd April 2019 at 07:00.
    WorBry is offline   Reply With Quote
    Old 3rd April 2019, 09:14   #307  |  Link
    Registered User
     
    Join Date: Jul 2010
    Posts: 132
    Quote:
    Originally Posted by WorBry View Post
    And looking at the function code, I can't see provision for other plane options. I got the impression that it's hard coded for luma only. Same goes for GMSD.
    yes, it does default to plane=0 (Y), if the plane param is None, meaning: not passed in

    Quote:
    Originally Posted by WorBry View Post
    How have you tested that ???
    looked at the code in muvsfunc, the plane param needs to be of type int...

    and u can also simply test this by running these params when passing config to Zopti:

    Code:
    'ssim': {'downsample': False, 'show_map': False, 'plane': (0, 1, 2)}
    it will throw error from muvsfunc that plane param needs to be int... setting plane=2 (for example) will measure the 'v' plane...

    Code:
    'ssim': {'downsample': False, 'show_map': False, 'plane': 2}
    so currently, u need to run all three planes individually...

    Last edited by Iron_Mike; 3rd April 2019 at 09:19.
    Iron_Mike is offline   Reply With Quote
    Old 3rd April 2019, 15:03   #308  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Oh I see now. It uses the GetPlane (ShufflePlanes based) helper function from mvsfunc to extract and convert the selected plane to greyscale (Y Luma) for processing.

    I'd be more interested in deriving an aggregate value for the UV chroma planes than all three planes.

    Actually, in the MDSI function there is provision to adjust the weight given to the pooled gradient and chromacity similarity maps:

    Code:
    alpha: (float, 0~1) Weight used to merge gradient similarity (GS) map and chromaticity similarity (CS) map.
    
    Default is 0.6.
    I'll look at that also.
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 4th April 2019 at 05:17.
    WorBry is offline   Reply With Quote
    Old 3rd April 2019, 16:03   #309  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by WorBry View Post
    I'm pretty sure all the component metrics are luma plane only.

    //www.zs-x.com/showthread.p...79#post1870779

    Quote:
    Originally Posted by HolyWu View Post
    ....Note that libvmaf only uses luma plane for calculating scores.
    __________________
    Nostalgia's not what it used to be
    WorBry is offline   Reply With Quote
    Old 4th April 2019, 02:12   #310  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by WorBry View Post
    Oh I see now. It uses the GetPlane helper function from mvsfunc to extract and convert the chosen plane to greyscale (Y Luma) for processing.
    Tested it out using the x264 CRF1 transcode of the Sony 2160/30p XAVC clip. Appears to work as expected. Plane=1 and Plane=2 produce different SSIM and GMSD scores to default plane=0 (None). Also, when the reference and test clips are converted to greyscale, the SSIM and GMSD scores are absolute (1 and 0) with Plane=1 and Plane=2, as you would expect.

    Quote:
    Originally Posted by WorBry View Post
    In the MDSI function there is provision to adjust the weight given to the pooled gradient and chromacity similarity maps:

    Code:
    alpha: (float, 0~1) Weight used to merge gradient similarity (GS) map and chromaticity similarity (CS) map.
    
    Default is 0.6.
    I'll look at that also.
    I was rather hoping that setting alpha=0 would exclude the gradient (structural/luminance) similarity component and setting alpha=1 would exclude the chromacity similarity component, but that does not appear to be the case. Based on the outcomes observed with greyscale clips, it does shift the bias to some degree, but it's not absolute.
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 4th April 2019 at 06:13.
    WorBry is offline   Reply With Quote
    Old 4th April 2019, 16:34   #311  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Incidentally, came across this study:

    https://www.intechopen.com/books/pro...gh-resolutions

    They used the MSU Quality Measurement Tool for the SSIM and PSNR metrics.
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 4th April 2019 at 16:47.
    WorBry is offline   Reply With Quote
    Old 4th April 2019, 18:48   #312  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by WorBry View Post
    Oh I see now. It uses the GetPlane (ShufflePlanes based) helper function from mvsfunc to extract and convert the selected plane to greyscale (Y Luma) for processing.
    Quote:
    Originally Posted by WorBry View Post
    Tested it out using the x264 CRF1 transcode of the Sony 2160/30p XAVC clip. Appears to work as expected. Plane=1 and Plane=2 produce different SSIM and GMSD scores to default plane=0 (None). Also, when the reference and test clips are converted to greyscale, the SSIM and GMSD scores are absolute (1 and 0) with Plane=1 and Plane=2, as you would expect.
    I also checked whether setting the selected plane internally gives the same score as converting the plane to Gray8 externally with ShufflePlanes, e.g.

    Code:
    clip = core.std.ShufflePlanes(clips=clip, planes=1, colorfamily=vs.GRAY)
    And it does - the scores are identical. For the x264 CRF1 clip (256 frames):
    Code:
    SSIM (no downsample):
    
    Plane=0;  255.9883826437114205942791044 
    Plane=1;  255.9511353443287036135700421 
    Plane=2;  255.9553550588348764804891293
    
    GMSD (no downsample):
    
    Plane=0 1.342334158110490287003219167
    Plane=1 2.221467708712367798208099638 
    Plane=2 2.180245724244588914348796231
    However, it needs to be borne in mind the luma-converted U (Plane 1) and V (Plane 2) planes are being processed at the chroma resolution. In this case, the 4:2:0 chroma > luma was processed at 1920 x 1080 resolution. For 4:2:2, it would be 1920 x2160 and for 4:4:4, 3840 x 2160.

    So expect that chroma resolution of the reference and test clip will affect the scores.

    In the FFMPEG SSIM metric:

    Quote:
    Originally Posted by zorr View Post
    The total SSIM takes into account all the planes but the weighting is different, each plane is scaled by the resolution is has. So for example with YUV420 the color planes have 4 times smaller weight.
    //www.zs-x.com/showthread.p...62#post1866162
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 4th April 2019 at 19:02.
    WorBry is offline   Reply With Quote
    Old 4th April 2019, 23:41   #313  |  Link
    Registered User
     
    Join Date: Jul 2010
    Posts: 132
    Quote:
    Originally Posted by WorBry View Post
    However, it needs to be borne in mind the luma-converted U (Plane 1) and V (Plane 2) planes are being processed at the chroma resolution. In this case, the 4:2:0 chroma > luma was processed at 1920 x 1080 resolution. For 4:2:2, it would be 1920 x2160 and for 4:4:4, 3840 x 2160.
    is the original src clip UHD format or why do u end up @ 3840x2160 in 444 for the chroma planes ?

    Last edited by Iron_Mike; 4th April 2019 at 23:51.
    Iron_Mike is offline   Reply With Quote
    Old 4th April 2019, 23:56   #314  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by Iron_Mike View Post
    is the original src clip UHD format or why do u end up @ 3840x2160 in 444 for the chroma planes ?
    Yes, the original source clip and x264 transcode are UHD resolution.

    Quote:
    Originally Posted by WorBry View Post
    Tested it out using the x264 CRF1 transcode of the Sony 2160/30p XAVC clip.
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 4th April 2019 at 23:59.
    WorBry is offline   Reply With Quote
    Old 7th April 2019, 16:03   #315  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quick question - how do you convert a full color RGB or YUV clip (whether 4:4:4, 4:2:2 or 420) to greyscale RGB in VapourSynth ?
    Couldn't figure it out when I ran those parallel greyscale MDSI tests in the CrowdRun > Prores series and ended up using the 'Greyscale' filter in AVISynth+ and exporting the output to MagicYUV.

    Must surely be possible with fmtconv/shuffleplanes, but I just can't figure it.
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 7th April 2019 at 16:22.
    WorBry is offline   Reply With Quote
    Old 7th April 2019, 16:44   #316  |  Link
    Registered User
     
    Join Date: Dec 2005
    Location: Germany
    Posts: 724
    Maybe like this core.std.ShufflePlanes(clip, planes=[0,0,0], colorfamily=vs.RGB)

    EDIT
    import mvsfunc as mvf
    clip = mvf.GrayScale(clip)
    __________________
    Search and denoise

    Last edited by ChaosKing; 7th April 2019 at 16:48.
    ChaosKing is offline   Reply With Quote
    Old 7th April 2019, 16:50   #317  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Thank-you.

    Edit:
    Actually, core.std.ShufflePlanes(clip, planes=[0,0,0], colorfamily=vs.RGB) works fine, but mvf.GrayScale throws the error - Error on frame 0 request: Resize error 1026: RGB color family cannot have YUV matrix coefficients - when trying to convert a full color YUV source to greyscale RGB with:
    Code:
    clip = core.fmtc.resample (clip, css="444")
    clip = core.fmtc.matrix (clip, mat="709", col_fam=vs.RGB)
    clip = core.fmtc.bitdepth (clip, bits=8)
    clip = mvf.GrayScale(clip)
    
    or
    
    clip = mvf.ToRGB(clip, depth=8) 
    clip = mvf.GrayScale(clip)
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 7th April 2019 at 18:01.
    WorBry is offline   Reply With Quote
    Old 8th April 2019, 03:19   #318  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    Quote:
    Originally Posted by poisondeathray View Post
    For moderate to high bitrates , in scenarios where you have adequate bandwidth to attempt to preserve details, I would disable SAO for x265 . It tends to be a detail killer, acting like a smoothing filter. I always do this for my own usage.
    Quote:
    Originally Posted by WorBry View Post
    Thanks, I'll look at that.
    I ran a parallel series of x265 encodes (CRF 1 -5 ) of the Sony 2160/30p XAVC clip, with SAO disabled:

    Code:
    ffmpeg -i  {Path}:/AX100.mp4 -vcodec libx265 -preset slow -crf {Value} -pix_fmt yuv420p -r 30000/1001 -x265-params no-sao=1:colorprim=1:transfer=1:colormatrix=1 {Path}:/AX100_x265_No_SAO_CRFx.mp4
    It had negligible effect on the encode bitrates and SSIM and GMSD scores in this case:

    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 8th April 2019 at 06:43.
    WorBry is offline   Reply With Quote
    Old 15th April 2019, 18:56   #319  |  Link
    Registered User
     
    Join Date: Jan 2004
    Location: Here, there and everywhere
    Posts: 1,187
    
    Quote:
    Originally Posted by WorBry View Post
    I also checked whether setting the selected plane internally gives the same score as converting the plane to Gray8 externally with ShufflePlanes, e.g.

    Code:
    clip = core.std.ShufflePlanes(clips=clip, planes=1, colorfamily=vs.GRAY)
    And it does - the scores are identical. For the x264 CRF1 clip (256 frames):
    Code:
    SSIM (no downsample):
    
    Plane=0;  255.9883826437114205942791044 
    Plane=1;  255.9511353443287036135700421 
    Plane=2;  255.9553550588348764804891293
    
    GMSD (no downsample):
    
    Plane=0 1.342334158110490287003219167
    Plane=1 2.221467708712367798208099638 
    Plane=2 2.180245724244588914348796231
    However, it needs to be borne in mind the luma-converted U (Plane 1) and V (Plane 2) planes are being processed at the chroma resolution. In this case, the 4:2:0 chroma > luma was processed at 1920 x 1080 resolution. For 4:2:2, it would be 1920 x2160 and for 4:4:4, 3840 x 2160.

    So expect that chroma resolution of the reference and test clip will affect the scores.

    In the FFMPEG SSIM metric:

    //www.zs-x.com/showthread.p...62#post1866162
    In light of the discussion that ensued in the Zopti thread...

    //www.zs-x.com/showthread.p...80#post1870880...

    ...I thought it would be interesting to see how the raw (muvsfunc) SSIM scores for the chroma planes compare with those generated by ffmpeg SSIM.

    For that I turned to the Crowd Run 1080 50p series of x264 (CRF 0 -30) encodes that I retained from the earlier metric tests; I had already collated the ffmpeg SSIM Y, U and V results.

    I also wanted look at the outcomes when the 8bit 4:2:0 chroma (of both the test and reference clips) is up-sampled to (YUV) 444 before testing, and whether converting the original chroma planes to Gray8 and then up-scaling to 1920 x 1080 produces similar results, which in theory it should.

    I used Resize.Bicubic for both the chroma up-sampling and Gray8 up-scaling. Downsample=False was applied in the chroma plane tests. Here are the results:



    The 'raw' muvsfunc SSIM scores obtained for the Y, U and V planes (top right chart) show a similar pattern to those produced by ffmpeg SSIM, but they are lower and propotionately more so in the lower bitrate range.

    Looking at the results for the individual planes.

    In the Y plane results I also included the scores obtained previously with 'Down-sample=True' i.e. the default settings. As seen in all of the test series, the initial 2x2 down-sampling always produces higher scores, and in this case higher than ffmpeg SSIM - I don't think the ffmpeg SSIM metric applies any internal down-sampling.

    As for the U and V planes. First thing to note is that the upsampled (444) and upscaled (Gray8) scores are indeed very close. Secondly, the 'upsampled/upscaled' scores are higher than the 'raw' scores and also the ffmpeg SSIM scores. Which leaves me wondering....

    Quote:
    Originally Posted by zorr View Post
    I looked at the ffmpeg source. It's doing the fast version too - no gaussian kernels there. The total SSIM takes into account all the planes but the weighting is different, each plane is scaled by the resolution is has. So for example with YUV420 the color planes have 4 times smaller weight. .
    Does that mean that the reported (aggregate) scores for the individual Y, U and V planes are also weighted (i.e. scaled by the resolution each has) or is that weighting only being applied in calculating a total ('All') score ? Or is it simply that the muvsfunc SSIM is more accurate than the 'fast' ffmpeg implementation ?

    Thinking about Poisondeathray's comments in the Zopti thread:

    Quote:
    Originally Posted by poisondeathray View Post
    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 either way you're measuring Y,U,V separately - so you should have the "raw" scores
    I'm inclined to agree that, for the purpose of objective metric analysis at least, you want to have the raw scores for the individual Y, U and V planes. Personally, I don't see that much value in composite 'Total' score, however derived. If there are differences, you want to know if they occurring in the Luma (structural distortions) or the Chroma. A weighted 'Total' score might also obscure subtle differences that are occurring in the chroma. You can see that in the above ffmpeg SSIM results, at the lower bitrates especially; the weighted 'All' score curve shows a greater bias to the 'Y' plane curve, as you would expect.

    That said, when it comes to 'perceptual quality' is there maybe a case for 'normalizing' the chroma to 444 ? After all, that is what we are looking at when viewing a video on a display. Is it more meaningful to 'normalize' the chroma before the metric is applied than to apply some compensatory weighting to the raw measures derived from the native chroma ? I'm not necessarily saying that's how it should be done - just some food for thought.

    I also ran simultaneous GMSD tests but have yet to collate the data.
    __________________
    Nostalgia's not what it used to be

    Last edited by WorBry; 16th April 2019 at 04:13.
    WorBry is offline   Reply With Quote
    Reply


    Posting Rules
    You may not post new threads
    You may not post replies
    You may not post attachments
    You may not edit your posts

    BB code is On
    Smilies are On
    [IMG] code is On
    HTML code is Off

    Forum Jump


    All times are GMT +1. The time now is 09:56.


    Powered by vBulletin® Version 3.8.11
    Copyright ©2000 - 2019, vBulletin Solutions Inc.
  • 《国家人文历史》往期杂志汇总 2019-04-22
  • 一师一团土地确权登记颁证工作全面展开 2019-04-14
  • 德州扑克赌场披“俱乐部”外衣 打竞技旗号难掩赌博实质 2019-04-12
  • 自治区党委召开常委(扩大)会议 陈全国主持 2019-04-12
  • 17年来首次!塔利班组织宣布停火3天 与阿富汗民众自拍 2019-04-04
  • 2022年冬奥会筹备进行时 2019-04-03
  • 人家80年前就造航母,我们现在才造航母,基础不一样。 2019-04-03
  • 葡萄牙首都上演城市节狂欢 2019-04-01
  • RED EARTH红地球展现自我丝绒唇膏全新发布 2019-03-24
  • 龙船礼 有讲究 百岁龙 抖精神 2019-03-17
  • 新加坡航空将开通 全球最长商业航线 2019-03-17
  • 传说中的自由飞“翔” 当厕所被狂风吹上天 2019-03-12
  • 导游强迫交易获刑 曾辱骂威胁强迫游客消费上万元--旅游频道 2019-03-09
  • 北京正式推出租赁型职工集体宿舍 每间居住人数不超8人 2019-03-09
  • 美元短线拉升 随后回吐涨幅 2019-03-07
  • 极速时时彩计划软件手机版 pk10计划北京赛车 北京赛车pk10稳赢技巧方法 重庆百变王牌规则 昨晚3d彩票开奖号码是多少 今日3d开奖号码 福彩3d和值表 高频彩票有哪些 外围半全场让球怎么算的 江苏时时彩11选五 36选7福利彩票走势图 中国福彩双色球规则中国福彩网首页 幸运飞艇 PK10一天赢100 福建时时彩彩走势图 炸金花游戏