- Cin - Cinelerra-GG Mailing Lists

Rendering, encoding and decoding with Nvidia
by David Koski 15 Nov '23

15 Nov '23

I've started using CinGG-20230930-x86_64.AppImage and I'm getting the hang of the basics. I have gotten my nvidia hardware engaged with Cinelerra for encoding but still the rendering is not all that great and my CPUs are loaded down. On finding that I need environment variables to engage decoding, I thought maybe that is hindering my rendering. So with the following setting I started a rendering job: export CIN_HW_DEV=vdpau Now I get an error: recvmsg(22, Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory libvdpau is installed: ii libvdpau-va-gl1 0.4.2-1build2:amd64 VDPAU driver with OpenGL/VAAPI backend ii libvdpau1 1.4-3build2:amd64 Video Decode and Presentation API for Unix (libraries) The files exist: drwxr-xr-x 21 root root 4096 Nov 1 19:29 /./ drwxr-xr-x 154 root root 12288 Nov 8 21:08 /etc/ -rw-r--r-- 1 root root 51 Apr 9 2020 /etc/vdpau_wrapper.cfg drwxr-xr-x 14 root root 4096 Mar 8 2023 /usr/ drwxr-xr-x 118 root root 4096 Nov 9 20:40 /usr/lib/ drwxr-xr-x 125 root root 122880 Nov 8 21:08 /usr/lib/x86_64-linux-gnu/ lrwxrwxrwx 1 root root 17 Mar 24 2022 /usr/lib/x86_64-linux-gnu/libvdpau.so.1 -> libvdpau.so.1.0.0 -rw-r--r-- 1 root root 18592 Mar 24 2022 /usr/lib/x86_64-linux-gnu/libvdpau.so.1.0.0 drwxr-xr-x 2 root root 4096 Sep 30 09:40 /usr/lib/x86_64-linux-gnu/vdpau/ lrwxrwxrwx 1 root root 23 Mar 24 2022 /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_trace.so.1 -> libvdpau_trace.so.1.0.0 -rw-r--r-- 1 root root 59544 Mar 24 2022 /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_trace.so.1.0.0 drwxr-xr-x 306 root root 12288 Nov 8 21:08 /usr/share/ drwxr-xr-x 145 root root 4096 Nov 8 21:07 /usr/share/bug/ -rwxr-xr-x 1 root root 553 Jan 6 2021 /usr/share/bug/libvdpau1* drwxr-xr-x 2302 root root 81920 Nov 8 21:08 /usr/share/doc/ drwxr-xr-x 2 root root 4096 Jul 27 09:19 /usr/share/doc/libvdpau1/ -rw-r--r-- 1 root root 1447 Mar 24 2022 /usr/share/doc/libvdpau1/changelog.Debian.gz -rw-r--r-- 1 root root 3208 Jan 6 2021 /usr/share/doc/libvdpau1/copyright Regards, David Koski david(a)kosmosisland.com

5 10

Re: [Cin] Cinelerra-GG packages build farm
by Phyllis Smith 13 Nov '23

13 Nov '23

This is very much appreciated as there are some definite advantages to having packages as opposed to the appimage -- in my opinion the most beneficial is the ability to get the updates applied automatically when there is a new version available (if enabled by the user). I assume it is OK for me to add this to the manual in the section: Distro with CINELERRA-GG Included . On Sun, Oct 8, 2023 at 5:14 AM Андрей Спицын <spitsyn.andrey(a)gmail.com> wrote: > Hello Phyllis and everyone, > > I've created a build farm for cinelerra deb and rpm packages. Although it > is at an early stage of development, it can build packages on every git > change in the main repo. Feel free to use these packages at > https://github.com/einhander/cin-gg-packages/releases. Note that releases > correspond to a build date, not a git commit date. > Current build hosts are debian 12 and alma linux 8. I'm open to > suggestions for a new distro and packages. > > > Best regards, > Andrey Spitsyn >

4 10

openexr test images
by Andrew Randrianasulu 11 Nov '23

11 Nov '23

https://openexr.com/en/latest/_test_images/index.html esp. https://raw.githubusercontent.com/AcademySoftwareFoundation/openexr-images/… where description says "This RGB image contains a number of rather bright rings, with pixel values over 1000, on a gray background. The image is useful for testing how filtering and resampling algorithms react to high- dynamic-range data. (Some filters, for example, convolution kernels with negative lobes, tend to produce objectionable artifacts near high-contrast edges.) Note that the rings in the image are smooth, although on most displays clamping of the pixel values introduces aliasing artifacts. To see that the rings really are smooth, view the image with and exposure of -10."

1 0

Fwd: [heroineworshiper/hvirtual] question about clipping in Histogram plugin (Issue #8)
by Andrew Randrianasulu 11 Nov '23

11 Nov '23

well, Andrea, can I copy your email to GitHub issues or you prefer to explain it there yourself? I think your use case goes a bit beyond just testing and into actual workflow category? ---------- Forwarded message --------- От: Adam Williams <notifications(a)github.com> Date: пт, 10 нояб. 2023 г., 21:16 Subject: Re: [heroineworshiper/hvirtual] question about clipping in Histogram plugin (Issue #8) To: heroineworshiper/hvirtual <hvirtual(a)noreply.github.com> Cc: Andrew Randrianasulu <randrianasulu(a)gmail.com>, Author < author(a)noreply.github.com> The big problem with histogram is histograms are expected to clamp. The graph has to be changed to show a Y range beyond 0-1, you need some more parameters to define min & max Y. You could make a new histogram plugin which implemented the new options. It gets a bit bloated so the question is again why you need histogram to support more than 0-1? Sent: Thursday, November 09, 2023 at 11:14 AM From: "Andrew Randrianasulu" ***(a)***.***> To: "heroineworshiper/hvirtual" ***(a)***.***> Cc: "Adam Williams" ***(a)***.***>, "Comment" ***(a)***.***> Subject: Re: [heroineworshiper/hvirtual] question about clipping in Histogram plugin (Issue #8) A case of is it worth the effort to support values <0 & >1 & the answer was no. If you can find a good reason & actually fix everything including the opengl functions no-one uses, maybe it could work. well, I looked into playback3d.C and some shaders there surely uses clip? But biggest problem for me I do not know how to init fp32 fbo/pbo, so it all remained clipped. But just switching textures to 32f made big difference with test file Andrea provided and fade out. https://www.youtube.com/watch?v=7GOhtJciHBk I tried to follow advice given in https://community.khronos.org/t/glx-ati-pixel-format-float-under-linux/4768… (but using more modern GLX_RGBA_FLOAT_BIT_ARB). use-case is exr/tiff from some photography software or rasterizer, where values > 1.0f exist. (ffmpeg seems to convert most/all video to integer formats, but may be in last ffmpeg they added it - https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/479747645f795b6f4f376578ea1… - "avutil/pixfmt.h: add native-endian RGB32F and RGBA32F formats") — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***(a)***.***> — Reply to this email directly, view it on GitHub <https://github.com/heroineworshiper/hvirtual/issues/8#issuecomment-18061989…>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJSS7TJ5T7MREFWQWTBCADLYD…> . You are receiving this because you authored the thread.Message ID: <heroineworshiper/hvirtual/issues/8/1806198961(a)github.com>

2 7

Clipping to 1.0 investigation.
by Andrew Randrianasulu 09 Nov '23

09 Nov '23

I tried cingg compiled on Nov, 1 2020 and issues still here - you need native exr reader to see it with Andrea's sample. Either by compositor's vectoroscope or color picker - in clipping case it will show 1.0 for much of window area, in non-clipping mode (no plugins) it will show up to 60.something in rgb channels! Sadly, 2018 version had no vectoroscope on compositor, need to double-test if native exr reader + any plugin will fail there in the same way via color picker.....

3 15

Trying to understand colour, try N!
by Andrew Randrianasulu 09 Nov '23

09 Nov '23

https://blender.stackexchange.com/questions/46825/render-with-a-wider-dynam… well, this one says EXR can hold quite a big value per channel, way above 1.0f, obviously. But for displaying (and encoding?) it must be compressed back to device-specific 0 - 1.0 range. Thing is, if I open exr example file in gimp 2.10 and re-export it - it retain its above 100% values. It does not do this if I do this same roundtrip via cingg. So yea, we seems to be clamping at output. Still not sure where, may be in fader? (where fade can't be more than 100%) . May be its time to ask Lion (Adam).

3 12

GIT check in of Tiff 4.6.0
by Phyllis Smith 08 Nov '23

08 Nov '23

Updated tiff from 4.5.0 to 4.6.0 and checked into GIT. Ran 2 render tests of different video files and loaded a bunch of previously created .tif files with no seen anomalies. (I should have tested on Ubuntu 16 and Debian 32-bit also, but will do so tomorrow). Tried to update libjpeg-turbo from 2.1.5.1 to 3.0.1 but having Errors in building which I have not figured out yet but will keep trying.

3 3

Floating point numbers between 0 and 1.0
by Andrew Randrianasulu 08 Nov '23

08 Nov '23

https://stackoverflow.com/questions/17949796/how-many-unique-values-are-the… ppl here come up with this number: 1,065,353,215. so ... even between 0.0f and 1.0f there is quite a number of ... numbers. Still, out of range numbers useful in photo work like here https://ninedegreesbelow.com/photography/gimp-tone-map-with-levels.html found via bugzilla bug filled for gimp: https://bugzilla.gnome.org/show_bug.cgi?id=737925 "*Bug 737925* <https://bugzilla.gnome.org/show_bug.cgi?id=737925> - Some filters / operations provide float values superior to 1.0" on CinGG plugins I found only exactly one instance of clamp line as Andrea suggested: grep "CLAMP(output, 0, 1.0)" -r plugins plugins/histogram/histogram.C: CLAMP(output, 0, 1.0); plugins/histogram/histogram.C: CLAMP(output, 0, 1.0); and nothing more.

2 1

oiiotool
by Andrew Randrianasulu 08 Nov '23

08 Nov '23

oiiotool --stats -v /dev/shm/1.exr Reading /dev/shm/1.exr /dev/shm/1.exr : 4096 x 2048, 3 channel, float openexr channel list: R, G, B chromaticities: 0.639999, 0.33001, 0.300004, 0.600003, 0.150002, 0.0599972, 0.3127, 0.329 compression: "zip" PixelAspectRatio: 1 screenWindowCenter: 0, 0 screenWindowWidth: 1 oiio:ColorSpace: "Linear" oiio:subimages: 1 Stats Min: 0.005371 0.006256 0.006348 (float) Stats Max: 117.000000 106.500000 104.500000 (float) Stats Avg: 0.746420 0.699325 0.674529 (float) Stats StdDev: 3.869811 3.841790 3.957525 (float) Stats NanCount: 0 0 0 Stats InfCount: 0 0 0 Stats FiniteCount: 8388608 8388608 8388608 Constant: No Monochrome: No this is for gimp exported EXR cingg exported tiff says: Reading /dev/shm/1.tif /dev/shm/1.tif : 4096 x 2048, 4 channel, float tiff channel list: R, G, B, A compression: "zip" Orientation: 1 (normal) planarconfig: "contig" oiio:BitsPerSample: 32 tiff:Compression: 32946 tiff:PhotometricInterpretation: 2 tiff:PlanarConfiguration: 1 tiff:RowsPerStrip: 1 tiff:UnassociatedAlpha: 1 Stats Min: 0.265371 0.266256 0.266348 1.000000 (float) Stats Max: 1.000000 1.000000 1.000000 1.000000 (float) Stats Avg: 0.630706 0.600794 0.582030 1.000000 (float) Stats StdDev: 0.221808 0.214916 0.202718 0.000000 (float) Stats NanCount: 0 0 0 0 Stats InfCount: 0 0 0 0 Stats FiniteCount: 8388608 8388608 8388608 8388608 Constant: No Monochrome: No ==== example usage from https://openimageio.readthedocs.io/en/latest/oiiotool.html wow, so oiiotool in itself a bit like imagemagick :) might make preparing some image sequences easier ... also, guess we better to note in manual that even if cingg outputs fp32 exr/tiff values there are normalized to 0-1.0f as far as we can see.

2 4

gimp 2.10 and exact small color values
by Andrew Randrianasulu 08 Nov '23

08 Nov '23

https://superuser.com/questions/1411132/manually-entering-16-bit-color-valu… ==== So, forgetting about setting the FG color, *the way to create a surface with a precision smaller than 1/256 in any component in GIMP 2.10 is using the painting or color tools*. You can do this, and use the color-picker tool to check for success: 1. use at least 16bit precision 2. fill an image with black; 3. Set your foreground color to the lowest possible graylevel (010101 hex color on the color dialog) 4. use, for example, the bucket-fill tool and set the opacity to desired level (25% for 1/4 of 1/256 gray, (1/1024 gray)). 5. Use the color picker tool to check if you got to the desired level (1/1024 gray will show 0.000076 for each component - while the 8 bit gray #010101 is 0.000304 for each component). 6. Convert the image to "16 bit integer precision" back *before* exporting to .PNG file - I further tested and found out that attempts to save a 32bit FP precision image as a PNG file will result in an 8bit png file (all work above is lost). But if the image on GIMP is 16bit integer, then the PNG export generates a correct 16bit PNG. (Saving as native .xcf file format will preserve the precision, of course) ==== not sure if bug (IMO) in #6 was fixed or not .... well, it seems back in 2019 trick was to use layer math, too ... found via https://discuss.pixls.us/t/gimp-color-picker-values/5571/20

1 0