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. |
4th December 2019, 15:25 | #41 | Link |
Registered User
Join Date: Nov 2017
Posts: 12
|
Sorry, my problem from the previous post is not related to this topic. I found this setting in the VapourSynth Editor - https://i3.imageban.ru/out/2019/12/0...c97d14d8c2.png
In AvsPmod the color matrix is determined based on the resolution of the clip, by default - https://i5.imageban.ru/out/2019/12/0...8b1eb17255.png I completely forgot about it, so I did not think that the problem was in the preview. Initially, I found a problem when using another VS-script viewer, in which there is no choice of colors matrix for viewing. I switched between the clip after deinterlacing and the clip where avsw.Eval goes next. |
4th December 2019, 18:24 | #42 | Link |
Registered User
Join Date: May 2011
Posts: 321
|
Yes, same old quantum physics principle - you look at YUV values only to see different 8bit RGB values. :-) So looking at it, you never see a real thing.
RGB preview values next to those real YUV values in VapourSynth Editor could help regarding these issues, because one could notice the same YUV values for both videos but different RGB values for preview. Or to always change your YUV to RGB24 or COMPATBGR32 yourself before preview where typing that mandatory matrix_in value would strike you right away as well. Code:
rgb = core.resize.Point(clip, format = vs.COMPATBGR32, matrix_in_s = '470bg') Code:
kernel = "Point" # chroma resampling filter in its menu, besides other parameters - chroma placement, b,c,tap parameters omitted in this example matrix_in_s = "470bg" # in the settings menu as matrix coefficients _resize = getattr(core.resize, kernel) rgb = _resize(clip, format = vs.COMPATBGR32, matrix_in_s = matrix_in_s) stride = rgb.get_frame(frame_number).get_stride(0) #to get one frame 305 for example: img = QImage(rgb.get_frame(305).get_read_array(0), rgb.width, rgb.height, stride, QImage.Format_RGB32).mirrored() #it is 8bit Qt image format #also Format_RGB32 in Qt means four 8bit interleaved planes with alpha, vapoursynths' COMPATBGR32 equivalent, so it is 8bit pix = QPixmap.fromImage(img).scaled(scale_w, scale_h, **modes) #getting 8bit Qt pixmap that is emited on screen #if not zooming -> scale_w, scale_h are the same as resolution -> exactly same values #modes = {'aspectRatioMode':Qt.KeepAspectRatio,'transformMode':Qt.FastTransformation} #that modes is in the vs editor menu as well, above scripted modes means nearest resize in Qt, that one you want to investigate true RGB equivalents of YUV pixel values Last edited by _Al_; 4th December 2019 at 18:57. |
5th December 2019, 06:57 | #43 | Link | ||
Registered User
Join Date: Nov 2017
Posts: 12
|
_Al_, thank you for the explanation.
With Code:
rgb = core.resize.Point (clip, format = vs. RGB24, matrix_in_s = '470bg') With Code:
rgb = core.resize.Point (clip, format = vs. COMPATBGR32, matrix_in_s = '470bg') Quote:
Quote:
|
||
5th December 2019, 17:16 | #44 | Link |
Registered User
Join Date: May 2011
Posts: 321
|
That RGB24 or COMPATBGR32 conversion is just for preview, to make sure yourself, what's going on, to bypass vsedit Preview or any other software preview conversion to RGB, to avoid setting defaults for matrix or pulling them from menu:
Code:
import vapoursynth as vs from vapoursynth import core clip = core.std.BlankClip(width=200, height=200, color=[220, 0, 20]) matrix = core.resize.Bicubic(clip, format=vs.YUV420P8, matrix_s="470bg") avs = core.avsw.Eval("trim(0,0)", clips=[matrix], clip_names=["last"]) avs_preview = core.resize.Point (avs, format = vs. COMPATBGR32, matrix_in_s = '470bg') #or vs.RGB24 avs_preview.set_output(0) #just for preview in RGB 8bit so previewer does not uses matrix for conversion avs.set_output(1) #for encoding: vspipe --outputindex 1 script.vpy - --y4m | x264 .... #or both for preview as well if you have some previewer that can switch between outputs #or Previewer that accepts clip arguments: #Preview([avs_preview, avs]) #Preview([vs.get_output(0), vs.get_output(1)]) As for that comparison , as I said, I cannot confirm that, I have the same colors in all cases. But I thought, you sorted that out by using proper Matrix in vs editor menu or some other (by the picture). Just use that script I just posted and load both outputs or switch between outputs. If color is different then that viewer us using wrong matrix for that YUV output. And if both outputs are wrong, then at least we know , it is not a matrix issue with preview, I have no idea what that would be. Last edited by _Al_; 5th December 2019 at 18:03. |
6th December 2019, 06:57 | #45 | Link | ||
Registered User
Join Date: Nov 2017
Posts: 12
|
Quote:
No, before avsw.Eval(). I just did not check that the option of inserting this line after "avsw.Eval ()" will work. Quote:
avs_preview.set_output avs.set_output Now I just replaced the line Code:
avs = core.avsw.Eval("trim(0,0)", clips=[matrix], clip_names=["last"]) Code:
avs = core.std.Trim(matrix, 0, matrix.num_frames-1) avs_preview.set_output avs.set_output I’m just wondering why in the first case I see color changes, but in the second I don’t see |
||
6th December 2019, 07:47 | #46 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
@vkusnyashka-
If you are using vsedit, it has to do with the frame props assigned. That's what it's using for the preview. The preview settings are only used if there are no frame props , no metadata or "unknown" Whenever it passes through avsw.Eval, it loses the frame props In the second case, replacing with internal std.Trim retains the frame props from the previous matrix. You can see this with avs = core.text.FrameProps(avs) , where matrix is "5" now (which is bt470bg). So that is used for the RGB conversion for the preview, not the editor settings. So both left (where you forced 470bg) and right (using props) should and do look the same In the first case, the left side "avs_preview" specified 470bg for RGB conversion,"avs" did not and has no props assigned (it "lost" them through avsw.Eval), therefore it uses the settings in the editor. So you get expected difference in color for the preview since it's set to 709. Note in both cases the actual values in YUV are the same, only the RGB converted preview representation is changed |
6th December 2019, 09:20 | #47 | Link |
Registered User
Join Date: May 2011
Posts: 321
|
vkusnyashka - I had persistence in color results because if using vsedit for preview I had in Advanced settings always proper matrix coefficients.
Then you'd have same colors even after going from avsw.Eval() and it looses '709' - that's a good catch! So pdr says you should do this to reset that proper matrix again (if not making sure in that menu for setting matrix or making RGB for preview yourself): Code:
avs = core.avsw.Eval("trim(0,0)", clips=[matrix], clip_names=["last"]) avs = core.std.SetFrameProp(avs, prop="_Matrix", intval=1) #1 for '709' or 5 if '470bg' avs.set_output(0) matrix clip has these props if set to '709': Code:
_ChromaLocation 0=left _ColorRange 1=limited range _DurationDen 24 _DurationNum 1 _Matrix 1=709 _Primaries 2=unspec _Transfer 2=unspec another follow up idea is to paste some props from that matrix clip back to the new avs clip, but that could be kind of redundant even dangerous (avs script can change things) because you write that script and you know what those props are if needed in script Code:
import vapoursynth as vs from vapoursynth import core def copy_property(n, f): fout = f[1].copy() props = ['_Matrix', '_ChromaLocation', '_Primaries', '_Transfer'] for prop in props: try: fout.props[prop] = f[0].props[prop] except: pass return fout clip = core.std.BlankClip(width=200, height=200, color=[220, 0, 20]) matrix = core.resize.Bicubic(clip, format=vs.YUV420P8, matrix_s="709") avs = core.avsw.Eval("trim(0,0)", clips=[matrix], clip_names=["last"]) avs = core.std.ModifyFrame(avs, clips=[matrix, avs], selector=paste_property) avs.set_output(0) Last edited by _Al_; 6th December 2019 at 10:23. |
3rd February 2023, 10:23 | #49 | Link | |
Registered User
Join Date: Dec 2014
Posts: 36
|
I plan to use the avs script Avisynth AiUpscale v1.2.0 within vs (https://forum.doom9.org/showthread.p...le),but failed。
Quote:
Last edited by gmail123; 3rd February 2023 at 11:17. |
|
3rd February 2023, 10:25 | #50 | Link | ||
Registered User
Join Date: Dec 2014
Posts: 36
|
but,my vs script(32bit avs dll) :
Quote:
Quote:
Last edited by gmail123; 3rd February 2023 at 10:28. |
||
3rd February 2023, 14:59 | #52 | Link | |||
Registered User
Join Date: Dec 2014
Posts: 36
|
modify:
Quote:
Quote:
Quote:
Last edited by gmail123; 3rd February 2023 at 15:04. |
|||
3rd February 2023, 15:49 | #54 | Link | ||
Registered User
Join Date: Dec 2014
Posts: 36
|
Quote:
Quote:
|
||
3rd February 2023, 15:58 | #55 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
AVISource won't work for the order that you have that script. AVISource can only load .avs scripts in a .vpy script as the output node of the avs script, so it must be first filter in the vpy script. You cannot apply in the middle of a vpy script If you use scunet, then avs aiupscale, you would need to import the vpy into the avs script eg. using vapoursoursce, then apply aiupscale, then import that back into the vpy. The problem is RGBS cannot be sent through vapoursource - not a supported pixel format. (vs-scunet requires RGBS or RGBH). So you'd have to downconvert after scunet in the vpy script output node, (before vapoursource in the avs script) to a supported pixel format in the AIUpscale avs script . I would use the output node of avisynth instead of sending back to vapoursynth in that case. All the piping has overhead (slow) Last edited by poisondeathray; 3rd February 2023 at 16:06. |
||
3rd February 2023, 16:03 | #56 | Link | |
Registered User
Join Date: Dec 2014
Posts: 36
|
Quote:
|
|
|
|