Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - dpjpandone

Pages: [1] 2 3 ... 17
1
General Development / Re: Fine-tuning Framing preview to speed it up
« on: February 07, 2023, 09:09:59 PM »
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.

2
General Development / Re: Fine-tuning Framing preview to speed it up
« on: February 06, 2023, 05:45:58 PM »
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

3
crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: February 05, 2023, 02:24:13 AM »
I went all the way down to 256 and did not notice an improvement

4
General Development / Re: Fine-tuning Framing preview to speed it up
« on: February 03, 2023, 05:11:49 PM »
You need to deletew your settings folder

5
crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: February 03, 2023, 05:09:21 PM »
Refresh speed? CPU overhead? Write speed? Which speed?

6
crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: February 03, 2023, 04:14:18 AM »
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]
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]
while (((white-black) >> div) >= 700)
I can't figure out what (or why) this does?




7
General Development / Re: Fine-tuning Framing preview to speed it up
« on: February 02, 2023, 10:50:41 PM »
Very stable with the following values:

Code: [Select]
(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.


8
General Development / Fine-tuning Framing preview to speed it up
« on: February 02, 2023, 10:26:04 PM »

This part of code:
Code: [Select]
    /* 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]
     /* 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?

9
General Help Q&A / Re: No Shutter Speek Lock on 5DIII?
« on: February 02, 2023, 01:26:15 PM »
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.  ;)

10
General Chat / Re: New PTP Camera Controller App for Android
« on: February 02, 2023, 02:09:51 AM »
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

11
Reverse Engineering / Re: LiveView Investigation
« on: February 02, 2023, 02:03:34 AM »


**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.....

12
Reverse Engineering / Re: LiveView Investigation
« on: February 02, 2023, 01:57:16 AM »

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



Woah! That is wonderful!

13
crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: February 02, 2023, 01:26:39 AM »
OK, I did not add this (because I don't understand it)

Code: [Select]
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

14
crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: February 02, 2023, 12:21:20 AM »
Danne:

Code: [Select]
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]
if (get_ms_clock() - last_hs_unpress > 300) ?



15
General Help Q&A / Re: No Shutter Speek Lock on 5DIII?
« on: February 02, 2023, 12:04:59 AM »
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

16
General Help Q&A / Re: No Shutter Speek Lock on 5DIII?
« on: February 01, 2023, 11:55:13 PM »
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?

17
General Development / Re: Using stubs vs. Hardcoding stuff into modules
« on: January 31, 2023, 07:54:38 PM »
Code: [Select]
* 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]
NSTUB(0xFF16E318,  lvfaceEnd)
NSTUB(0xFF23FF10,  aewbSuspend)
NSTUB(0xFF181340, CartridgeCancel)

Code: [Select]
#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]
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]
NSTUB(0xFFA0321C - RAM_OFFSET,  AbortEDmac)
this^ is a different format, does the format itself tell me how/what to send?

or

Code: [Select]
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]
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?


18
crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: January 31, 2023, 03:22:41 PM »
Flicker stuff. No idea.

I did a search for CONGIF_KILL_FLICKER in all files
Code: [Select]
  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!

19
General Development / Re: LiveView hacks (write speed improvement)
« on: January 31, 2023, 02:43:53 PM »

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

20
General Development / Using stubs vs. Hardcoding stuff into modules
« on: January 31, 2023, 02:41:32 PM »
I can give some advice.

Firstly, modules are built outside of the context of any individual cam.  This is because modules are supposed to be portable: people can copy them from one card to another in a different cam and they're supposed to work.  TCC code on the cam handles loading modules and looking up symbols by name.  This is the way that modules find stubs.  If a symbol doesn't exist, the user will see an error and the module won't load (but ML won't crash, it's more like a warning than a real error).

If you define something in features.h for a cam, I think it won't be visible to the module during the build.  Even if it is, it won't work properly if you copy the module and use it with a different cam, so this isn't a correct approach.

I was suggesting that *things which are functions* could be moved to stubs.  I haven't looked at the variables like more_hacks_are_supported, so I don't know what these do or what the best way to handle them is.

You should be able to test your ideas in qemu.  First get the existing code working and test it emulates this far (should do I think).  Then make changes and see if you broke anything.

I suppose it depends what you mean by "doing stubs wrong" :)  In the module code, where it's just an address, I haven't checked how it's used.  In a stub context, it will be treated as a function pointer according to the definition of NSTUB (or ARM32_FN / THUMB_FN if you use those).  Is it appropriate to treat these addresses in that way?  That depends how the module uses them.  In the exact text you gave, you put them in as comments, which will do nothing (and the symbol won't get exported, so the modules won't find it).

Probably, but that's a bigger question than you might realise.  I think the intention when ML added lots of supported models was that they'd all get all the features eventually.  Later on (I guess) as you've found, FEATURE and CONFIG limit or specify features, but that doesn't work well with modules.  Modules are *supposed* to be cam independent, but actually this was never true, there were some edge cases that became apparent when we worked more on modern cams and found that some structs and other internals had changed enough that some assumptions around how modules worked failed.

So, what's an elegant way to let modules behave the right way on a range of cams?  My personal feeling is modules could, instead of doing this:

Code: [Select]
if (is_camera("5D3", "1.2.3"))
{
    screen_x = 0x0101; screen_y = 0x0202;
}
else if { // many other cameras omitted }

Do something like this:
Code: [Select]
    get_screen_x_y(screen) // screen is a struct with .x and .y members

That is: cleanly separate modules from ML code, so they can only work via exported functions.  Modules ask the cam what the right values are for that model.  No hard-coding values inside modules.

So in your specific example, create a stub for *all* cams maybe called is_more_hacks_supported() (this is a bad name, but you get the idea).  This would probably default to returning false, and be overridden by cams that did have support.  Then the module code is greatly simplified - no per cam checks, but something like this:

Code: [Select]
    more_hacks_supported = is_more_hacks_supported();

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.

you put them in as comments

didn't want those to compile yet



So in your specific example, create a stub for *all* cams maybe called is_more_hacks_supported() (this is a bad name, but you get the idea).  This would probably default to returning false, and be overridden by cams that did have support.  Then the module code is greatly simplified - no per cam checks, but something like this:

Code: [Select]
    more_hacks_supported = is_more_hacks_supported();



is this the correct syntax to do such a thing?

Code: [Select]
NSTUB(1 - is_more_hacks_supported)
and cams that do not support it the stub needs to be 0 ? Or you start by saying:

Code: [Select]
more_hacks_supported = 0; //defaults to 0
more_hacks_supported = is_more_hacks_supported() //returns value set in stub

If there is no stub in another cam's Stubs.s does it return 0 automatically?

21
crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: January 31, 2023, 02:17:08 AM »
What build are you on? Always leave it at 14bit lossless. Then reduce bitdepth from Movie tab.

This is your Jan 9th build. perhaps you should change help to:

"reduce bitdepth from Movie tab" ??

and clarify that this is or is not compressed?

hey btw, is there any possible side effects for defining CONFIG_KILL_FLICKER on 5d3? It looks like this was an easy way to add Kill canon Gui, but could this possibly slow down other stuff that we dont wish to interfere with?

22
General Development / Re: LiveView hacks (write speed improvement)
« on: January 31, 2023, 02:12:35 AM »
I can't check it thoroughly because I don't have a 5D3 and I don't know what precise code you're working from.  I can give some advice.

Not asking you to test it, just to tell me if I'm doing stubs wrong.


If you define something in features.h for a cam, I think it won't be visible to the module during the build.  Even if it is, it won't work properly if you copy the module and use it with a different cam, so this isn't a correct approach.


This is helpful. On second glance I can't find an example of a module calling ifdef(feature xyz)




I was suggesting that *things which are functions* could be moved to stubs.  I haven't looked at the variables like more_hacks_are_supported, so I don't know what these do or what the best way to handle them is.


more_hacks_are_supported is basically just to hide the option from the menu in cams that don't support. Is there a more elegant way to accomplish this?

23
crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: January 31, 2023, 01:17:19 AM »

24
crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: January 30, 2023, 11:41:03 PM »
But does it work?

Does not allow the user to select 12bit lossless in 3.5k mode. It automatically reverts to 14bit lossless. I think you reused the portion of the code that blocks lossless 12-8bit in HIGHER resolutions (4k...etc.) but 3.5k was always working from the inception of crop-rec on steroids

25
General Development / Re: LiveView hacks (write speed improvement)
« on: January 30, 2023, 08:14:43 PM »

These would likely be better as stubs.  That way you could remove the per cam code from the module, and just call the stubs - same name for all cams.

I'm trying to learn how to do this properly. Can you please check my work?

The code from TheBilal was:

Code: [Select]
if (is_camera("5D3", "1.2.3"))
    {
        lvfaceEnd  = (void *) 0xFF16E318;
aewbSuspend = (void *) 0xFF23FF10;
CartridgeCancel = (void *) 0xFF181340;
more_hacks_are_supported = 1;
CartridgeCancel_works = 1;

The first step I think is to add this to Stubs.s in 5D3.123:

Code: [Select]
/** LiveView Hacks For Write Speed Improvement **/
///NSTUB(0xFF16E318,  lvfaceEnd)
///NSTUB(0xFF23FF10,  aewbSuspend)
///NSTUB(0xFF181340, CartridgeCancel)

now when we get to:

Code: [Select]
CartridgeCancel_works = 1; should this go in Features.h ?

like this?:
Code: [Select]
#define FEATURE_CARTRIDGE_CANCEL// write speed improvement in LiveView
#define FEATURE_MORE_HACKS// write speed improvement in LiveView 

Let me stop here because I dont know if it's ok to define a feature that is dependent on a module?




Pages: [1] 2 3 ... 17