3K/UHD 5D2 Raw development and Other Digic IV Cams

[reddeercity]

@ Ilia3101 & masc
Just tested mlv app V1.5 on windows , seem to work now , but I sure it didn't work before
that why ask on your thread . I don't get the same Info that you posted @ masc  when I select 0.33x .
That not on my windows version and I guess that the confusion right there , If I would have seen the
pixel stretch final resolution , I would have used mlv app .

Tip: if you set metadata in camera correctly, MLVApp shows the right AR automatically, and you also can fast export to DNG with correct AR. Adobe programs show correct AR out of the box then.

 
No it doesn't , at least on windows -- I can't get it to export more then 1 dng (only works with export frame) "fast export to DNG" does nothing
and the dng that's does export with "single frame export with 0.33x set is only 1632x609 not 4896x1828 , that only
happens with compressed file format like "PNG" or "H264" etc. ..... no pass though cdng's to 4.9k etc. ....

Even MLVFS with Quick Mount  ( which I use 99%  in After Effect & Resolve) doesn't show corrected a.r.
I guess as long as I have 16bit tiff's I'm happy , would like to have the right sized cdng (4896x1828) to work with .
Maybe mlv_dump can export them correctly never looked in to it yet .

[jpegmasterjesse]

Can we expect to see a build to test soon? Are there any specific kinks you're still working out?

[masc]

@reddeercity:
The MLV and DNG code is identical on Win/Linux/OSX. But I tested on Windows now. Unfortunately I can't find a bug. I tried with a 1x3 MLV file from EOS-M (which has correct stretching metadata) and it works (AR is correct in viewer and in all possible DNG (single compressed/uncompressed, batch uncompressed, compressed, fast) / PNG exports without changing one single parameter in MLVApp).
https://bitbucket.org/Dannephoto/magic-lantern/downloads/M19-1215.MLV
I opened the DNGs / PNGs in LR6.14 for testing. In my case I got always 3552x2000 from originally 1184x2000. You'll get something else if you override resolution by enabling "resize" box in export settings.

How did you test? Would be interesting - maybe somewhere are still bugs (I am sure there are).
If you like to see the new resolution label from my screenshot you should compile the latest commit - just pushed the code to the repos for now. But all the resizing should work in v1.5 as described.

The metadata which is used for correct AR are:
RAWC.binning_x, RAWC.skipping_x, RAWC.binning_y, RAWC.skipping_y

Somehow Resolve can't interpret stretching metadata - so here you'll get wrong AR out of the box.

[OlRivrRat]

                     jpegmasterjesse

       If You Read the last 100 or so replies, I suspect You will find what You are Wanting ~

[70MM13]

masc,
I have had the occasional mlv from my 5d3 that doesn't get automagically stretched.  It may have been only once.  I just recall it happening about a week or two ago.
Unfortunately I don't have the mlv's, as it was during my ongoing testing, and those files get ditched when I format the card.
I'll keep an eye out for it and if it happens again I'll send you the file...

[Danne]

@reddeercity:
How did you test? Would be interesting - maybe somewhere are still bugs (I am sure there are).
If you like to see the new resolution label from my screenshot you should compile the latest commit - just pushed the code to the repos for now. But all the resizing should work in v1.5 as described.

No bug. metadata has to be set in code, so where´s the code?

[ilia3101]

No bug. metadata has to be set in code, so where´s the code?

+1

@reddeercity if you released code when you come up with more changes, all of your presets would be added to the menu by now, and the camera would set stretch metadata correctly. Danne is very keen on helping.

I appreciate that you have the original code uploaded, but it's important to have modified newer versions too.

[reddeercity]

There's no new code yet , I'm doing everything though adtg_gui_.mo
Now that should clear up things about code etc. ....
and the 1x3 files display correctly in mlv app when exported to compressed format

[ilia3101]

There's no new code yet , I'm doing everything though adtg_gui_.mo
Now that should clear up things about code etc. ....

Thanks it does clear stuff up. Then could we just have the code for the build that can do 3008x1080 resolution? Last time I checked, the uploaded code was the 2880x1080 version.

and the 1x3 files display correctly in mlv app when exported to compressed format

Good to hear it works.

[masc]

Then could we just have the code for the build that can do 3008x1080 resolution?

Have you tried this one from first post? https://www.magiclantern.fm/forum/index.php?topic=19336.msg182476#msg182476

[70MM13]

confirmed here, uncompressed doesn't display correct aspect ratio automagically in mlvapp.  lossless does.
i remember now how it happened here.  i was troubleshooting a shot a while back and tried uncompressed.  i was focused on the issue and didn't pay much attention to the whole stretching thing...

[masc]

I don't think it has something to do with compression, because these metadata variables are always there. If they are used by ML in camera, MLVApp can use them as well, if not then not. But if you have such a file I could have a look.

Edit: quick test with EOS-M footage 10bit lossless vs. uncompressed: no difference in those parameters and behaviour.

[70MM13]

i'll PM you the file...

[kwstas]

Hi reddeercity and guys,

I've made some quick test with experimental release. Followed the steps from p1. I'm facing these issues.

- 5x mode is magenta, when recording turns grayscale, yet crop factor is irrelevant to what it records
- when pressing to 10x mode camera freezes

And a hypothetical scenario.
Just wondering if it possible when 5x mode pressed the viewfinder remains in 1x with crop lines displayed based on chosen ratio.

cheers,
K.

[masc]

i'll PM you the file...

Thank you. The metadata is definitively wrong in your file - so it is not set correct in camera. This is how your file looks inside (look at the very right, I marked metadata blue):

Your file is 1x3, but 3x3 is set in the MLV.

[70MM13]

as soon as i switch to lossless in camera, there's no problem.
uncompressed only.

[mlfan]

Hi reddeercity and guys,

I've made some quick test with experimental release. Followed the steps from p1. I'm facing these issues.

- 5x mode is magenta, when recording turns grayscale, yet crop factor is irrelevant to what it records
- when pressing to 10x mode camera freezes

I'm a new 5D mk II user and I'm seeing this too. IIRC 10x mode doesn't always freeze, but I consistently have a very pink 5x mode.

[reddeercity]

What preview mode are you using ?
remember this is bleeding edge stuff , sometimes things that
normally work on the nightly builds don't always work on bleeding edge stuff .
crop_rec is only meant to record extended resolutions in 3x crop_mode (5x zoom)
and not to be used with the regular nightly build feature set .
Meaning 10x zoom freezes the camera .
 
I expect to have normal canon previews in future releases of the crop_rec  in 3x crop_mode (5x Zoom)

[mlfan]

What preview mode are you using ?
remember this is bleeding edge stuff , sometimes things that
normally work on the nightly builds don't always work on bleeding edge stuff .
crop_rec is only meant to record extended resolutions in 3x crop_mode (5x zoom)
and not to be used with the regular nightly build feature set .
Meaning 10x zoom freezes the camera .
 
I expect to have normal canon previews in future releases of the crop_rec  in 3x crop_mode (5x Zoom)

I'm not quite sure what you mean by preview mode -- I'm in manual mode in Live View. Could you explain?

[Walter Schulz]

Please read first post of this thread with care. Esp. what is written about preview mode there.

[dfort]

I've been experimenting around with the 7D to see if I can get it working with reddeercity's latest crop_rec settings. Still a long way off but I have managed to merge the current crop_rec_4k_mlv_snd branch with waza57's crop_rec_4k_5D2 along with raw_video_10bit_12bit_LVState -- but wait, there's more -- RscMgr_memory and the changes need to get the 7D working with 10/12bit. But that's not all, also the latest lua_fix. The 50D should be working on this branch. In fact all of ML cameras should be functional on this branch. Ok--they all compile but I haven't tested them. Need some help with that.

There's a test build for the 5D2 on my downloads page. It should work the same as the waza57 version. I didn't include reddeercity's unpublished changes at this time.

Here's the source code if you want to roll your own and start experimenting:

https://bitbucket.org/daniel_fort/magic-lantern/src/crop_rec_4k_mlv_snd_experiments/

@reddeercity -- I could use some tips from you on how to get started with Digic Poke to change the resolution.

[EDIT] Sorry, looks like I didn't merge waza57's code before I posted this.

[reddeercity]

I don't really see why you merged in to "crop_rec_4k_mlv_snd branch"
I can't see any advantage with it , specially with lua_fix . That I can't see to be any use at all at least on 5d2 in Video .

I thinks it simpler & easier to keep on the waza57's crop_rec_4k_5D2 branch , in my own opinion .

@reddeercity -- I could use some tips from you on how to get started with Digic Poke to change the resolution.

Sorry , I been busy with getting a few projects up and running ( it spring time and warm weather finally has come to the great white north  )
and writing code for crop_rec 5d2 . I'll see if I can put something together in the next day of two .

Edit: just read though the crop_rec code and there's no code for waza57 crop_rec branch
There no reference to 5D2 in the code at all , so I would say it didn't merger any think for waza57 source "crop_rec_4k_5D2 " branch

[aprofiti]

I think it's better to work on a clean fork of crop_rec_4k_mlv_snd.

It will allow to prepare for merging back into the "official" codebase when things will be ready.

Regarding code from Waza, is it still necessary or a better way to allow digic4 to work on this branch was found?

I remember reddeercity has to reverse back some of the code to make it work as current state

[dfort]

I don't really see why you merged in to "crop_rec_4k_mlv_snd branch"

Why? Because it is there! Oh wait, that's a mountain climber's answer. Well, in a way this is quite a mountain to climb.

If you take a look at the experiments downloads page--

4K raw video recording; lossless compression
crop_rec module with higher resolutions (4K, 1080p48 etc):

I think it's better to work on a clean fork of crop_rec_4k_mlv_snd.

Yes, I did that. Basically the various development branches went into the Cuisinart and they blended together quite nicely with very few conflicts. Then I added some work I did go get the 7D working and voilà, a branch where the old 5D2 and 7D can live side by side with newer 5D3, 70D and the rest of the family too! @aprofiti - that means your 50D and eventually your manual_lens_info pull request should also be working on all cameras.

Ok--so much for the sales pitch, it is not quite ready for prime time. There's some build script problem that prevents "make zip" from working properly though "make install" works fine. Go figure. I'm also sure there are a few bugs that need to be addressed. Right now let's call it more a proof of concept.

Regarding code from Waza, is it still necessary or a better way to allow digic4 to work on this branch was found?

Edit: just read though the crop_rec code and there's no code for waza57 crop_rec branch
There no reference to 5D2 in the code at all , so I would say it didn't merger any think for waza57 source "crop_rec_4k_5D2 " branch

 

Oops, that's the one branch that I haven't merged in yet. Thought I did it earlier. Need to resolve a few conflicts.

Well, it does answer the question whether Digic 4 can work on this branch but in order to get the crop_rec module working it does need some more work and since waza57 and reddeercity have already done that let's see if it can be merged in with the mainline experimental branches without breaking anything.

[dfort]

Ok--still a little ruff around the edges but I got something that might work. Tested on the 7D and it does 10/12bit, the 50D should work the same. Now on the 5D2 I'm interested if the crop_rec module is working, it is from waza57's crop_rec_4k_5D2 branch. If it does work it would be interesting to see if reddeercity's crop_rec module works in this build.

Posted test builds on my downloads page. Look for the builds from the magiclantern-crop_rec_4k_mlv_snd_experiments_waza57 branch.

@reddeercity - waza57's changes are showing up now:

https://bitbucket.org/daniel_fort/magic-lantern/commits/branch/crop_rec_4k_mlv_snd_experiments_waza57?page=5