Messages

Hihi, does anyone have any advise on the best workflow of color grading .dng files in davinci resolve? Thank you!

If you have the MLV files, try MLVApp instead. If not, try to use ACEScct inside Resolve...

@Luther Nice to hear from you again! This attempt is going much better, way more simple. Should be able to do a release quite soon.

Also thanks again for all the links you have sent since whenever you started. I looked back at that RawToAces github link you sent ages ago with the camera spectral data, and it is literal gold, what can be done with it is amazing. I really hope I can find such data for more cameras. In MLV App 2.0 (or whatever), we'll definitely have super accurate spectral colour correction

You're welcome! I think the gamut feature will be great for MLVApp. Thanks for all the work on this awesome software!

I hadn't considered TPM (TEE / PSP on Arm?)

TrustZone could work too.

and don't know if Canon ship the right HW feature.

Not current cameras. I meant the next generation of cameras.

they could simply use asymmetric crypto instead of AES.

Do you mean homomorphic? This would imply adding wifi to every camera, including the cheaper ones...

Regardless, any change in this area would be months of work for a dev team

I don't know about that. TPM is not that complicated. There's companies with know-how on this, and Canon could simply contract to do the work...

bricks customer cameras.

Firmware update wouldn't be any difficult or more harmful. They could make a database for the TPM/Trustzone key on their website and make this accessible only for authorized maintainers. The employers could simply get the key based on the camera serial number.

I don't know if any of this will actually happen, but that is a possibility. And, if this happens, this would mean the end of magic lantern... until someone discovers a vulnerability on the TPM module (which has already happen before).

Nice to see you working again on gamuts @Ilia3101 ! 

This might be an easier option?

https://sourcehut.org/blog/2019-08-21-sourcehut-welcomes-bitbucket-refugees/

@chris_overseas is right. Sourcehut is awesome. You don't need to pay, you can self host too. If git is too complicated, see also Pijul and Game of Trees

And if you do make updating firmware harder, useful updates are harder as well as higher risk (which means higher testing cost)

Not necessarily. Canon can just add TPM 2.0 on newer cameras. This would prevent update by others (including ML), because only they would have the key. TPM doesn't make it any difficult for them and solves the problem with little effort.

Here is the tutorial:
https://www.magiclantern.fm/forum/index.php?topic=24338

Nice! The animation is much better! I'll do a simple tutorial later about this Transform effect, might be of interest to other people...

A 35mm Foveon recording CDNG would be fantastic. I think the colors will look even better than ALEXA LF or DXL2.
They will need some faster flash memory, though, I'm not sure SATA SSD will be enough for high frame rate and NVMe with M.2 interface is very expensive...
I would easily buy one with Foveon if I had the money. Just to test the true power of Foveon with ACES workflow
Also, the minimalist design is great.

Youtube-dl output:

Code Select Expand


format code  extension  resolution note
140          m4a        audio only DASH audio  130k , m4a_dash container, mp4a.40.2@128k, 4.34MiB
251          webm       audio only DASH audio  166k , opus @160k, 4.58MiB
278          webm       256x144    144p  107k , webm container, vp9, 24fps, video only, 2.26MiB
160          mp4        256x144    144p  118k , avc1.4d400c, 24fps, video only, 2.10MiB
242          webm       426x240    240p  242k , vp9, 24fps, video only, 3.42MiB
133          mp4        426x240    240p  276k , avc1.4d4015, 24fps, video only, 4.84MiB
243          webm       640x360    360p  456k , vp9, 24fps, video only, 6.17MiB
134          mp4        640x360    360p  627k , avc1.4d401e, 24fps, video only, 9.79MiB
244          webm       854x480    480p  878k , vp9, 24fps, video only, 11.17MiB
135          mp4        854x480    480p 1196k , avc1.4d401e, 24fps, video only, 19.91MiB
247          webm       1280x720   720p 2124k , vp9, 24fps, video only, 23.83MiB
136          mp4        1280x720   720p 2359k , avc1.4d401f, 24fps, video only, 42.30MiB
248          webm       1920x1080  1080p 3050k , vp9, 24fps, video only, 43.88MiB
137          mp4        1920x1080  1080p 4825k , avc1.640028, 24fps, video only, 85.55MiB
271          webm       2560x1440  1440p 12681k , vp9, 24fps, video only, 156.89MiB
313          webm       3840x2160  2160p 18023k , vp9, 24fps, video only, 297.91MiB
18           mp4        640x360    medium , avc1.42001E, mp4a.40.2@ 96k, 14.94MiB (best)


I don't think uploading lossless is very efficient, though. You could just upload ProRes 422 lite or DNxHD 422 and have the same quality, since youtube will compress to VP9/H.264...
I would like to test AV1 10-bit Rec.2020 on youtube some day:
https://en.wikipedia.org/wiki/AV1

Nice video, btw! Amazing quality on the scene at 02:32. Also, very trippy music, reminds me of Kraftwerk. I like it.

I know I'm beating a dead horse, but I'll (try) to contribute to the discussion anyway.

No one touches color, including WB, before the colorists which is typically after editing and the media is already in a 10 bit ProRes/DNxHD(R)/MXF file.

You're wrong in this part @KirbyLikes525. In high-end movies color grading is not done in ProRes or other intermediate codec.
Maybe in television shows it is, because it's a faster workflow.
The process goes somewhat like this:

Raw > Convesion to OpenEXR > CG > Color grading > ProRes > Distribution format (H.264/H.265)

The Raw conversion already fixes some issues: white-balance, normalise exposure, high quality debayering, lens profiles (fix distortion, CA, etc), sometimes denoise (new algorithms work before even debayering), color space (normally ALEXA Wide Gamut or ACES AP1) and curves (normally Log-C or ACEScct).
This then it is rendered to OpenEXR for other post-processing (CG, montage and audio processing) and then, finally, into the color grading guy.
It's important to note camera white balance is most times wrong even if you use gray card, because debayering will affect how color is interpreted. I noticed this on MLV too, not sure this is a significant variation in high-end cameras such as Arri.

The correct term for ProRes should be "visually losless", not "virtually". For the human eye, no one will be able to perceive a difference between ProRes or true lossless (considering the bit depth and color space is adequate to the display where it is playing). But, for color grading, there's other variables that ProRes cannot contain and are important for processing, such as independence of color spaces (not something compressed like Rec.709) and bigger dynamic range.

So having recorded RAW before is nearly useless. ProRes is nothing bad, if used the right way. If mp3 is good for you and diskspace is another problem... why not recording H.264 and converting to ProRes Has nearly the same effect but is much easier.

It's not useless @masc. The processor inside those cameras cannot do complex debayering like we have in MLVApp (AMaZE) in realtime. You know that much better than me, you're the primary developer of mlvapp. Those cameras cannot contain a high powered GPU/Manycore processor because it consumes too much power and heats too easily...
Maybe OpenPiton will solve it

@reddeercity Any news about the 50D build?

Nice! The colors are very good too. I see you did some hardcore hiking to get into those places, haha.
Any particular reason to use 25fps instead of 24?

- export all clips as ProRes 422 Proxy (small and fast for cutting)
[...]
- export clips as ProRes 4444 (best quality for final)

So you have two ProRes renderings? Isn't that redundant and doesn't it takes too much space in the HDD? I personally just export everything in ProRes444 from MLVApp and work with those, because the size of MLVs is too huge for my HDDs...

Cool! What shutter speed are you using? There's something "off" about the motion blur, but might be just my imagination.
Also, a nice tip I learned: you can use the effect called "transform" on Premiere Pro to make animations with motion blur. You could use that on the "MXT" animation in the final of the video. Like this (notice that the "Use Composition's Shutter" is turned off):

@Ilia3101 Do you have plans to return on the BetterProcessing branch? Let me know if I could help.

Sounds like the compiler on windows is too stupid to use the given includes.

Code Select Expand

#include "stdlib.h" or

Code Select Expand

#include "stdint.h"  is missing in the file. No exact idea here and can't try.

Yep, that's it. Including stdint.h to wb_conversion.h makes it work.
Patch:

Code Select Expand


*** wb_conversion.h.orig Tue May 28 21:02:42 2019
--- wb_conversion.h Tue May 28 20:58:55 2019
***************
*** 10,15 ****
--- 10,17 ----
 
 
  #include "stdlib.h"
+ #include "stdint.h"
+
 
  void wb_convert(float *rawData, int width, int height, int blacklevel );
  void wb_undo( uint16_t *debayeredFrame, int width, int height, int blacklevel );




The camera matrices, do they give output with absolute colour, D65 is equal to D65? or is it something like D65 is at D50, I seem to remember andy600 mentioning that and it has been a thought in the back of my mind ever since. (I am so confused about this!!!!!!!!!!!)

Another thing.... Let's say processing will use multiple gamuts for different stages (it will, three to be exact) - some of these gamuts may have a D50 white point, some D65, and some approximately D60. When converting between these gamuts inside of processing, should the white point be adapted (relative transform) or should it use an absolute transform? I am thinking relative would be better, as it avoids white shift in some adjustments like saturation.

And: Does anyone have links to info of how perceptual gamut transforms work? (implementation, not just an explanation of how it looks)

I have no idea about those questions Ilia. In my mind I always thought that color conversion is something complicated and often not precise, so the simplest solution should always be the best one.
I noticed you seem to be using XYZ and then converting to other space, right? For example, I see you got the ACES matrix from here (XYZ-to-AP0). Wouldn't be better to just use right away the intended color space?
Might be a good idea to request help on ACES Central. They might have the answers about your white point questions.

Yes, I can compile here on OSX. What OS do you use? (If it is not OSX I am sorry... I am in holiday and no Win/Linux in the near.)

On Windows 10. QT 5.9.1. QTCreator 4.7.0. Using MinGW to compile.
Errors:

Code Select Expand


C:\MLV-App\src\debayer\wb_conversion.h:14: error: unknown type name 'uint16_t'
void wb_undo( uint16_t *debayeredFrame, int width, int height, int blacklevel );
               ^


Code Select Expand


In file included from ..\..\src\processing\rbfilter\rbf_wrapper.cpp:8:0:
..\..\src\processing\rbfilter\rbf.h: In function 'void _recursive_bf(uint16_t*, float, float, int, int, int, float*)':
..\..\src\processing\rbfilter\rbf.h:148:18: warning: value computed is not used [-Wunused-value]
         *--temp_x; *temp_x = 0.5f*((*temp_x) + (*--in_x));
                  ^
..\..\src\processing\rbfilter\rbf.h:149:18: warning: value computed is not used [-Wunused-value]
         *--temp_x; *temp_x = 0.5f*((*temp_x) + (*--in_x));
                  ^
..\..\src\processing\rbfilter\rbf.h:150:18: warning: value computed is not used [-Wunused-value]
         *--temp_x; *temp_x = 0.5f*((*temp_x) + (*--in_x));
                  ^
..\..\src\processing\rbfilter\rbf.h:156:25: warning: value computed is not used [-Wunused-value]
         *--temp_factor_x; *temp_factor_x = 0.5f*((*temp_factor_x) + 1);
                         ^
..\..\src\processing\rbfilter\rbf.h:175:22: warning: value computed is not used [-Wunused-value]
             *--temp_x; *temp_x = 0.5f*((*temp_x) + ycr);
                      ^
..\..\src\processing\rbfilter\rbf.h:176:22: warning: value computed is not used [-Wunused-value]
             *--temp_x; *temp_x = 0.5f*((*temp_x) + ycg);
                      ^
..\..\src\processing\rbfilter\rbf.h:177:22: warning: value computed is not used [-Wunused-value]
             *--temp_x; *temp_x = 0.5f*((*temp_x) + ycb);
                      ^
..\..\src\processing\rbfilter\rbf.h:182:29: warning: value computed is not used [-Wunused-value]
             *--temp_factor_x;
                             ^
..\..\src\processing\rbfilter\rbf.h:271:24: warning: value computed is not used [-Wunused-value]
                 *out_++;
                        ^
..\..\src\processing\rbfilter\rbf.h:273:23: warning: value computed is not used [-Wunused-value]
             *factor_++;
                       ^



Code Select Expand


In file included from ..\..\src\debayer\wb_conversion.c:8:0:
..\..\src\debayer\wb_conversion.h:14:15: error: unknown type name 'uint16_t'
void wb_undo( uint16_t *debayeredFrame, int width, int height, int blacklevel );
               ^
..\..\src\debayer\wb_conversion.c: In function 'wb_convert':
..\..\src\debayer\wb_conversion.c:27:60: warning: unused parameter 'blacklevel' [-Wunused-parameter]
void wb_convert(float *rawData, int width, int height, int blacklevel)
                                                            ^
..\..\src\debayer\wb_conversion.c: In function 'wb_undo':
..\..\src\debayer\wb_conversion.c:58:67: warning: unused parameter 'blacklevel' [-Wunused-parameter]
void wb_undo(uint16_t *debayeredFrame, int width, int height, int blacklevel)
                                                                   ^
Makefile.Debug:8960: recipe for target 'debug/wb_conversion.o' failed
mingw32-make[1]: *** [debug/wb_conversion.o] Error 1
mingw32-make[1]: *** Waiting for unfinished jobs....
..\..\src\processing\rbfilter\RBFilterPlain.cpp: In member function 'void CRBFilterPlain::filter(uint16_t*, uint16_t*, float, float, int, int, int)':
..\..\src\processing\rbfilter\RBFilterPlain.cpp:266:29: warning: unused variable 'src_prev' [-Wunused-variable]
             const uint16_t* src_prev = src_color;
                             ^
mingw32-make[1]: Leaving directory 'C:/Users/Pichau/mlvapp/MLV-App/platform/build-MLVApp-Desktop_Qt_5_9_1_MinGW_32bit-Debug'
Makefile:36: recipe for target 'debug' failed
mingw32-make: *** [debug] Error 2
20:13:44: The process "C:\Qt\Tools\mingw530_32\bin\mingw32-make.exe" exited with code 2.
Error while building/deploying project MLVApp (kit: Desktop Qt 5.9.1 MinGW 32bit)
When executing step "Make"


Very nice @reddeercity. Let us know when you release your code. I have a 50D so I could help testing.

If it is possible could you give me a sample (s)?

Here you go:



Download the MLV (90MB) here:
https://drive.google.com/open?id=1zksn3AZAZc8d0bX8V8cxHcMIlj5Y9ln4

Download PNG's with all gamut test from BetterProcessing:
https://drive.google.com/open?id=1B9Pfij9pjymNsXWCDFhhCQxbiqCB_Atd


As I said, this is not very scientific. The MLV was recorded using 50D, with WB at 5500K in direct sun light. I'm using a old Nikkor lens, so it should be a bit warmer because of the lens coat. Also, the pantone palette is quite old and the paper started to get a bit yellow. Anyway, should be enough to do some tests. I can assure you the rawtherapee is very accurate to what I see in real life.

@masc Are you able to compile master? I think this commit broke it:
https://github.com/ilia3101/MLV-App/commit/88e803d1033640953edd284de4bccdae88645c63

frame_caching.o: In function `get_mlv_raw_frame_debayered'
undefined reference to `wb_convert'
undefined reference to `CA_correct_RT'
undefined reference to `wb_undo
error: ld returned 1 exit status

Dual ISO is done by alternating exposure between sensor lines. So it can only happen when the picture is taken.
You can, though, do HDR images with any camera. I recommend HDRMerge.

Finally, got to test the BetterProcessing branch.
Testing with 14-bit 50D MLV's, on a 99% Rec.709 monitor.
Some notes I did while testing:

- No processing gamut is working, except for Rec.709 and XYZ.
- XYZ to Rec.709 seems to be working nicely. Still, not precise, but might be the camera matrix(?).
- Comparing with Rec.709 > Rec.709, the XYZ > Rec.709 shifts towards red and slightly cyan on shadows. Because of the shift, reds get easily clipped (skin tones, mostly). Intense reds are a bit brighter than it should. Reds also gets hue shifted a bit towards magenta.
- Is already better than the original processing. Less color artifacts when doing heavy processing. More color separation (in especial the 'sub-tones' of red, differentiation between red, oranges and magenta).
- Other functionalities seem to be affected (using XYZ > Rec.709): curve in the Red channel is very sensitive and HSL is not precise.

Using Rec.2020 output:
- XYZ to Rec.2020 doesn't seem right. Can't say for sure, though, as I don't have a Rec.2020 monitor
- AdobeRGB to Rec.2020 seems alright (even though this wouldn't make much sense, as Rec.2020 is bigger than AdobeRGB).

Old bug, but I think Ilia already knows:
- While using camera matrix, bellow 3600K give odd colors. It seems the blue channel gets pulled and the reds gets fucked up

I'll post some samples some other time. I don't have a colorchecker, but a Pantone palette might work as a unscientific experiment.

But I have no idea how openfx works

Seems to be really complex. Don't know why, but might be because it was designed for compositing and VFX, not for simple filters. The good thing is that it seems to be a standard now. Nuke and Resolve are associated.