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 - dfort

Pages: [1] 2 3 ... 121
Wow, this is getting messy but some good points are being raised.

Much of the conversation is going on a "fake" pull request I made to see if we could merge the changes needed to get the manual lens lua script working on the crop_rec_4k branch:

aprofiti did a similar pull request on his repository against the crop_rec_4k_mlv_snd branch:

However, the conversation is continuing on my repository so I merged my changes so far while trying to follow the conversation and created a new pull request to see the changes against the crop_rec_4k_mlv_snd branch:

Still very much a work in progress.

General Development Discussion / Re: Canon EOS 1300D / Rebel T6
« on: Yesterday at 08:40:23 PM »
In file fps-engio.c is OK this value?

I think that the timer values need to be found on the actual hardware.

As far as the QEMU error messages, I'm getting that too. Not sure if this is anything significant that needs to be worked out before trying out a minimal build on the camera.

General Help Q&A / Re: Exposure Confusion.
« on: July 14, 2018, 11:54:07 PM »
I can probably get my hands on one of these and maybe try running some logs to see what it is doing. The instructions on how to use it might give a hint.

Waiting for you guys, as I can't test this PR because my camera is not supported

Tried your new branch but it doesn't bring up the manual lens info menu when starting the camera without a lens mounted. It also shows this message when starting up the camera with the lens.lua script on Autorun mode.

My attempt does bring up the menu but mlv_lite isn't working.  :-[
[EDIT] However, silent MLV using mlv_lite does work as does xml with CR2  :)

General Help Q&A / Re: Exposure Confusion.
« on: July 14, 2018, 06:23:31 PM »
With a manual lens mounted, Canon's exposure indicator and exposure simulation in LiveView unfortunately cannot be trusted in M photo mode, on many models, including 5D3 (in particular, but not only, after shooting with a narrow aperture on a Canon lens). Expo override attempts to fix the latter, but since I don't use Canon's exposure indicator (here's why), I didn't even think about testing it.

Necroposting this because I stumbled on a "EOS Live View Correction Cap" that is supposed to "fix" this problem. Apparently this is a big issue with the stop motion animation studios. Many of these studios shoot with Canon cameras and manual lenses.

Note: Found out about this hardware solution while answering a post on a different topic:

Maybe there's a way to do the same thing in ML using patchmgr?

Is there a better way to send/transfer photos from 5d3 to computer monitor in real time? 

Many of the stop motion animation studios are using Dragonframe. Their software can probably do what you want.

Going off topic--found this product on their website called an EOS Live View Correction Cap. It sounds like this "fixes" an issue a1ex has mentioned before -- need to find those posts.

Quote from: Dragonframe website
Many of the EOS cameras have a setting called “Exposure Simulation.” This setting is designed to ensure the Live View image brightness matches the actual photos shot. Unfortunately Canon drops the ball with non-digital lenses. The camera actually knows the current correct exposure, hence the ability for the light metering to be correct, but fails to communicate properly to the internal “Live View Exposure Preview Calculator.” Instead, the internal calculation is locked—based on the last digital lens attached to the camera.

Why does it not show up in dfort's latest build for 650D.105?

Ok--so I didn't miss anything?

Different time zone here and I was working today.

@aprofiti - You have a good understanding of this. I only got the crop_rec_4k merge barely limping along. It would be great if you could create a branch on your fork and point us to it. Of course eventually make a pull request on one of the experimental branches in the main repository.

The patch didn't apply cleanly on mem.c so I had to do some manual labor but it is working!

Of course it could use some more testing but the manual lens lua script menu does come up if you start the camera without a lens attached.

Turned into a monster changeset.

Ha ha --

Quote from: g3gg0
the only thing that is bugging me - it will cause conflicts when merging the crop_rec branch.

Yeah, this is getting complicated.

It should be ok, but it needs "script/lib" folder from manual_lens in order to run lens.lua

Thanks. Added that but it isn't working yet. Need to dig in a little deeper when I've got some time.

Tried applying that patch but it didn't apply cleanly for me so I had to do some manual fixing. Ran out of time to do any significant testing but you can pull it from my ML fork, crop_rec_4k_ELNS branch.

Made a fake pull request to check what has changed:

There's some experimental tuff in the current crop_rec_4k branch, especially for the 700D and EOSM, so we should probably wait until that is sorted out before adding ELNS.

Post-processing Workflow / Re: software to process dng?
« on: July 10, 2018, 04:41:06 PM »
@psdn - You don't need to buy Resolve. The free version is usually all you need. We're starting to test their newest version 15 Beta (Studio version) and it does work better with their hardware and operating system recommendations.

Post-processing Workflow / Re: software to process dng?
« on: July 10, 2018, 07:40:06 AM »
Davinci resolve runs beautifully on win7...

And Linux. Been testing the latest beta version at work with both of these operating systems.

Camera-specific discussion / Re: Canon EOS M
« on: July 10, 2018, 05:34:06 AM »
Some interesting action going on with this pull request:


Never knew how the Low Light mode in FPS override is supposed to work because it was broken on the EOSM. It is working now, though with some issues. It would be great if some other EOSM users who can compile the latest crop_rec_4k (not the sound branch) try it out.

General Development Discussion / Re: Canon EOS 1300D / Rebel T6
« on: July 08, 2018, 10:38:45 PM »
That address is in R5, not R0.

Right--I edited my post after I realized that but maybe you didn't see the update when you made your post.

Code: [Select]
fe166c78:  ldr r5, [pc, #-996] ; fe16689c: (00036ec0)

So we should be on the right track here:

Code: [Select]
#define FOCUS_CONFIRMATION (*(int*)0x36EC4)
Whether that actually does what we expect (i.e. becoming TRUE when focus is confirmed, even in MF mode), remains to be seen. On 700D, 650D, 100D and EOS M, apparently it doesn't.

Does it work on the 1200D? That's what we (critix and I) are mainly using because it seems to be the closest match to the 1300D. Of course that camera is also fairly early in the development stages. However, if we look at that same section of code (near focusstatus %x,%x) on the cameras you say focus confirmation isn't working, we come up with some different values.

Cameracurrent valuepossible change?

I couldn't find it on the 100D using this method but I didn't try very hard.

So how to confirm focus confirmation is confirming? Is there a test for it? Maybe a simple lua script will do the trick?

[EDIT] Is this why trap focus isn't working on these cameras?


Ok--that page says it is "EOS 6D Firmware Version 1.1.6 for Windows" but the download link is for 1.1.8. Yeah, confusing.

What you have to do: load and write down the address for registers 805F and 8061 (at the bottom of screen).

Short answer:


Ok--so this confirms the values that were already found for the EOSM but the journey I took to get there was rather interesting so here comes a longer answer.

Reply #1745 points out some "much-needed refactors" so I assume that is happening in the config_var_refactor branch. That branch was recently merged into the lua_fix branch but there isn't a new build posted on the experiments download page yet so another assumption is that this isn't ready for regular users yet. Tried compiling adtg_gui in the lua_fix branch and it didn't compile. Tried the one posted on the modules download page but that didn't work either. Ok, we're only looking for register addresses at this point so I compiled the iso-research branch and got the addresses.


Something weird happened on the EOSM. I couldn't get to the 805F and 8061 registers at first because the camera was set to 1280x720/60. However, I could see the 805E and 8060 registers. (Note that on the 700D all these registers are visible at the same time.)


Switched over to 1920x1080/24 and the registers we're looking for showed up.


Note that I might have had to push the zoom button for the registers to show up but I'm not sure if that was necessary.

I did a search for FRAME_SHUTTER_BLANKING_ZOOM / FRAME_SHUTTER_BLANKING_NOZOOM and here is where things started getting interesting. As a1ex mentioned, FRAME_SHUTTER_BLANKING_WRITE is disabled on the EOSM. What I found was that all of the FRAME_SHUTTER_BLANKING constants are disabled on the 100D. In addition, it uses the 805E and 8060 registers instead of 805F and 8061. Also interesting is that the 5D3 uses 805E / 8060 while the 6D uses 805F / 8061 and both of these cameras have all the FRAME_SHUTTER_BLANKING constants enabled.

Looks to me like 805F / 8061 is for mv1080 mode (maybe why FRAME_SHUTTER_BLANKING_WRITE is disabled on the EOSM?) while 805E / 8060 is for mv720 mode. So why are we using one set and not the other? Maybe there should be a way to use both sets of registers depending on the movie settings?

Ok--still need to look into the refactors. Should we be using the lua_fix branch for this? Maybe merge lua_fix into crop_rec_4k? Or should we start with just the config_var_refactor branch?

Looks to me that the link is pointing to the right file and working properly:

Camera-specific discussion / Re: Canon 550D / T2i
« on: July 07, 2018, 08:24:26 PM »
@Murkka - If you read through the link a1ex pointed out you'll see this:

Please try the lua_fix builds and report back. It might be fixed, but I'm unable to test on this model.

Have you tried that yet? You can download it from this page:


Commit 4cf70155104c appears to fix this issue, too:

You can look up that change and see if the build you are using includes it.

Is it possible to transcode pixel coordinates into a fpm list?

Just thought of something. The dcraw "badpixels" format files are formatted to fit the final image size while fpm files usually map the full raw buffer. You should be able to write a script that takes the Crop/Pan values along with the raw buffer size that is in the MLV metadata and re-map the coordinates so they line up with the full raw buffer.

Camera-specific discussion / Re: Canon 700D / T5i
« on: July 07, 2018, 06:27:29 PM »
Ok--it isn't being used but it is obviously the wrong address so how about we fix it in case we need to get back to it in the future?

Hey, that gives me an idea for a movie  8)

Pull request respectfully submitted:

@dfort, @bouncyball
Is it possible to transcode pixel coordinates into a fpm list? Let's say you create your own "dcraw" coordinates and then needs them working with fpm lists in mlvfs etc? Maybe doable through fpm utility?

Lots of activity here -- trying to keep up.

The main differences between a dcraw "badpixels" file and our fpm format is that dcraw includes the "UNIX time of death" and fpm needs to have either a header or the filename must include the hex code for the camera model and either the full raw buffer size or the image size. Note that the dcraw developer has documented the "badpixels" format but fpm is mostly undocumented.

If you add the metadata to the files you uploaded they might work without any further processing. Depending on the app you're using the trailing zeros are ignored. We just aren't interested in "UNIX time of death" for the pixels that we're fixing.

By the way, I'm all for fixing the focus pixels when creating the DNG files but prefer not to mess around with modifying the original MLV files. They should be archived the way they were saved in camera because some day we'll have better MLV processing tools and may want to go back to our camera originals.

General Development Discussion / Re: Canon EOS 1300D / Rebel T6
« on: July 07, 2018, 08:19:25 AM »
How did you find those values--pattern matching? I found the same by pattern matching but searching for the same pattern on the 1200D resulted in completely different values than what was found to work on that camera. So my guess is that the values that you found are probably not ok.

On Reply #220 a1ex provided some links that if you follow will lead you a wiki article on Struct Guessing. It uses the FOCUS_CONFIRMATION stub as an example. I checked the example against the 550D.109, 60D.111 and 1200D.102 and they all have a structure that looks something like this:

Code: [Select]
So the value we need to search for is 0x4 less than the value of the FOCUS_CONFIRMATION stub that was found for the camera you're using to pattern match to.

After working through the article my guess is this:

Code: [Select]
#define FOCUS_CONFIRMATION (*(int*)0x5C7D1)
Assuming that the FOCUS STRUCTURE ADDRESS = 0x5C7CD

Look up this string in the disassemblies and the pattern to match is a few lines down from there.

Code: [Select]
"    focusstatus %x,%x":
[EDIT] On second look maybe a better guess would be this?

Code: [Select]
#define FOCUS_CONFIRMATION (*(int*)0x36EC4)
Assuming that the FOCUS STRUCTURE ADDRESS = 0x36EC0

The 1300D is somewhat different from the other cameras we're using as references so it is a bit tricky to find the right lines that match up.

Camera-specific discussion / Re: Canon 700D / T5i
« on: July 06, 2018, 08:12:26 AM »
Found some stubs that were off on the EOSM and in the process might have found one on the 700D too. I'm pretty sure this needs to be adjusted but am not sure how to test it.

Code: [Select]
-NSTUB(0xFFA73C58 - RAM_OFFSET,  TryPostEvent_end)
+NSTUB(0xFFA73C5C - RAM_OFFSET,  TryPostEvent_end)

Pages: [1] 2 3 ... 121