Messages

Got these errors every other couple of shots today with latest build:

Live display; text in red:

'fatal no buffers'

then a few seconds later

'audio failed to stop. read state 3'

only a 3kb file is saved with no content.

Pressing menu then allows a proper recording, but the whole cycle repeats again.

I was recording in 3K as usual, with NO audio, so that's odd!

Anyone replicate this error?

Thanks.

[4952e34]

Very interesting developments. Thanks to the brains behind it!

I notice that commit 4952e34 is cmos_cal.c - compatibility with other cameras

In layman's terms does this mean it is now possible to run the cmos_cal.mo on say 5D3, and if one can discover the correct RAM addresses add this data and complete a sensor calibration?

If one knows what one is doing – of course...

Hah! I wasn't so far off the mark after all!

I shall expect a beta by Monday then! 

@a1ex Many thanks for clarification and links.

These values should be tweaked so all these 8 groups of columns have consistent output; otherwise, you get vertical stripes / banding...

I've found this also true of the ADTG2/4 0xFE register. Uneven values between the banks give a similar result.

Audionut on March 02, 2014, 03:20:11 PM
Does iso_regs scale [8,9,A,B], keeping the deltas between them?

a1ex
Yes. It considers the first one as reference (that one will get the value from menu) and all the others as delta (so, when you set it to 0 or 1 or maybe even 2 or 3, it may underflow and cause strong banding). I preferred this underflow instead of clamping to 0 because in this way you see when you went too far. However, ADTG gains 888x are not scaled in iso_regs (these are simply set all of them to the same value).

I'm reviewing whether the decimal adjustments in my Q iso-regs menus are using the correct math. Line 1205 > https://bitbucket.org/rivertim/magic-lantern-danneclone/src/ddebb19831d7ce7472bb80db9926bc69b3bc2d6d/modules/crop_rec/crop_rec.c

Is the "deltas between them" described by @a1ex and @Audionut in this context meaning to keep the integer relationship constant? e.g.

Say for: ADTG2 8,9,a,b values = 0x60,0x61,0x62,0x60 meaning x, +1, +1, -2 Do the relationships scale as they change?

Sorry for math duh-ness! 

**EDIT**

a1ex
However, ADTG gains 888x are not scaled in iso_regs (these are simply set all of them to the same value).

I notice in adtg_gui my values for these (888x) registers are different:

Code Select Expand


ADTG2[8882] = 0x436
ADTG2[8884] = 0x438
ADTG2[8886] = 0x439
ADTG2[8888] = 0x43a

ADTG4[8882] = 0x437
ADTG4[8884] = 0x437
ADTG4[8886] = 0x437
ADTG4[8888] = 0x43a



Should they in fact all be set to the same value?

Thanks!

You can tell I'm not a 'proper' developer because I start with the UI as my inspiration...  To each his own I guess.

But joking aside, working away from presets – and towards a single all-camera build that can accommodate any user's input (up to a specific camera's limits) is inspirational to me! Not so long ago 4K was simply a dream in search of realisation. 

If the current dev work allows for choice of resolution, bit-depth, binning, ratio, frame-rate etc., I can see edge cases for which a user might select 96fps (or 120!) if the final output is going to be a 20s 340p clip seen only on a mobile device! (Is this actually possible btw – or are we hitting the 5D3 card write speed limits?)

I know it's easy to reel off this functionality wish-list, and – having recently dipped a toe myself into developing – quite another to deliver it. But we all need a goal.

I guess I've just set mine pretty high!

Any 10cents?

Would be nice to integrate the style/functionality of those bit-rate type calculators into ML – which then prepares settings to shoot with. Happy New Year all! 

Cool menu edit + new toys... Thanks!

Notice that with Sound recording = ON, the camera start/stop beeps don't sound. Turning Sound recording = OFF brings them back. Is this expected behaviour?

Hi!

Just cloned your crop_rec_4k_mlv_snd_isogain_1x3_presets_2020Jan01 repo and tried to add my iso-regs code into it.

Think maybe I've done something wrong as the new 'Presets' tab is there – but when I try and select it, it doesn't activate.

Can you see something I've done wrong? Maybe I need to add things in different places now... 


Ignore pls!

For some reason my crop_rec.mo wasn't compiling at all... Compiled separately and it works now.  Sorry... 

Cheers!

Some point soon you may have to sit down and learn C

Well, I've made a start with some tutorials... but my mind just isn't at its best thinking in code.

@Danne Many thanks! That's great news.

lv-img-engio.c looks scary... 

I'm looking for some pointers for making my iso-regs Q-menu adjustments available in NON-crop modes (i.e. mv1080p). 

This would mean using a different Q-menu, say in Movie > and either > Image Fine-tuning or Movie Tweaks.

I can see the Image Fine-tuning functions in lv-img-engio.c https://bitbucket.org/hudson/magic-lantern/src/crop_rec_4k/src/lv-img-engio.c

Is this the right place to add these reg-adjust functions - or am I on the wrong track?

Thanks!

Looking at your code, I think you have an integer overflow bug when you're setting registers using 0x400 + reg_x pattern.  Because the addresses you're assigning to are later considered to be 2 bytes wide, and menu input + the constant could make this higher than uint16_t max.  This could lead to menu choices giving the user a radically different result than they expect.  You should probably clamp the value to between 0 and uint16_t max.  Also since your variable is signed, underflow will lead to sign extension and really mess your values up.

@names_are_hard So far, with the code as-is I'm seeing the kinds of changes I'd expect to the regs targeted. With the integer overflow bug, are we talking values that the user thinks they're inputing at 10 are actually [say] 100? Is that the sort of discrepancy you outline?

Thanks! More reading! lol

For the record: I have indeed read this entire thread through – twice. It just takes a long time to filter through me!

[**UPDATE**]

@names_are_hard Thank you for your comprehensive answer. I will have to reflect awhile on the information to understand it fully.

@Audionut Thanks! I will explore the 'SET' button option. I am conscious that there are thousands of registers as yet unknown! So maybe the values I am trying to find are amongst those.

**UPDATE**
Used adtg_gui to spy registers: > 'Changed since now' and 'ISO related'
If anyone is looking for these values they report as follows:

Code Select Expand


ADTG24[7] = 0x0
ADTG24[8] = 0x5a
ADTG24[9] = 0x5a
ADTG24[a] = 0x5a
ADTG24[b] = 0x5a
ADTG24[1b] = 0x320


They've no doubt been discussed before – but possibly way back in the thread.

Thanks! "initial" is certainly a better way of describing my "default" yes! 

Since I know certain initial values (which I already assign to certain regs) it looks like your code might override all adtg_new?  – whereas I want to set "initial" to only certain regs, on a line by line basis – and then override it.

Might that be something like?:

Code Select Expand

set_adtg_defaults(adtg_new[25], adtg_new_size);  // sets whatever the "discoverable" algorithm is for only adtg_new[25] register.
adtg_new[25] = (struct adtg_new) {6, 0x14, 0xdead};  // then override the initial of adtg_new[25] with 0xdead


PS Here's how I'm doing the existing overrides which is working:
https://bitbucket.org/rivertim/magic-lantern-danneclone/commits/7fce7f696aa1ae67c4aa16248c497a612bc10761
(Not sure why that file is marked 'DRAFT', as I committed and pushed changes to that repo days ago!?)

Hey!
Certain registers such as ADTG Preamp et al are set at Canon default values at boot.

So the above example (ADTG Preamp) loads default values of: 0x60,0x61,0x62,0x60 and 0x63,0x65,0x63,0x63 for the various columns/colour channels. These values are discoverable through the documented work of others in adtg_gui.c and iso_regs.c

There are other register for which I can't find values that load at boot i.e. 'default' values, that I wish to address. I was asking whether there is some code that says "load default value if discoverable, or set a safe value as default" – rather than have me set some crazy inappropriate value of my own! 

Hence my crude attempt:

Code Select Expand

adtg_new[25] = (struct adtg_new) {6, 0x14, default_value};

Does that make sense? 

I'm trying to pass a default value to some registers for which I can't find any [default] values listed in adtg_gui or iso_regs.

Is there some code that says: 'set to default value' even if that is not known?

Something like this:

Code Select Expand


adtg_new[25] = (struct adtg_new) {6, 0x14, default_value};


Thanks!

I've been experimenting with different build sources for my Q-iso menu (AKA 'TNT' build) https://bitbucket.org/rivertim/magic-lantern-danneclone/downloads/ because I want to nail down my hunch that there are subtle exposure differences between modes – and builds itself. Have typically used: an old @a1ex build from Dec17, iso-research build, and various @Danne's with success.

Yesterday I tried the most recent crop_rec_4k from the 'Downloads' page on the ML site. 22Jul2018. There appear to be some issues with this build:

1) Laggy response shifting through main/sub menus.
2) Top half of LiveView often fills with pink 'mist' – looks like preamps settling (without any 'regs' enabled). This can suddenly fade. Or it can persist and record into the file. Haven't seen this before.

Anyone have any suggestions on which recent build from this branch is a better bet?

Many thanks.

PS Should I be looking to this page for clues? https://builds.magiclantern.fm/jenkins/view/Experiments/job/crop_rec_4k/changes

@a1ex All good stuff to know. Many thanks for sharing. 

I cannot see your screenshots without looking at the source code of your post (JS issues?)

How odd. I'm seeing them on my browsers (Chrome & Safari on Mac)! I used https://imgbb.com/, which usually works ok.  Anyone else not seeing my images preview?

@a1ex Many thanks! Very thorough explanation. Have updated to latest raw_diag.mo

It's a whole lot better – but I'm still occasionally (2 out of 10?) getting the 'Busy' on second SNR shot. Sometimes I can settle the regs with a MENU button press. Other (now rare) times the camera locks (batt pull). But it seems certainly workable with now! Is this relevant: Debug > (Red dot) Memory Patches - 1 ROM,2 RAM and a message in yellow text at the bottom: "Cache is locked down (not exactly clean). A Ram management issue?

Now, the question is whether to trust these numbers;

Funny you should say this...

I see a whole EV DR readout difference between the small readout window say at DR 11.62 and saved chart: EV 10.88

And the histogram often tells another story... Which to trust? 

@anyone I think these have come to light as the testing of my Q-iso-regs build requires the clip point to be set exactly for the benefit to be seen at its best.




My SNR charts look a bit left biased. Shouldn't the curve be to the right more – given the scene DR?

@a1ex Thanks!

ready for the grand public?

I consider myself part of the great unwashed!

Nice catch. The diag box does now appear! But to operate the 2-shot it has to be turned back to 'Hold' – whereupon my camera still goes 'Busy' and locks up. Will research "hg bisect".

Cheers!

I have uninstalled ML completely. Restored Canon FW. Reinstalled ML.

Things are working again in basic crop_rec mode, however I can't get raw_diag.mo to show the small liveview reporting window (EV etc).

Is there a definitive version of raw_diag.mo I should be using?

Also, there is a message in Debug > (Red dot) Memory Patches - 1 ROM,2 RAM and a message in yellow text at the bottom: "Cache is locked down (not exactly clean).

Is this telling me something's wrong?

Hi

In several different 5D3 builds incl: my own, danne's, a1ex's (with no reg changes!) I'm having big problems with taking the second picture of the SNR 2 shots in raw_diag module. 9/10 I am getting 'BUSY' displayed, and the camera locks/needs batt pull. I get no second picture saved.

I notice also that when the camera is sitting there OFF, the red light pulses every few seconds... This doesn't happen consistently though. Something odd going on...

Could someone offer some help please?

So, someone "just" needs to automate the process with some module and embed the frame in each .MLV file

Such an interesting rabbit hole to disappear down!

@Luther Do you think there would be a hit to performance if it's encoding another frame?