View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000343 | Cinelerra-GG | [All Projects] Bug | public | 2019-11-28 12:10 | 2019-11-29 21:46 |
Reporter | MatN | Assigned To | PhyllisSmith | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Platform | X86_64 | OS | Mint | OS Version | 19.2 |
Product Version | |||||
Target Version | Fixed in Version | ||||
Summary | 0000343: Moire visible in HD video | ||||
Description | In a local (private) video Cin-gg (version 2019-10) displays moire. VLC (version 3.0.8) does not. See below for the tests done. Screenshot of particular scene attached. Unfortunately the video itself cannot be shared. | ||||
Steps To Reproduce | Moire test using Cinelerra-gg 2019-10. Hardware: Ryzen 5 2400G. GPU device ID 1002:15dd (from /var/log/gpu-manager.log). Display Samsung 1600x1200 via HDMI. Test video: "Gouda" video produced with Adobe Premiere Pro, 10 Mb/s, resource info detail shows "video1 h264 1920x1080 50.00 pix yuv420p¨. Loaded after cinelerra (re)start as "replace current project". Symptoms: moire best visible in a scene with letters on signpost, but present everywhere. It doesn't matter in compositor window (scaling: auto) or compositor full screen. VLC 3.0.8 displays this perfectly, no moire, even when stopped. Software: Mint 19.2, kernel 5.0.0-36, X11 1.19.6, driver amdgpu, OpenGL renderer AMD Raven Mesa 19.0.8. /lib/firmware/amdgpu updated from git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git , files from git dates 2019-10-04 . This update fixed freezes. But in /lib/firmware/amdgpu the raven firmware files are dates 2019-11-05, likely later updates, automatically applied via the system's update manager. Cinelerra settings: Started from terminal to see errors, restarted between tests or config changes. Performance-> Use HW device: none (to eliminate hardware issues). Settings->format: RGBA-8bit. Screenshots of various tests are attached. 1. Display A = X11 (use direct X11 when possible), cpu load 15%: -> shows the moire 2. Display A = X11 (don't use direct X11 when possible), cpu load 15%: -> shows the moire 3. Display A = X11-XV, cpu load 10%: -> almost gone, still visible when stopped. 4. Display A = X11-OpenGL, cpu load 12% -> almost gone, still visible when stopped (very slightly worse than in test 3). System rebooted to recovery mode (= not using amdgpu driver), OpenGL renderer llvmpipe (LLVM 8.0 128 bits). 5. Display A = X11 (use direct X11 when possible), cpu load 10%: -> shows the moire 6. Display A = X11 (don't use direct X11 when possible), cpu load 10%: -> shows the moire 7. Display A = X11-XV, cpu load 10%: -> shows the moire 8. Display A = X11-OpenGL, cpu load 20% -> almost gone, still visible when stopped (very slightly worse than in test 3). System rebooted to amdgpu mode. Settings->format: RGBA-float. Display-A = X11-OpenGL. 9. Same as test 4, but higher cpu load 25%. Settings->format: YUVA-8bit. Display-A = X11-OpenGL. 10. Same as test 4, but higher cpu load 20%. | ||||
Tags | No tags attached. | ||||
I can answer this question quite simply, Phyllis, experienced craftsmen look for the right tool for the job and not the right job for the tool. | |
@Andrea: I opened BT 0000345 to include other Scaling Equations if in OpenGL video driver mode. You and GG think alike on this -- that is exactly what he said yesterday, i.e. GL should be able to do the other modes too! @Andrew: I put your Note in a text file for GG to review today (but first he has to look at the Zoom/Full Screen BT #34x. @Olaf: the issue is the "cost" in CPU time, etc. because as Andrew states "As more texture elements are sampled in the minification process, fewer aliasing artifacts will be apparent." What price are we willing to pay? Not everyone has a fast computer. |
|
> PhyllisSmith "I do not see that there will ever be a fix." You can't leave that as it is, even if it could be sold at Christmas time as a glittering feature. That's exactly how it's rendered. cgg-comparison.webp (219,116 bytes) |
|
I found this thread on bilinear filtering in shader: https://community.khronos.org/t/manual-bilinear-filter/58504 --quote-- vec4 texture2D_bilinear(in sampler2D t, in vec2 uv, in vec2 textureSize, in vec2 texelSize) { vec2 f = fract( uv * textureSize ); uv += ( .5 - f ) * texelSize; // move uv to texel centre vec4 tl = texture2D(t, uv); vec4 tr = texture2D(t, uv + vec2(texelSize.x, 0.0)); vec4 bl = texture2D(t, uv + vec2(0.0, texelSize.y)); vec4 br = texture2D(t, uv + vec2(texelSize.x, texelSize.y)); vec4 tA = mix( tl, tr, f.x ); vec4 tB = mix( bl, br, f.x ); return mix( tA, tB, f.y ); } --quote-- I think CinGG sets filtering in cinelerra-5.1/guicast/bctexture.C void BC_Texture::bind(int texture_unit, int nearest) (line 199 currently in git) But then I failed to track where it called exactly :/ Documentation for filtering parameters: https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glTexParameter.xml As more texture elements are sampled in the minification process, fewer aliasing artifacts will be apparent. While the GL_NEAREST and GL_LINEAR minification functions can be faster than the other four, they sample only one or four texture elements to determine the texture value of the pixel being rendered and can produce moire patterns or ragged transitions. The initial value of GL_TEXTURE_MIN_FILTER is GL_NEAREST_MIPMAP_LINEAR. But for magnification only GL_NEAREST/GL_LINEAR supported, no mipmaps here. I can try and dig other algorithms, for bicubic/Lanczos filtering in shaders.... http://www.java-gaming.org/index.php?topic=35123.0 - Bicubic in GLSL 1.30 (OpenGL 3.0) https://gitlab.com/higan/xml-shaders/tree/master/shaders/OpenGL/v1.0 some shaders named Lanczos (4/6 tap) |
|
> If the video driver is X11 OpenGL, Nearest Neighbor is always used. However, if you use the X11 video driver, you have 5 choices of Nearest Neighbor, BiCubic / BiCubic, BiCubic / >BiLinear, BiLinear/ BiLinear, and Lanczos / Lanczos Good information; I think we should include it in the manual because I always thought that the various algorithms applied to all video drivers. In any case, the "nearest neighbor" is the worst scaling algorithm of all. Is it possible to implement the others for X11-opengl? I think it's the most used one. |
|
Yes, as Olaf says, problem caused by scaling and I do not see that there will ever be a fix. All of the video presentations are just little, itty, bitty images on a monitor in the first place -- although apparently VLC somehow compensates. Thanks for such a thorough explanation and testing. GG looked at the images attached and here is what he says. "Images are displayed on the Compositor in either of 2 ways - 1 is a direct "transfer" using "nearest neighbor" and in theory this is done with "no scaling". But in many cases and when plugins are involved, the 2nd way is via the "overlays" routine; and this is where there is scaling to get the image displayed as best as can be done. If the video driver is X11 OpenGL, Nearest Neighbor is always used. However, if you use the X11 video driver, you have 5 choices of Nearest Neighbor, BiCubic / BiCubic, BiCubic / BiLinear, BiLinear/ BiLinear, and Lanczos / Lanczos in Settings->Preferences, Playback A tab, to the right of "Scaling Equation: Enlarge / Reduce". It seemed to us that at least the BiLinear or BiCubic improved the looks for less of a moire pattern. |
|
Try it with a magnification of "x 1.0" in Composer. The Moire, if not already present in the raw material, is created by the scaling compensation. | |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-11-28 12:10 | MatN | New Issue | |
2019-11-28 12:10 | MatN | File Added: Gouda_cin201910_x11_2019-11-28_11-32-10.png | |
2019-11-28 12:10 | MatN | File Added: Gouda_cin201910_x11-opengl_2019-11-28_11-32-10.png | |
2019-11-28 12:10 | MatN | File Added: Gouda_cin201910_x11-xv_2019-11-28_11-32-10.png | |
2019-11-28 12:10 | MatN | File Added: Gouda_vlc308_2019-11-28_11-32-10.png | |
2019-11-28 14:23 | Olaf | Note Added: 0002503 | |
2019-11-29 00:32 | PhyllisSmith | Note Added: 0002507 | |
2019-11-29 00:32 | PhyllisSmith | Assigned To | => PhyllisSmith |
2019-11-29 00:32 | PhyllisSmith | Status | new => acknowledged |
2019-11-29 08:38 | Andrea_Paz | Note Added: 0002508 | |
2019-11-29 11:05 | Andrew-R | Note Added: 0002509 | |
2019-11-29 14:20 | Olaf | File Added: cgg-comparison.webp | |
2019-11-29 14:20 | Olaf | Note Added: 0002510 | |
2019-11-29 19:37 | PhyllisSmith | Note Added: 0002512 | |
2019-11-29 21:46 | Olaf | Note Added: 0002513 |