alexmitchellmus's picture

@alexmitchellmus

I made a donation to Vuo.

Compositions

4 years ago
4 years ago
4 years ago
4 years ago
alexmitchellmus's picture
alexmitchellmus posted a new Feature Request, “Linear RGB data type

Linear RGB data type

Currently Vuo does not understand the difference between RGB that is in linear - or has an OETF (gamma) applied.

Attached is an example composition that shows the difference between the two- when using a blur.

I suggest that there be a linear data cable type, which can be converted easily. No image processing (compositing, blur, etc) should happen to the data when their is an OETF on the data.

This would mean that Vuo would need to read the ICC profile of the image, and remove the EOTF based on the tags. (And also allow the user to convert from known colour spaces - sRGB, P3, rec.2020 etc) https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html

This is clearly shown in a blur effect, with an image with saturated colours.

Simply because x^2 + x^2 != (x+x)^2

Here are two screenshots from the attached Vuo composition, note that in both the blur effect is identical, the only difference is the top one has: OETF removed -> Blur -> OETF applied.

NOTE: for the attached example composition- I am using the approximation of pow(src, 2.2) for sRGB OETF

Notes from Team Vuo

Complexity: 

●●○○ — A few weeks of work

Potential: 

●○○ — Appeals to current community

Currently, Vuo's colors and textures use the sRGB colorspace. Our overall goal for Vuo is to make it easy for people to get professional results, without having to master underlying technical details. So, we'd like to approach this a bit differently.

Our plan would be to audit Vuo's image filter nodes and figure out which ones handle colorspace properly as-is, and which ones don't (presumably blur is one that doesn't), and fix the ones that don't (i.e., make them convert input textures from sRGB to linear (when necessary), perform the filter, then convert linear back to sRGB (when necessary)). We think ideally this should all happen automatically so composition authors don't need to worry about it. Part of the fix would be to add an "Apply ICC Profile" node, to facilitate advanced color management.

alexmitchellmus's picture
alexmitchellmus commented on Paul's Discussion, “Equirectangular camera

Paul, the reason for forcing 2:1 is that that is the official format aspect ratio.

Personally I don't mind either way, as it can be changed to a degree afterwards. Also, equirectangular isn't really the best format for storage of 360°. As you would be aware the poles become distorted, and have excessive resolution, with heavy antialiasing.

alexmitchellmus's picture

IIRC dual fisheye will always have errors around the perimeter. Hence the need to go with a 90° cubemap rendering.

I think this is what the current Vuo2 code does, but I haven't had time to check.

alexmitchellmus's picture

Ardour is a GPL DAW that has ability to split buffers. Hence why all LV2 plugins always need to know the buffer size (not the sample rate, that's set).

This allows as you said, a buffer to work with timming that are between buffers.

I don't know how this would work in a live context, as Vuo would need to know in advanced where when to split the buffer. Which would mean that all incoming data (MIDI/OSC/controll) would need to be delayed by one buffer cycle.

I think that would be ok, given the benefit it would bring.

Pages