Messages

1

Raw Video Postprocessing / Re: What causes incorrect white & black levels?

« on: February 16, 2021, 12:25:03 AM »

Ok thanks for that.

Do you mean 12bit setting in the camera? If so yes, but I have 120GB of footage shot like that now.

I used to use the 12bit lossless on my 70D as my go-to setting and I don't remember encountering any issues with exposure.

These new files were shot on 5D mk3 with your crop_rec_4k_mlv_snd firmware Could that be why?

2

Raw Video Postprocessing / What causes incorrect white & black levels?

« on: February 15, 2021, 03:26:17 PM »

Recently I shot a bunch of stuff with some lights, and exposed both by 'eyeballing' the LCD and checking the histogram.
Bringing MLVs into MLVApp, everything looks really blown out. Highlights are obliterated.
Exporting as cDNG, I started to freak a bit when I realised I couldn't even recover the highlights in Resolve.

Back in MLVApp I discovered If I set the White Level to maximum, it looks roughly as it did on the LCD when shooting. I could rest a bit easier.
I've seen mention of these levels come up on the forum, but before switching from MLVFS to MLVApp, I've never had access to them, not had any need to.

So then,

A. How are these values set?
B. What should I investage if they are wrong? The camera? The ML version in use? or the software doing the conversion?
C. Is there anything wrong with selecting all the MLVs I just shot, and setting all their White Levels to maximum to try salvage my footage?

Sorry if this information exists somewhere on the forum, but I can't find it.

White Level according to MLVApp is set to 6000, but nothing looks even close to correct unless its set to somewhere in the 12,000 - 16,000 range.


EDIT: I can see now in some other posts that white level should be 16200 or even max 16383 for 5D Mk3. So why would it be set to 6000 in my files?

3

Raw Video Postprocessing / Re: MLV App 1.11 - All in one MLV Video Post Processing App [Windows, Mac and Linux]

« on: July 14, 2020, 06:03:27 AM »

Any updates on the possibility of Cinelog?

Could we not allow a users who own Cinelog to copy the dcp files into a place where MLVApp can detect and use it?

Cinelog really is a great pairing for MLV Raw and remains AFAIK the only colourspace transform designed and calibrated specifically for it.

MLVApp + Cinelog workflow that would allow more or less one click dumping of a card full of MLVs into Cinelog Prores would be a very fast, powerful and space saving combination.

Working direct with cDNG in Davinci has it's benefits, but if you're working on real projects, it's hard to beat the blazing speed of FCPX with Prores.

4

General Development / Re: Magic Lantern development compiler.app (Mac OS)

« on: May 28, 2020, 12:14:29 AM »

Ok I'm in business!

So I think yes that's crux of it. It seems, at least on 10.13.6 anyway, macOS has python2.7 installed under python, but thats it.
Brew has installed other python versions on my system at some stage, but 'which python2' gives me nothing so its going nowhere.

So it was as easy as installing python2 via brew, although I had to do it from a commit as python@2 didn't want to work.

For anyone following, this commit did the trick

brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/86a44a0a552c673a05f11018459c9f5faae3becc/Formula/python@2.rb

Thanks for the help!

5

General Development / Re: Magic Lantern development compiler.app (Mac OS)

« on: May 27, 2020, 01:45:07 PM »

Ok pip3 returns

Requirement already satisfied: docutils in /usr/local/lib/python3.7/site-packages (0.16)

Looking again I can also see a lot of /bin/sh: python2: command not found

python3.7 and python3.8 have presumably been installed by some other brew apps, so maybe even though macOS still targets python2.7, Homebrew defaults to 3.7?

But I'm a bit out of my league here....

6

General Development / Re: Magic Lantern development compiler.app (Mac OS)

« on: May 27, 2020, 02:03:19 AM »

This is caused by ML assuming that "python" resolves to python 2 (breaks the module string generation so the header file is missing).  You almost certainly have "python" resolve to python 3 (Catalina?  I don't have a Mac to test).

The quick hack way to fix is to make python point to python 2.  The slightly nicer way is to edit ML source so that it explicitly calls python2.  The best way would be to remove the dependencies on python2 entirely but I haven't done that yet.

I think the changes for option 2 are split over these three commits:
https://bitbucket.org/stephen-e/ml_200d/commits/?search=python

DO NOT apply those commits blindly to Danne's repo, that's from one of my repos and they're messy commits with changes for multiple things.  Copying blindly will break your compile.  I'm in the middle of tidying this up so should have a nice, single commit this week.

Thanks for the reply, and thanks you Danne for the Mac script!

I'm only on 10.13.6 on this machine, but I do have Python 2.7, 3.7 and 3.8 installed for other stuff.

Python --version gives me Python 2.7.16 though.

Is there a way to check what version of Python this is referencing?

7

General Development / Re: Magic Lantern development compiler.app (Mac OS)

« on: May 26, 2020, 08:35:12 AM »

This all installed fine and setup dependencies (AFAIK), but no matter what repo/branch combination I select, I just get this error on compile for all modules.

module.h:344:28: fatal error: module_strings.h: No such file or directory

Any ideas?

8

Raw Video / Re: 5D mk iii RAW record to SD card vs 70D

« on: May 24, 2020, 03:09:20 AM »

Well its not good economics to buy a 5D3 and then use a card that writes 40mb/s.

Continuous 12bit lossless @ 1080p requires 36MB/s which is perfect for me and works just fine on my 70D.
But the 70D's moire and inadequate dynamic range and low light performance was wearing me down, hence the 5d mk iii.

I'm going to experiment with sd_uhs for mk iii.
Before I give up on SD need to do a throughout inverstigation of SD overclock. I can see some promise in e.g Ilia3101!'s build for spanning both devices, but I cant try that as I don't have an CF cards.

Does anyone have a build with sd_uhs included for 5D3.123, or just the module itself?

I've got one foot in the rabbit hole of compiling my own, but usually try not reinvent the wheel where possible.

9

Raw Video / Re: 5D mk iii RAW record to SD card vs 70D

« on: May 23, 2020, 01:59:24 AM »

The CF cards is really fast tho. I have a Lexar 256gb 1066X that I'am very happy with.

No doubt they are, but they're the price of a second hand 60D.
Conversely I've had a BMCC on loan for a bit that takes SSDs. A 256gb SSD is $33, is faster and can be used for other things.

It's all just economies of scale of course, but knowing that the 5D sd slot is a dud makes a big difference to the smartest way spend ones' hard earned funds looking forward. With CF cards being that price, it probably means forget the 5D and put the money towards a BMCC

5D3 is 1 year and 4 months older then 70D

Ok that explains a lot, thanks.

10

Raw Video / Re: 5D mk iii RAW record to SD card vs 70D

« on: May 23, 2020, 01:39:27 AM »

And this was discussed when and where? Link, please!

I'm pretty sure nobody involved in ML development ever dared to imply something like this.

Ok my apologies for the bad wording, I didn't mean to imply 'cheaper than the 5D' . But the 70D thread is full of the 40mb/s theoretical limit of the sd hardware as obviously, it's a consumer grade camera and was never meant to write that much data to fast cards. Much of that was overcome as 10/12 bit and lossless came and now sd overclock.

In any case, the 5D thread is epic and I couldn't glean the answer to that question from searching so I thought it was an appropriate question to ask that might help others in future.

A simple 'no the 5D sd clot is know to be slow, it has CF etc' ... or... 'no that's not right, the 5D card should write 40mb/s too, you're using the wrong build' were the answers I was hoping for. 

11

Raw Video / Re: 5D mk iii RAW record to SD card vs 70D

« on: May 22, 2020, 03:18:31 AM »

Ofcourse but it has a lot in common and I would have expected it shares the same SD slot, if not better.
But I guess that where I went wrong.

So we're saying the SD Slot in the 5D mk iii is inferior to the 70D then?

As in, it definitely has nothing to do with MLV settings or SD Card type or ML build, but purely a hardware thing that can't be avoided due to an inferior SD chip and I have no choice but to buy CF cards?

I can come to terms with it, but from following 70D development I was under the impression that it was the 70D that had the cheaper SD hardware with 40mb/s limits. That the 5D would be even worse comes as a bit of a surprise.

12

Raw Video / 5D mk iii RAW record to SD card vs 70D

« on: May 22, 2020, 01:26:23 AM »

I've been overjoyed at the performance of my 70D raw recording capabilities with the newest experimental branches.
With 11bit lossless I can record continuous RAW now at near-enough-to-HD rez, and that's been a game changer.

But the thorn in the side on 70D is the moire, it constantly ruins good shots when color grading and I decided it's time to say goodbye to moire and get a 5D mk iii.

All is well and good except when I tested the SD card for RAW. With the same settings as continuous on 70D, I can get max 6 seconds on the 5D.
Where I live, a Sandisk Extreme CF card is exactly 4x price of a Sandisk Extreme SD for the same size. They're also about 6x the price of an SSD that are used in other cameras.
I realise this is economies of scale at play, but my question is....

If the 70D can do it, why not the 5D mk iii?

Can the 70D sd slot really be faster than then 5D mk iii SD slot?

13

Raw Video Postprocessing / Re: Cinelog - True logspace conversion for DNG and CinemaDNG footage

« on: November 19, 2019, 06:43:01 AM »

Hey @Andy600 . Cinelog is still my favourite way to work with ML Footage, but as MLVFS doesnt seem to support some of the new compression formats, slomo and such, at least on all my Mac systems, MLVApp is now the most streamlined method.
But at this stage we have to convert everything to cDNG in MLVApp, then do the Davinci method from the guide on your site.

Is there a way we can get a Cinelog profile for MLVApp please to make this a one step process??

I've tried selecting BMDFilm in MLVApp and applying the BMD-Film to Cinelog LUT but the result looks wrong and very different to how it looks back when I could use MLVFS.

While we're at it, ever going to get some more looks in the LUT bank?

Cheers!

14

Raw Video Postprocessing / Re: MLVFS - a FUSE based, "on the fly" MLV to CDNG converter

« on: June 19, 2019, 03:30:46 AM »

Quite happy with MLVFS > DaVinci workflow these days, but just seeing a lot of talk here about updates to the Windows version.
There's been a lot of progress lately with bit-depth and lossless on the 70D. Does the current MacOS version have everything needed to handle these formats correctly? I notice no updates since July 2018.

I'm guessing not as they appear as 0 frames with no info.

Is there any kind of working Mac version of this around now, or are we forced to use a different workflow with lossless compression on MacOS?

I took a quick look at the source, but the C stuff is a bit beyond me.
Be awesome to have this workflow rolling again as I don't think we can turn back from lossless now we have it.

thanks.

15

crop_rec and derived builds / Re: ArcziPL's crop_rec_4k experiments for 70D

« on: June 19, 2019, 01:51:06 AM »

Hey guys, big ups to everyone getting lossless / sd hacks / 3k going on this cam!

I've been checking this thread fairly regularly since it started, and reread the last 5 pages, + searched the 10bit thread,  but still a couple of things I can't find info on.

1. Why does 14bit lossless say ISO < 100. To me that means choose an ISO smaller than 100, but that doesn't make sense. Why does ISO matter to lossless anyway?
2. Magenta highlights in 12bit /10bit lossless modes. Is this a known issue? What causes it? I remember reading somewhere way back about incorrect white level, I can alleviate it somewhat by messing with it in MLV App, but I've no idea what I'm doing and it seems to hurt other colors. What's needed to fix this on the 70d now and can I help?

thanks

16

Raw Video / Matching ML Raw to BMCC Film (log) footage

« on: April 29, 2019, 08:47:13 AM »

I shot some stuff the other day for a project using a Blackmagic Cinema Camera and a 70D for the second cam.
My well thought out plan was that If I brought the 70D Raw footage into Resolve , set the colourspace to BMDFilm and set the white balance to the same as the BMCC camera was set to, the shots should match.
But even with the exposure tweaked to match, the color and tonality is very different.
When I cut the footage from the 2 cams together and drop a BMD Film > Rec709 LUT over the sequence, the shots from the Canon look more contrasty and saturated than the BMCC footage.
The BMCC footage also seems to have a pretty strong green cast compared to the Canon

Has anyone had experience matching footage like this?
Is there a recommended workflow for this or just a matter of matching things manually?

Thanks in advance

17

Raw Video / Re: Raw video post processing help!

« on: July 06, 2018, 03:40:50 AM »

Hello,

I am just wondering how to turn the Magic Lantern files into a film sequence. The small problem is that I don't have adobe after effects or premier pro and all youtube tutorials use these programs. The software I do have is Final Cut Pro X, Adobe Lightroom and Adobe Photoshop. Ideally I don't want to spend any money on buying new Mac OS software (I have a MacBook Pro).

Many thanks,
Jonny

This should go in the Post Processing sub thread but....

Install MLVFS / MacFuse https://www.magiclantern.fm/forum/index.php?topic=13152.0
Search for DaVinci Resolve on the App Store and install it (it's Free)
Edit direct in Resolve if you like it, or get it to spit out Prores files and use them in Final Cut.

18

Raw Video / Re: Color grade when in the RAW-to-ProRes process?

« on: July 06, 2018, 03:35:52 AM »

Also depends a lot on your preference of editing software, and if you want to playback multiple streams in realtime.
e.g
 1. You have a new GFX card with plenty of ram, running from SSD, and don't plan to overlay multiple streams. Then you won't be bothered by the MLVFS/MacFuse CPU overhead or on-the-fly debayering so can edit direct in Resolve and take advantage of editing natively in RAW.

2. You running from hard drive, and/or enjoy the lightning fast realtime playback/scrubbing of multiple streams in FCPX. Then you might prefer to convert from MLV to Prores in a log colourspace.

In theory cDNG has more information to grade with, but in my experience trying it both ways I find Log has just as much grading latitude for %99 of shots, but is far more efficient use of your available CPU/ram resources.

I find these days If I'm messing around with holiday footage and want how far I can stretch things and play with colour, I'll use Resolve with MLVFS.
Any chromakeying I'll do with MLVFS in after effects.
For any serious work like music videos where there might be some layer blending or FX involved, I really love that liquid smooth playback of Prores within FCPX so I find it's well worth the extra conversion step before I start.

19

Raw Video / Re: Color grade when in the RAW-to-ProRes process?

« on: June 07, 2018, 10:42:36 AM »

Thats a pretty long winded process.
Try to take advantage of a log format like BMD Film or if the excellent Cinelog if you can spare a few bucks.
A quick and powerful workflow is to use MLVFS and software that can load cDNG and export Prores (e.g DaVinci Resolve Lite, After Effects) to bulk convert all your MLVs to Prores in a Log colourspace in one fell swoop.
Then bring your Prores files into Premier / Final Cut or whatever you use, and grade there while you edit.
You will retain nearly all advantages of raw (No compression artifacts , 4:2:2, 10bits of color informations and no clipping of highlights or shadows) but your file sizes will be much smaller and you can grade / edit multiple streams in realtime in your NLE.
So to condense that: convert to Log and grade after that because it's far more efficient use of your time, disk space and processor power.

20

Raw Video / Re: No way to do auto restart recording for RAW?

« on: January 27, 2018, 06:58:32 AM »

There is an option "Frame Skipping" which will prevent MLV_REC from stopping when buffer is full. Side effect: Corrupt frames.

Well I mean gaps don't matter as in the kind of gaps you get if you keep pressing record again immediately after recording stops due to dropped frames. i.e. lot's of ~10sec files with no dropped frames, but large gaps in continuity. I can still use this footage by patching over where the gaps are with another cam or b-roll. But it would be nice if I could just hit record and not have to keep watching for when I can record again.

The 'Frame Skipping' option just creates a jumble of corrupt and non corrupt frames, completely unusable.

Is this something I could do with a LUA script maybe?

21

Raw Video / No way to do auto restart recording for RAW?

« on: January 09, 2018, 02:07:11 AM »

Feature is there for standard video recording, but can't seem to do it for RAW.

On the cameras with limited SD bandwidth, in my use case I'm often just reading to continually restart, gaps aren't that important.

Any way? LUA maybe?

22

Raw Video Postprocessing / Re: Does MLVFS Chroma Smoothing effectively turn 444->420 ?

« on: May 05, 2017, 09:05:43 PM »

Just give up.. I used to run around in circles trying to get rid of moire. You can't not without losing tons of detail and looking like SD footage. Maybe the mosaic engineering vaf? Seems like the only real solution.

Yeah I've come to that conclusion (though I've found the ACR defringing tools can work wonders in for the coloured variety, even though its not designed for this)

Well I'm on 70D, VAF's ludicrous pricing with intl. shipping makes it almost the same as trading the 70D for a 5D3. I'm amazed anyone buys them.

23

Raw Video Postprocessing / Does MLVFS Chroma Smoothing effectively turn 444->420 ?

« on: May 05, 2017, 02:33:12 AM »

Testing different ways to deal with Moire and being that blurring and upsampling are visually similar, am I giving up one of the reasons for shooting raw in the first place (444, I know the bit depth is still there).

24

Raw Video Postprocessing / Re: To Log or not to Log (from MLV)

« on: May 01, 2017, 06:52:15 AM »

Alright it is important to note the difference, log versus raw is very different.  It not only comes down to the dynamic range of the footage, but more importantly the bitdepth.  I will shoot with a log picture style for most of my work if I don't have to/plan to push the image to hard in my manual grade in post.  If you push the h264 files to hard the colours will heavily band and you will get blocking artifacts due to the heavy compression.  RAW on the other hand is 14bit (depending on RAW settings) versus h264's 8bit, it can be worked very hard before breaking down.  Personally my workflow is to take the RAW MLVs colour balance them and convert them to an arri standard log with some noise reduction before outputting them in Cineform, a GPU accelerated codec that outperforms ProRes and is resolution agnostic, to use in my NLE where I preform my final grade.

Sent from my SM-G930W8 using Tapatalk

I wasn't talking about fake log color profiles for H.264 (IMHO you're better off trying to get the most out of your 8 bits by exposing your shot properly and using standard/neutral profiles, and getting your utilising all 0-255 data values. The sacrifice to color tones is just too great to force log into 8 bits).

What I'm referring to is converting 14bit RAW to a 10/12bit Prores using a log colourspace such as VisionLog / Cinelog-C via ACR or other method, which seems to be the workflow of choice for some people on this forum.
Real high bit depth Log colourspace files like this (like their in-camera counterparts Arri Log-C / BMD Log etc) are really not so different to RAW at all when it comes to grading latitude. But of course we don't have that option, we can only go H.264, MLV, or MLV->Log Prores.


And yeah..... if you're a FCPX user you'll know that Prores is lighting fast. I can have 4+ layers of 1080p with FX all in butter smooth realtime. Prores and FCPX were designed for each other though, if you're using Windows or another NLE, YMMV.
If Cineform can beat that, I'd like to see it.

Sidenote: With the trend pointing at universal adoption of H.265 HVEC in GPUs and camera SoCs, things are about to change rapidly for codecs. With an All-I (GOP1) highbitrate 10bit 444 H.265 file rivalling Prores 444 in quality and edit speed, at a fraction of the file size, it's not hard to see where things are going.
These new chips from Ambarella (https://www.ambarella.com/news/94/122/Ambarella-S5-IP-Camera-SoC-Delivers-4K-10-bit-H-265-Video-and-Multi-Imager-Capabilities-to-the-Professional-Surveillance-Industry) means even tiny action cams will be encoding this on their hardware very soon, and you GPU will be decoding it realtime back at the computer. That will be hard for 3rd party codecs to beat!

25

Raw Video Postprocessing / To Log or not to Log (from MLV)

« on: April 29, 2017, 09:04:08 AM »

As I understand it, for cameras that can record Log natively, it can provide most of the dynamic range benefits or RAW, whilst keeping the convenience of single file clips and space conservation of [barely] compressed formats like Prores. (From here on in 'Prores' is interchangeable with your intermediate codec of choice)

But being that ML users must shoot RAW to get these benefits, by the time we get MLVs into a usable format, we've already had to deal with (to varying degrees deepening on model) space/time/res limitations and extra workflow steps involved with shooting RAW. So as we're not really able to cash in on a lot of the conveniences that a true cam->NLE log workflow provides, I'm interested to know why the people that are using things like VisionLog / Cinelog-C in their workflows choose to do so.

I assume some people would like to go Log-Prores to keep dynamic range available whilst maintaining the playback/scrub speed of Prores in NLEs like FCP.
If so do you....?

1. Drop a Log->Rec709 LUT on your Log clips (or output/timeline) by default so you're viewing as Rec.709, and do cc/grading before the LUT in the chain?
   This would obviously have the benefit of allowing clipped areas to be recovered if needed, but should otherwise look like the Log step never happened. Other than that, is there also a specific benefit to applying color correction while in the Log colourspace as opposed to filming 'flat' (contrast/saturation reduced) Rec709? Another way to say this is: If I'm displaying Log footage through a Rec.709 LUT, but adjusting curves before that LUT, the function curve is affecting a very different set of values than if it were after the LUT. Do people use this to advantage? What the theory?

2. Drop a "Film Look" type LUT on the log footage that has the Log->Rec709 transfer built in?
   Since I've been playing with Log and thinking about it, this should effectively give the LUT access to values that lie outside the range of rec.709 and presumably the opportunity to map those values into more a pleasing highlight rolloff. In testing though I can't say such a subltle difference justifies the extra steps and CPU load.

3. Begin grading directly from the Log footage, working contrast and saturation back in manually?
I hear a lot that log is just an intermediate step for maintaining DR, and not intended for output. But I swear a lot of new TV series with flat look resemble Log footage with the blacks pulled down and some sat in the mids. Is this the case or am I just misinterpreting a stylistically flat, but not necessarily log grade.