- Cin - Cinelerra-GG Mailing Lists

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 07 Nov '23

07 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 07 Nov '23

07 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 07 Nov '23

07 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

more vfx from reddit, exr, linearization
by Andrew Randrianasulu 07 Nov '23

07 Nov '23

https://www.reddit.com/r/vfx/comments/ptk6ej/confusion_about_floating_point… well, I think this answer answers it ... Q first: ===== Confusion about Floating Point in Color Space Transforms/Management from Learning <https://www.reddit.com/r/vfx/?f=flair_name%3A%22Learning%22> Dear VFX Gurus/Professionals, I am not a VFX person at all. My question is more from a Color Management standpoint. And seeing how VFX artists follow the same rules as colorists(I'm not really a colorist either just someone who developed a bit of a hobby recently) in color management and equally have to deal with the confusing physics of light, I was wondering if you fine people could enlighten me. To explain my confusion I'm going to use an example of a hypothetical camera sensor which CLIPS White at a max 1000% scene linear reflectance and crushes blacks at 0% light (I know there is no such thing as 0% light but it just makes the numbers easier to deal with). I've attached below a Hypothetical 10bit Log Transform and a 16bit Linear RAW graph of the Input of Linear Light and Code value output(The so called OETF). The output values are both in Code Value (and Normalized from 0-1) {img omitted} Now, as far as I understood, when the 10bit Log encoded image goes through a Color Space Transform the first thing that happens to it is that it gets "Linearized" to a 32bit Floating Point(This is part of the IDT or Input Transform in Davinci Resolve or in the case of ACES VFX workflow, 16bit half float) before any other thing happens to it. Now, I'm not a software developer or video engineer or anything of that sort but having read about Floating Point(which is much more confusing than integer values) it's been said that Floating Point allows for OUTPUT values greater than 1 and less than 0. The problem I'm having is understanding how does this relate to Scene Linear Reflectance getting matched to the output in Linear Floating Point? For instance is 100% light reflectance giving an output of 1(the highest possible value in integers)? Does a 500% reflectance give an output of 5?What about 1000% reflectance, would that be an output of 10 and would the graph end there?? Or am I completely way off and 1000% reflectance would still be an output of 1, just that between 0 and 1 there'd be approximately 4 billion values worth of data(then what's the point of having values greater than 1 and less than 0?) The thing that's tricking me is that the entire dynamic range of the camera gets squeezed into a 0-1 output range in the integer encoded camera files, but I can't understand what's happening with it when it becomes a Linearized 32bit Floating Point. On the one hand everyone says these (ACES Linear Gamma or Davinci Wide Gamut) are HDR workflows but the problem is everyone just uses 0 and 1's for their light inputs and for their outputs when they're showing the graphs. For all I know an Input of 1 could just mean a Reflectance of 100%(just like in Linear RGB) or it could mean a 1,000,000% reflectance(Which is indeed MEGA-HDR). And what of the outputs potentially being greater than 1 and less than 0(What does that even mean?) I'll admit I haven't really tried to truly understand Float Point Operations, perhaps that's where I am failing. How is this 32bit Floating Point any different than the Linear RAW(Other than it being 32 bit Float rather than 16 bit?). Are they exactly the same with the only difference being there is an infinitely bigger amount of data values between Output 1 and 0(which linearly maps 0 - 1000% light reflectance)? What's the significance of having Output values greater than 1 and less than 0? Just very lost on this. And yes I have read multiple articles on this(Chris Brejons, ACES Manual, etc...) but the lightbulb isn't turning on for some reason. Feel free to correct me since as an amateur I definitely need guidance. Thanks ===== Welcome to the fun of colorspace. The whole thing is a pain. I've set up some facility level color pipelines (camera to broadcast), and even when you have a decent grasp of it, it's still basically a nightmare. A properly linearized image, rendered to EXR, will show values greater than 1, in my example earlier, they'd read 13-16 and everything in between. that's what half float (16) and float (32) allow to happen. But, and this is a big one, most container formats can't support values over 1. So historically LOG images have always been encoded with a LOG curve to jam their data into that 0-1 range. So it's important to note which colorspace transform has been applied to create the output image. Nuke makes it explicit to the format type, Resolve defaults to gamma 2.4 unless otherwise changed at the project level. The note above about reading in RAW, IIRC, is to make sure all the data is pulled in (no clipping) and then the correct colorspace transform is applied in app, pushing the super white values above 1. This was done for a couple reasons, a) to again keep all the data, and b) to allow any legal -> full range expansion before applying the colorspace move. It's less prevalent now, but there used to be a workflow where the camera SDI was outputting a legal feed, and the outboard capture decks were were also applying a full -> legal transform, creating master files that were double legalized. A lot of folks still render EXR with the LOG curve applied, so it's still technically 0-1 range. This is also the safest way for VFX vendors because if we reapply the same log curve on export, when it gets to the color house it will be apples to apples the same regardless of how they linearize (same as source). In theory the best practice would be to linearize the footage and leave it linear, but in reality that's problematic, as each software suite uses slightly different math to linearize. ACES color management is meant to solve this, but again most folks don't actually work in ACES correctly, to be fair most folks don't manage color is Resolve correctly either though. Also, I've seen this a few times, depending on where you start, I've noticed that some people speak in opposite jargon. IE when they say "log" they mean "was log, has been linearized" and when they say "linear" they mean flat raw log. When I refer to footage as log I mean very flat looking camera native, and when I say linearized I'm referring to footage that looks much closer to how we would see it if we were there on the day. ==== quote end ===== So .... it seems to be software-dependent what kind of values it can put in fp32 EXRs ....

1 0

Plugins in integer or in float
by Andrea paz 06 Nov '23

06 Nov '23

>From the source code we can tell if a plugin works in 32 bit float or 8/10 bit integer? I don't know, maybe by searching for the string "float" in the code or something like that? Or the normalized range (0-1.0) instead of the range (0-255), etc. It would be important to put this information in the manual because, for example, I know that Histogram works with integers and this can lead to clipping (with loss of information) in highlights or deep blacks. In contrast, Blue Banana works in floats.

3 17

Blue Banana, again
by Andrea paz 04 Nov '23

04 Nov '23

The revision of the manual on the plugin chapter is not yet finished, and for that I apologize to everyone, especially Phyllis for the extra workload. I have added tips to Blue Banana and made minor corrections. But I have left untouched the parts that I don't understand well and that don't seem clear to me. If anyone can suggest improvements I would be grateful. I also attach the txt that contains the additions, but they do not show where I put them in the manual. Also in these, if you find errors in them, please report it to me.

2 3

No release this month
by Phyllis Smith 31 Oct '23

31 Oct '23

Since the only change is an update of libvpx from 1.13.0 to 1.13.1, there is no new release this month. This library update includes a fix for a vulnerability so users who do their own build may want to consider using the latest GIT for a new build..

1 0