MLV App 1.14 - All in one MLV Video Post Processing App [Windows, Mac and Linux]

Started by ilia3101, July 08, 2017, 10:19:19 PM

Previous topic - Next topic

0 Members and 5 Guests are viewing this topic.

ilia3101

didn't even realise it was baldavenger, I just googled "davinci dctl example" or something

and no this isnt a lut (sorry if i misunderstood what youre saying)

timbytheriver

@ilia3101

Thanks! I don't know how to add that matrix to MLVApp, but I've made a .DCTL from it which Resolve now recognises. But the transform is not correct yet:



Does it maybe require some extra code from the CTL, like:

void main (
input varying float rIn,
input varying float gIn,
input varying float bIn,
        etc...


?


5D3 1.1.3
5D2 2.1.2

ilia3101

The code structure seems different, so no we don't need to add that. But I am not sure why the colours are so wrong. The input to that IDT needs to be in camera raw space.

maybe davinci does channel gains already, so try this:

__DEVICE__ float3 transform(int p_Width, int p_Height, int p_X, int p_Y, float p_R, float p_G, float p_B)
{
const float r = (p_R * 0.883020f) + (p_G * -0.083165f) + (p_B * 0.200145f);
const float g = (p_R * -0.008164f) + (p_G * 1.114861f) + (p_B * -0.106697f);
const float b = (p_R * 0.048320f) + (p_G *-0.441363f) + (p_B * 1.393044f);

return make_float3(r, g, b);
}
[/s]


Ok how about this: https://acescentral.com/t/aces-idt-dctl-generator/2566

timbytheriver

@ ilia3101 Yay! It works. Awesome work. Thank you! :)



That was a 3200K CTL

There's also a 5500K one:


// Canon_5D_Mk_III - 5500K
// Generated on July 15,2019  9:55:47 AM

import "utilities";

const float B[][] = { {0.852627, -0.013844, 0.161217},
  {0.028905, 1.168449, -0.197354},
  {0.057001, -0.365605, 1.308605} };

const float b[] = {2.293205, 1.000000, 1.453861};
const float min_b = min(b[0], min(b[1], b[2]));
const float e_max = 1.000000;
const float k = 1.000000;

void main (
input varying float rIn,
input varying float gIn,
input varying float bIn,
input varying float aIn,
output varying float rOut,
output varying float gOut,
output varying float bOut,
output varying float aOut )
{
float Rraw = clip((b[0] * rIn) / (min_b * e_max));
float Graw = clip((b[1] * gIn) / (min_b * e_max));
float Braw = clip((b[2] * bIn) / (min_b * e_max));

rOut = k * (B[0][0] * Rraw + B[0][1] * Graw + B[0][2] * Braw);
gOut = k * (B[1][0] * Rraw + B[1][1] * Graw + B[1][2] * Braw);
bOut = k * (B[2][0] * Rraw + B[2][1] * Graw + B[2][2] * Braw);
aOut = 1.0;

}



Which I translate as this in DCTL language (Is this correct @ilia3101 ?) It certainly looks correct in Davinci... :P



__DEVICE__ float3 transform(int p_Width, int p_Height, int p_X, int p_Y, float p_R, float p_G, float p_B)
{
const float r = (p_R * 0.852627f) + (p_G * -0.013844f) + (p_B * 0.161217f);
const float g = (p_R * 0.028905f) + (p_G * 1.168449f) + (p_B * -0.197354f);
const float b = (p_R * 0.057001f) + (p_G * -0.365605f) + (p_B * 1.308605f);

return make_float3(r, g, b);
}



Here are the resulting DCTL/IDT files if anyone wants to test: https://bitbucket.org/rivertim/magic-lantern-danneclone/downloads/
5D3 1.1.3
5D2 2.1.2

timbytheriver

Quote
Ok how about this: https://acescentral.com/t/aces-idt-dctl-generator/2566

Oh My God! That looks ****in awesome! Thanks for the great find @ilia3101 And it's only 4hours old. Syncronicity at work. :)

Playtime. :)

PS Hope all this will work with MLVApp also! :P
5D3 1.1.3
5D2 2.1.2

ilia3101

your translation looks about right (given that mine was right :D)

I really don't know anything about davinci resolve ctl so I can't promise anything. Maybe compare it to aces conversion without it.

timbytheriver

Closer examination show a bias towards purple with these DCTLs. Continuing this discussion on the DaVinci Resolve and ML Raw thread here: https://www.magiclantern.fm/forum/index.php?topic=15801.msg225208#msg225208
5D3 1.1.3
5D2 2.1.2

Luther

Quote from: ilia3101 on February 23, 2020, 06:21:06 PM


Very nice. On closer evaluation, I think MKIII has better approximation instead of MKII. The most essential tone (R9 - Red) is out of gamut in MKII, and this tone is crucial for skin tones.

ilia3101

I don't think thats the correct way to look at those pictures. Nothing is out of gamut, the gamut is just reproduced wrongly, especially at the edges (as the pictures show very well). The R9 colour (whatever that is), may by itself be wrong, but skin colour is probably about right on all of these cameras.

Luther

Quote from: ilia3101 on February 26, 2020, 08:22:32 PM
the gamut is just reproduced wrongly
Well, can't that be considered "out of gamut"?
Quotebut skin colour is probably about right on all of these cameras.
Well, these informations have been interpolated for each pixel (mean value between RGGB)? Because the value for Red sensitivity is what actually matter for skin tones, and using the graph above it seems that MKII falls out of the ideal...

ilia3101

Quote from: Luther on February 26, 2020, 08:36:18 PM
Well, can't that be considered "out of gamut"?

I don't know. It will still see the colour, but will reproduce it far too desaturated (wrong).

Is it out of gamut if it is reproduced oversaturated? Like green is on the sony A7?

I once read somewhere that input devices like a camera don't have a gamut, and I still like to think that way.

Quote from: Luther on February 26, 2020, 08:36:18 PM
Well, these informations have been interpolated for each pixel (mean value between RGGB)? Because the value for Red sensitivity is what actually matter for skin tones, and using the graph above it seems that MKII falls out of the ideal...

If you find me some spectral data for reflectance of skin I can calculate how it will look on all of these cameras ;)

Luther

Quote from: ilia3101 on February 26, 2020, 09:05:07 PM
Is it out of gamut if it is reproduced oversaturated?
My undestanding is that "out of gamut" is when a device can't reproduce/capture a particular range of tones (wavelenghts). From the plot above, the reference point for Red would mean the 'ideal' amount of tones... so MKII falls behind it.
I'm not really a color specialist though, so everything I say about this topic is probably innacurate in some way or another.
Quote
I once read somewhere that input devices like a camera don't have a gamut, and I still like to think that way.
It's just a bunch of photodiodes, but when you try to classify that signal inside a gamut for real world usage, this is when things get complicated. This is also why (IIRC) some color spaces have "imaginary colors".
Quote
If you find me some spectral data for reflectance of skin I can calculate how it will look on all of these cameras ;)
Good point. But the low Red sensitivity will affect these tones on MKII. I'm not sure if non-saturated reds would have a big difference, though.

ilia3101

Quote from: Luther on February 26, 2020, 09:53:19 PM
My undestanding is that "out of gamut" is when a device can't reproduce/capture a particular range of tones (wavelenghts). From the plot above, the reference point for Red would mean the 'ideal' amount of tones... so MKII falls behind it.

I don't know. I am not making conclusions from these diagrams because I don't know what to conclude.

Quote from: Luther on February 26, 2020, 09:53:19 PM
I'm not really a color specialist though, so everything I say about this topic is probably innacurate in some way or another.

Same

Quote from: Luther on February 26, 2020, 09:53:19 PM
But the low Red sensitivity will affect these tones on MKII. I'm not sure if non-saturated reds would have a big difference, though.

Non-saturated reds will probably look similar to normal. Cameras seem to reproduce less saturated colours decently, but not saturated ones with spiky spectrums.


Also I used the Adobe daylight matrices, I will see how different these gamuts look with the matrices included in the aces dropbox.

ilia3101




Eyes5D Mark II5D Mark IIISony A7Nikon D810

The Canons here have more accurate green colours.

vstrglv

MLV App does not recognize *.raw files from 5D3 recorded several years ago. Is it possible to convert *.raw to *.mlv?
Thanks in advance.
Canon 5D3,1.1.3; Canon EOS M,202,  CF-SanDisk Extreme PRO,160MB/s, 256GB, SD-SanDisk Extreme Pro, 170MB/s, 128GB.

masc

Quote from: vstrglv on March 03, 2020, 09:52:50 AM
MLV App does not recognize *.raw files from 5D3 recorded several years ago. Is it possible to convert *.raw to *.mlv?
Thanks in advance.
I just know about this workaround: Convert using an old tool RAW to DNG. Then use Ilia's tool RAW2MLV and convert the DNGs to a single MLV file.

Maybe Switch has also an option for such a conversion.
5D3.113 | EOSM.202

vstrglv

Canon 5D3,1.1.3; Canon EOS M,202,  CF-SanDisk Extreme PRO,160MB/s, 256GB, SD-SanDisk Extreme Pro, 170MB/s, 128GB.

Danne

Open up your raw files with Switch. It will ask if you want to convert to mLV file. Thanks to bouncyball for his conversion tool.

vstrglv

Canon 5D3,1.1.3; Canon EOS M,202,  CF-SanDisk Extreme PRO,160MB/s, 256GB, SD-SanDisk Extreme Pro, 170MB/s, 128GB.

ilia3101


Danne



Danne


vstrglv

Quote from: Danne on March 03, 2020, 11:48:52 AM
Open up your raw files with Switch. It will ask if you want to convert to mLV file. Thanks to bouncyball for his conversion tool.
I am on WIN10.  SWITCH_LINUX has been installed on Ubuntu-18.04.4 on VirtualBox-6.1.4-136177-Win. If I drop *.raw file on SWITCH, there is a message "Select your input folder". After selection there are several options, but there is no "you want to convert to mLV file".
Canon 5D3,1.1.3; Canon EOS M,202,  CF-SanDisk Extreme PRO,160MB/s, 256GB, SD-SanDisk Extreme Pro, 170MB/s, 128GB.

Danne

Strange. What does it say? Print screens? You can post additional info in the Switch thread.