Messages

DR not only ignores ACR metadata tags, but not supports RAW parameters ramping at all.

The tag in question is not specifically ACR metadata (XMP Exposure), but rather a tag that's part of the DNG spec called BaselineExposure. It *should* be honored by all raw processors, but that doesn't mean it is.

The deflicker algorithm simply attempts to hold the exposure (the apparent brightness) of every frame constant. It simply adjusts the exposure of each frame so that the median matches the given parameter. It analyzes actual image data and gives no regard to exposure parameters or anything else.

I suppose it would be possible to write a different sort of algorithm that does closer to what it seems you want, either by logging the digital ISO values in the MLV file and then using those in the exposure offset tag, or by detecting changes to exposure parameters (full mlv_rec only, wouldn't work with mlv_lite) and automatically ramping between them.

The PFM version of MLVFS is very old and doesn't have the deflicker stuff. You'll need the latest version (dokany). Also, the deflicker amount computed by MLVFS is added as metadata to the DNG, not all raw processors honor this tag (ACR does, others IDK).

http://www.magiclantern.fm/forum/index.php?topic=5473.msg179973#msg179973

Do you see it on this page: https://bitbucket.org/garry23/dof-fix-for-focus.c/pull-requests/

Click it, then select for the "source" (left side) your branch with changes from your repository and select for "destination" (right side) the "unified" branch of the hudson repository.

The first google result for "bitbucket create pull request":
https://confluence.atlassian.com/bitbucket/work-with-pull-requests-223220593.html

Nope, not there, you made the pull request against your own fork. You need to make the pull request against the main repository. Go here: https://bitbucket.org/hudson/magic-lantern/pull-requests/ and then click "Create Pull Request"

urgently incorporated

Your best shot at that is to least submit the pull request yourself. The ML tutorial is not the only tutorial in the world that explains how to make a pull request.

In C, division of two integers results in an integer (always rounded down to the nearest integer).
7 / 4 => 1

In Lua, unless you use "//" (double slash), integer division promotes to floating point.
7 / 4 => 1.75

Throw in some more operations to compound the difference and you can get wildly different values:
For the computation 5 / 3 - 1 / 4 * 1000:
C => 1
Lua => -248.333

It looks to me like there are some issues with the ML calculation, and I'm guessing the main source of the difference is the line:

Code Select Expand

const uint64_t  imag = (fd-fl)/fl;

The roundoff error that is created by this line gets compounded in the following line. Whenever doing integer division in C, always save the division operation for last as to avoid propagating and compounding roundoff error. Changing the last line to this algebraic equivalent should improve things a little:

Code Select Expand

lens_info.dof_far = (fd*fl*fl*10000)/(10000*fl*fl - (fd-fl)*lens_info.aperture*coc)

1. You might not always want to pop a getfield:
  - if it's going to be the value returned from a function
  - if some other lua API call is going to consume/pop it
  - if it's going to be an argument to a function call or the function being called (which will result in it and the other arguments getting popped)

Keeping track of what's going on the the stack is probably the single hardest part of writing lua API stuff in C, I don't really know of a way to automatically verify stack operations, because what happens to the stack simply depends on what it is trying to be accomplished. You'll notice in the lua API docs in gray on the right side are three values for each function, these values describe what that particular function does to the stack.

Sometimes you have to write something so complicated that the only way to do it is to make code comments of what is going on with the stack. Something relatively simple in Lua is very challenging to write the equivalent C. For example to simple do a nested function call like: foo(1, bar(2,t[3]), 4) in C you would need to:
push foo on the stack
push 1 on the stack
push bar on the stack
push 2 on the stack
push t on the stack
push 3 on the stack
getfield
call
push 4 on the stack
call

2. They do a lot more than those built in functions, for example providing a way to specify the default value for optional parameters, and also inserting the name of the parameter into the error message (that way the user maybe has some idea of what they did wrong).

3. Probably a good idea to make those tables readonly.

4. to be continued...

Code Select Expand

if display.idle then

Not without aliasing, dual ISO introduces aliasing in the areas where the two ISOs don't overlap (highlights and shadows).

From the Lua docs:

Get the current Canon GUI state of the camera (PLAY, QR etc; see gui-common.h)

gui_common.h (starts at line 180)

Code Select Expand

FONT.LARGE:width("test")

See also editor.lua

Probably the memory used for the choices is getting "garbage collected" by lua and then reused for something else.

from the Lua docs:

Because Lua has garbage collection, there is no guarantee that the pointer returned by lua_tolstring will be valid after the corresponding Lua value is removed from the stack.

The fix would be to allocate the memory ourselves in C for the menu entries' choices rather than just using the pointer returned from lua_tostring directly:

Code Select Expand


menu_entry->choices[choice_index] = lua_tostring(L, -1);

would change to something like (but with proper checks and everything):

Code Select Expand


menu_entry->choices[choice_index] = malloc(sizeof(char) * (strlen(lua_tostring(L, -1)) + 1));
strcpy(menu_entry->choices[choice_index], lua_tostring(L, -1));


And then appropriate code to free those buffers should the menu entry ever be removed and they are no longer needed.

As a workaround you can probably fix it in Lua by assigning anything to be use as 'choices' to global variables (so they don't get garbage collected).

Why are you so bent on getting this app to run on mac when there are a plethora of alternatives that already run on mac and actually support more of the very latest features (like lossless compression)?

If you really want to port this app to Mac, I would recommend first decoupling the MLV processing code from the UI specific stuff and into its own assembly. Such an assembly should have minimal dependencies and therefore would run directly under mono or .net core. Then you can re-write the UI to be able to support only Silverlight stuff, while you're at it I would highly recommend adopting the MVVM design pattern (which is really how WPF was intended to be used). Finally you can eliminate the WPF specific code, and re-implement all of that functionality using only stuff available in Silverlight.

Please upload a sample file. If you dig round mlv_dump code it says following.
Error related to int ret.  Frame size?

The data is corrupted. See lj92 header:

Code Select Expand

LJ92_ERROR_CORRUPT = -1

will that work?

Sure, if you want to port this app from WPF to Silverlight (probably not trivial).

This app uses WPF, you won't be able to use it on a Mac.

Merged @bouncyball's lj92 stuff, and updated the Mac build.

Canon's printf() implementation is not standards compliant and does not support %f (amongst various other things). I suppose you are using the main nightly builds, and I suppose they are still using Canon's printf (it was fixed to use our own standards compliant libc implementation, but that was so long ago, I don't remember if it has made it into unified).

There was a poorly written article on a popular blog that totally missunderstood and missed the point of a recent reverse engineering discovery. The fact is that it has been possible for us to write DNGs even before ML was called ML (there is DNG writing code from CHDK, the precursor to ML). There is however no plan or even good reason to replace regular CR2 stills with DNG, rather we use DNGs for whenever ML needs to save some custom image data it has manually captured, such a silent pictures.

The discovery itself simply made it possible to write losslesly compressed DNGs using Canon's own hardware compression (read: DNGs from ML will save faster and take up less space). This worked because Canon happened to use the same algorithm for CR2 compression as the one specified by the DNG specification ("lossless JPEG" it the name of it, though it has nothing to with the normal JPEG algorithm, it's named that simply because the spec comes from the same standards body).

I also believe you have confused cr2hdr with raw2dng (raw2dng is only for converting raw video from an old, no longer used format to DNG files). The cr2hdr algorithm is rather complex and even on fast, modern desktop CPUs make take 30 seconds or more to convert a single image. Running this algorithm on the camera's CPU (which BTW, don't even have hardware floating point), I imagine would take an amount of time potentially measured in hours for a single image. Regardless, there's no justification for the development effort it would take to port it. ML is not a replacement for post processing tools, and in general we never waste development effort on things that are easily accomplished in post.

That's exactly what HDR video is supposed to do.

April 1st, 2018

By "digic processor" I assume you are talking about the main general purpose ARM CPU core (the CPU that ML code runs on)? If so then, yes, the raw image data from the sensor is copied directly to and from main memory and other hardware modules using specialized hardware (EDMAC).

That might be the Canon grid. Turn it off in the Canon menu.