Messages

Is it possible to have L/R buttons change shutter speed ? I use manual lenses so it makes more sense to have Up/down buttons change ISO and have L/R buttons change shutter since those two are only things we can control with manual lenses.

scroll the wheel

The EF-M 22mm is undoubtedly a very good lens but get your facts straight: MLVApp is the culprit because it does have lens correction profiles (CA + distortion + vignetting), which are automatically applied, recognized and cannot be toggled off. If you want to deactivate those you'd have to grade using CinemaDNGs inside RawTherapee/Lightroom/CameraRAW/etc.

Besides, any decent CCTV or industrial lens is on par if not superior to the EF-M kit lenses (uncorrected). They have wider fields of view on both Canon's (x1.66) and Bilal's/Danne's various crop factors and way, way faster apertures (i.e f/0.95 25mm Schneider-Kreuznach's Xenon). Not to mention the vast selection of other adapted C-mount lenses that were meant for video/photo/Bolex/whatever (Angénieux, Berthiot, Wollensack etc). Heck, even some properly adapted D-mount lenses are just as good if you can achieve infinity focus.

The only true downside to all those manual lenses is the lack of stabilization.

You open with "get your facts straight" then end with an opionionated rant about "the superior quality of CCTV lens" ?  How about posting some charts or citing reputable sources that your analysis is based on? 

If you don't have two cards in the camera there can be no spanning

[Year]

I had a thought yesterday which is black area limit is being controlled somewhere in preview initialization registers which being set once, e.g. doesn't change from video mode to another.
Firstly, I had to search among +2000 registers, until I narrowed down and got it. This year would definitely be the Year of Preview (well, at least for entry level models )


*Preview stuff is like crashing into a wall to find another wall needs to be crashed in then to find out there is a third wall ... etc

That sounds very tedious. Thank you for all your hard work!

yeah thats what happend when you enable "more hacks"

[How to find it]

-How to find it?
More likely by comparing video modes configurations, e.g. 1080p vs 720p and x5 vs x10. Find which function set YUV configuration, and where does it store it in memory?

are you doing this in QEMU? or in camera? Maybe if you make a video showing how you're comparing configurATIONS i COULD HELP YOU

I'm not asking you to incorporate this into your builds danne, I'm doing my own thing on 5D3.

I already added it as a menu option on mine. The way I have it set up is:

-realtime
-framing (same as it always was, automatically switches to Gray when buffer is almost full)
-gray ultrafast (full time)
-Frozen LV (liveview is frozen if kill global draw is set to enable in raw menu)

I have not worked out what the behavior should be on auto. That's what i wanted to talk about. It's fine if there is no interest.

Danne, bilal,

Can we talk about implementing an option under preview menu for full-time ultrafast gray? I was hoping we could all agree on menu structure/name/behavior so that it's consistent across bodies. Are you guys interested? first thing to discuss I think is behavior

I went all the way down to 256 and did not notice an improvement

You need to deletew your settings folder

Refresh speed? CPU overhead? Write speed? Which speed?

[New builds:]

New builds:

Testing this suggestion:
https://www.magiclantern.fm/forum/index.php?topic=25287.msg241992#msg241992

I'm pretty happy with the balance between speed and stability with those values.

I now understand that:

Code Select Expand

if (get_ms_clock() - last_hs_unpress > 300) is to make switching back and forth faster. This is good. personally 200ms is perfect for me

When you have a moment could you please explain lowering the gamma and white levels to <700 ? in raw.c:

Code Select Expand

while (((white-black) >> div) >= 700)

I can't figure out what (or why) this does?

Very stable with the following values:

Code Select Expand

(need_for_speed)
            ? ((queued_frames > valid_slot_count / 2) ? 416 : 208)
            : 20

(I chose multiples of 24/1000) .0416

Pushing it much harder produces slot error when buffer is full and recording stops (5d3.123)

I would like to discuss cleanest way to implement as a menu option, (and what to call it) I like the behavior when Gray Ultrafast is used full time, but pressing halfshutter switches to realtime (5x) almost like a magic zoom) I honestly think the color half-res preview is useless.

This part of code:

Code Select Expand

    /* be gentle with the CPU, save it for recording (especially if the buffer is almost full) */
    msleep(
        (need_for_speed)
            ? ((queued_frames > valid_slot_count / 2) ? 1000 : 500)
            : 50
    );

Controls when it's okay to refresh Framing preview depending on RAW recording state, this part of code add delays while recording for Framing preview to slow down refresh rate.
If you removed this part of code you will have semi real-time preview in B&W during RAW recording, of course this will make CPU usage 100% all time and there is high chance you will have corrupted frames.

But we can probably fine-tune the delay (reduce it), play with 1000 and 500 values (decrease them).
1000 and 500 are in milliseconds.

I am playing with this now. I think the only way to test for stability is to record in a resolution that is higher than continuous because the slot error happens when the buffer is full, any thoughts?

also:

I noticed Danne modified these values in Raw.c:

Code Select Expand


     /* scale useful range (black...white) to 0...1023 or less */
+    /* changing from 1024 to 700 for speed reasons */
     int black = raw_info.black_level;
     int white = raw_info.white_level;
     int div = 0;
-    while (((white-black) >> div) >= 1024)
+    while (((white-black) >> div) >= 700)
     {
         div++;
     }

-    uint8_t gamma[1024];
+    uint8_t gamma[700];
     
-    for (int i = 0; i < 1024; i++)
+    for (int i = 0; i < 700; i++)

Does this reduce CPU overhead?

Dear devoted moderator:

There is a menu option (ML) for shutter lock on small bodies that don't have this swtich. It does what the switch does. (locks shutter speed so you don't accidentally change it with shutter dial)

It's probably normal for a person who follows the upgrade path from small (XXXD) body to full-size (XD) body to wonder what happened to this feature. Hopefully having the correct answer/spelling on the subject will save you some words down the road. 

This has potential to be very useful. Most timelapses I am interested in recording end up with the camera in a very uncomfortable position to have to program the damn intervalometer from the LCD

**In the past, I tried some EDMAC write channels for RAW recording, some of them introduced corrupted frames, while others were perfect. And of course in our builds we are using the perfect ones.

I had this problem in 2014-2015 working on 7D. Tearing in the recorded image (like a split screen) when external monitor was taxing CPU. Changing to different EDMAC channel fixed it. I wish i could tell you why.....

-Also, the preview is now being calculated automagically in crop_rec, there are no hardcoded values for each preset.

Woah! That is wonderful!

OK, I did not add this (because I don't understand it)

Code Select Expand

if (get_ms_clock() - last_hs_unpress > 300)

but I found that the other changes certainly speed up the refresh rate of gray ultrafast, however I saw a consistent 1-2 MB/s drop (From 91.2MB/s to 88.3MB/s) in SD card write speed. I went back and forth testing before and after the changes to confirm. I guess this is the meaning of "Be Gentle, save for recording"


Got consistent "Frame order error Slot" when buffer filled up

Danne:

Code Select Expand

while (((white-black) >> div) >= 700)

good idea!

playing with it now, (btw I asked you about frozen vs/ gray ultra fast I have figured out that frozen call's ultrafast when need for speed kicks in)

why this:

Code Select Expand

if (get_ms_clock() - last_hs_unpress > 300) ?

And the answer is:

The "Lock" switch on the camera body can be set to lock any or a combination of the following:

shutter dial
wheel
joystick


Canon menu -> custom functions -> lock

I have the same question, therefore am reviving this old thread. I see it as a menu item (that doesn't function) In danne's build. Is there a good reason i shouldn't add this back in?

Code Select Expand

* Types of NSTUB values and how to find them:
* 0xFFnnnnnn - ROM address. Go to address in old ROM then find the matching ARM assembly code in new ROM to find the new value.
* 0xnnnnn    - Data address. Search the operands column for =0xnnnnn then find the same region in new ROM to find the new value.
* 0x000nnnnn - System routine. Search operands column for sub_0nnnnn then find the same region in new ROM to find the new value (do these ever change?).

means these are ROM adresses:

Code Select Expand

NSTUB(0xFF16E318,  lvfaceEnd)
NSTUB(0xFF23FF10,  aewbSuspend)
NSTUB(0xFF181340, CartridgeCancel)

Code Select Expand

#ifndef __STUB_H__
#define __STUB_H__

#define NSTUB(addr,name) \
.global name; \
.extern name; \
name = addr

#endif /* __STUB_H__ */


where does this go? The Stubs files in platform\Stubs.s looks like these:

Code Select Expand

NSTUB(0xFF136F68, _audio_ic_write)                          // str:Reg_0x_02X_Data_04x)

this ^ actually has a comment that might give a clue as to what/how info this can receive
or

Code Select Expand

NSTUB(0xFFA0321C - RAM_OFFSET,  AbortEDmac)

this^ is a different format, does the format itself tell me how/what to send?

or

Code Select Expand

NSTUB(0xFF137168,  SetAudioVolumeOut)

This^ I assume would accept a value how loud to set the volume, but how do I know what values I can send? and how to format said values?

then there's stuff like the ones I want to make into stubs. They just tell the camera to do a thing like "stop calculating autoexposure and white balance because" (because it's making write's slower) how should these be formatted:

Code Select Expand

0xFF16E318,  lvfaceEnd)
0xFF23FF10,  aewbSuspend)
0xFF181340, CartridgeCancel)

maybe the answers to these questions are really obvious to someone who is well-groomed in C and assembly, I've done some cool stuff with arduino making multi-axis motion control stuff for cameras/VFX work, but I usually found a well-documented library that did the lower level stuff and played around with a well-commented example to understand how it works so I can use it properly. If my questions are not ML-specific and you think I should study some other resources first so that i can ask better questions I don't want to waste your time maybe you could point me toward some preliminary study material that would help me become a better contributor to this community?

Flicker stuff. No idea.

I did a search for CONGIF_KILL_FLICKER in all files

Code Select Expand

  C:\ML4K\src\debug.c (1 hit)
Line  783: #ifdef CONFIG_KILL_FLICKER
  C:\ML4K\src\powersave.c (4 hits)
Line 150: #ifdef CONFIG_KILL_FLICKER
Line 243: #ifdef CONFIG_KILL_FLICKER
Line 383: #ifdef CONFIG_KILL_FLICKER
Line 469:     #ifdef CONFIG_KILL_FLICKER
  C:\ML4K\src\tweaks.c (3 hits)
Line 3421: #ifdef CONFIG_KILL_FLICKER
Line 3599:     #if defined(CONFIG_KILL_FLICKER) || defined(FEATURE_SCREEN_LAYOUT) || defined(FEATURE_IMAGE_POSITION) || defined(FEATURE_UPSIDE_DOWN) || defined(FEATURE_IMAGE_ORIENTATION) || defined(FEATURE_AUTO_MIRRORING_HACK) || defined(FEATURE_FORCE_HDMI_VGA)
Line 3606:             #ifdef CONFIG_KILL_FLICKER
  C:\ML4K\src\zebra.c (3 hits)
Line   71: #ifdef CONFIG_KILL_FLICKER // this will block all Canon drawing routines when the camera is idle
Line  433:             #ifdef CONFIG_KILL_FLICKER
Line 3893:                 #ifdef CONFIG_KILL_FLICKER
and I did not find anything that would have adverse effects on performance, It seems to just call CLRSCREEN in certain instances as a fix for 50D in powersave modes. your idea to use it to remove canon 5x  overlay was brilliant!

Is this the best way to go?  That's harder to say.  It would increase the size of the ML binary, while reducing the size of modules.  Size constraints are a real concern on some cams.

I have created a new post in General Development in order to keep this thread on topic:

https://www.magiclantern.fm/forum/index.php?topic=26779.new#new