Menu

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.

Show posts Menu

Messages - aprofiti

#76
Quote from: dfort on February 18, 2019, 09:18:20 PM
What needs to happen on the 7D and other Digic 4 cameras is to find a few stubs like aprofiti did on the 50D. That's a first step. I tried but couldn't find one of them, can't remember which one at the moment.
Quote from: a1ex on September 21, 2018, 03:21:12 PM
the correct stubs should start with 0xFF9 instead of 0xFF1. That means, you should patch some address that Canon code is going to execute, not a mirrored copy.

Make sure the hook is actually executing (add some printf, for example).

@dfort Can you try these ones?

NSTUB(0xFF27E674, StartImagePass_x1_SetEDmac)
NSTUB(0xFF27F444, StartImagePass_x5_SetEDmac) 


First one It's a bit different but function called looks likely the same.
Looking into the disassembly I can't find a mirror for both stubs in the 0xFF9 range or similar like on 50D
#77
You can use "lens.serial" in a lua script if using "Non-CPU lens info" from the experimental builds.

Notice that the serial number returned is an integer and may be different from the one showed in the Lens Info menu (exiftool version).

Edit: Tried it and return "0" because ML lens_info.serial field is not updated automatically with my lens (also show "(none)" in Lens Info menu).
I imagine that with a Canon's lens it should be retrieved correctly from ML.
#78
Quote from: zLOST on February 08, 2019, 01:21:41 PM
Small issue is, that hellios had a chipped adapter, so the camera used the provided aperture of F1.4..
Are you referring to the embedded exif data of the image or the generated .xmp sidecar?

I'm sorry, regarding embedded exif we still need to figure out how to inject in the image processing pipeline as a1ex said..

If you are referring to the .xmp didn't noticed this issue with my local build, it should take the data in the ML lens_info struct

Quote from: zLOST on February 06, 2019, 09:58:37 AM
The crashes of experimental manual_lens branch were caused by one of recent commits, so for my testing i've used build from Alessandro - https://bitbucket.org/aprofiti/magic-lantern/downloads/
Currently I'm working on:
- Refactor config lib to make code more readable (recursiveCopy is a completely mess... not proud of It...)
- add more attribute to lenses looking from zLOST ..xmp
- add support for multiple name for the same attribute to .xmp lib (ex. Lens name using aux: exif: and exifEX:)

Still thinking about the possibility to have user's lenses in a separate config than embedded in the script.
This will be useful in case of an update, as user doesn't need to insert lenses each time

Attribute added locally:
-Fmin,Fmax (from zLOST)
-lens specification (from zLOST)

Would like to calculate aperture min and max from FNumber automatically instead of adding 2 more attribute to lenses.
Will look into it.

@zLOST can you show your .xmp.lua?
I'm having problems in adding support for multiple name for the same attribute. It doesn't print some of the other ones

Also can't figure out why lua isn't saving my data with the modified recusiveCopy I'm working on.. they are table, so passing is by reference...

Also noticed a strange behaviour with Lightroom, it looks like doesn't read the .xmp when opening the image... so no correction applied.

Does this also appen to you guys?

I will update my remote repo and the PR after solving those problems
#79
Quote from: a1ex on January 25, 2019, 07:10:15 PM
If the question is about how to modify EXIF data in a CR2, then it all happens on the main CPU. Where exactly... I'm afraid I don't know.

It doesn't work in QEMU yet, but that's "just" a matter of implementing the LJ92/JPG encoders and other image processing paths used while creating the CR2. Once that works, you will be able to experiment with modified EXIF info..
Good to know! Thank you a1ex, maybe one day we will be able to experiment with it :)

Quote from: zLOST on January 25, 2019, 10:46:59 PM
You mean this one?




Prob is, that each adapter may behave in a different way depending on presence and version of the chip. And we'd have to override this behavior by giving the camera a list of available apertures to choose from. Which may technically be the same as setting the lens name and focal length.
Yes, exactly. It' the same problem as with lens data, overridding from cpu memory/code will possibly do the trick.

A temporary solution would be to use flexinfo to print the aperture value on top of Canon's text. Not very clean but doable if needed....
#80
Quote from: zLOST on January 24, 2019, 02:56:54 PM
My aim is/was to "fake" as much data as possible and if there is a way we could make the camera believe, that these values came from the lenses directly instead, so they get saved with another exif data in the image header, then go for it. That would make them instantly available for all image editors at once..
According to this old post, writing to Canon data structure is considered dangerous .

Maybe @a1ex discovered some other possible methods to inject exif data to .cr2?
I imagine MPU is most responsible for this and it usually doesn't "collaborate"; so not much expectation from this at the moment.

By the way, I would like to have aperture overridden in Photo menu... it would be useful to remember and check what value selected from the script.

Quote from: zLOST on January 19, 2019, 01:41:46 PM
I've just found what was wrong when setting params for my Samyang - lens.serial is expected to be integer, but this lens has string.
Regarding managing serial number as string... I made some tests and got a half working version:

/* lua/lua_lens.c */

#include <bmp.h>
#include <inttypes.h>

// Retrive value
static int luaCB_lens_index(lua_State * L)
{

...

    /// Get the serial number of the lens
    // @tfield string serial
    //else if(!strcmp(key, "serial")) lua_pushstring(L, lens_info.lens_serial);
    else if(!strcmp(key, "serial"))
    {
      char buf[20];

      //  snprintf(buf, 17, "%#" PRIx64, (uint64_t)lens_info.lens_serial);
      snprintf(buf, 17, "%llu", lens_info.lens_serial);
      //  snprintf(buf, 17, "%#" PRIu64 , lens_info.lens_serial);

      bmp_printf( FONT(FONT_LARGE,COLOR_RED,COLOR_BG), 30, 250,"lens.serial 2: %llu",lens_info.lens_serial);
      bmp_printf( FONT(FONT_LARGE,COLOR_RED,COLOR_BG), 30, 300,"buff: %s",buf);

      lua_pushstring(L, buf);
    }

....

// Assign new value
static int luaCB_lens_newindex(lua_State * L)
{
  else if(!strcmp(key, "serial"))
    {
        //LUA_PARAM_INT(value, 3);
        //lens_info.lens_serial = value;

        LUA_PARAM_STRING(value, 3);
        lens_info.lens_serial = strtoul(value, NULL, 0);

        bmp_printf( FONT(FONT_LARGE,COLOR_RED,COLOR_BG), 30, 100,"value: %s",value);
        bmp_printf( FONT(FONT_LARGE,COLOR_RED,COLOR_BG), 30, 150,"lens.serial 1: %d", lens_info.lens_serial );
    }

This save correctly the number as unsigned long integer in ML lens_info data structs (can be seen in Lens Info debut menu), but then when I try to get it as a string from the lua script, it give me nothing usefull... like a empty string with the format specifier as prefix.


    { make = "Samyang", name = "85mm f/1.4 AS IF UMC", focal_length = 85, manual_aperture = 1.4}
      --  serial = "A217D0264" }

Also in your case it is a alphanumerics value and add support to this isn't straightforward... I can change "strtoul" arguments to parse number in hexadecimal base (0-9 , A-F) and try to adapt script, but would not cove all possible case... as example old canon lenses use all of the letter from alphabet and other manufactures may do the same.

Given that, it may not be worth to manage serial in lua as a string; it's converted from number to string when saving .xmp, but actually it works only for decimal numbers.

@a1ex @dmilligan Any suggestion on what to do?
#81
Quote from: reddeercity on January 23, 2019, 07:20:17 AM
Boy this ROM hack from waza57 for height is really hard to disable , more I think I'm close the more error's I get  & can't compile  :(
On the Bright side  :D My preset code structure works , after I found where to add the code.
I was wondering if isn't better to make Digic 4 camera build on top of official crop_rec_4k branch? This is something should be done before or after.

At the moment I can remember @dfort for lossless compression here and a new one here , which is a fork of crop_rec_4k if I'm not wrong; then there is waza57 repository, which I'm not of what is capable of doing and I imagine that @reddeercity is working on top of that because is the one which compile, is it right?

Can someone make me an overview of the difference on those repository and what is needed to make d4 compile on top of crop_rec_4k?
#82
Quote from: zLOST on January 21, 2019, 10:45:30 PM
Thanks for the non-crashing build, Alessandro. It's perfect!
Happy to hear this!
Please report any strange behaviour if you plan to use it in the next days.

Quote from: zLOST on January 21, 2019, 10:45:30 PM
To ease my struggle with finding the right field to use for lens name, which will be accepted by darktable, i've modded xmp.lua, so the properties name can be a string and table/array as well to generate three lines with a single call to add_property()
Nice idea! May be useful to make code a little bit shorter if we add the new tags. Will look into it :)

Quote from: zLOST on January 21, 2019, 10:45:30 PM
At the moment i'm using this xmp output (the exifEX:LensModel is the right field for DarkTable...)
Would like to know if inserting the same information but with different namespace can make any editing software angry or not, as what I understood from your post, each software looks at different tags in the xmp.
Is possible to make a short recap on which tags each software use?

We could fill .xmp using different namespace (aux, exif, exifEx ) for the same information (name, aperture...) If there aren't any problems.

Quote from: zLOST on January 21, 2019, 10:45:30 PM

xmp.lens_specification  = { name = "exif:LensSpecification",    format = "%s" } -- Exif.Photo.LensSpecification  Rational  This tag notes minimum focal length, maximum focal length, minimum F number in the minimum focal length, and minimum F number in the maximum focal length, which are specification information for the lens that was used in photography. When the minimum F number is unknown, the notation is 0/0


xmp:add_property(xmp.lens_specification,        function()
                        local focal_min = (lens.focal_min or lens.focal_length)
                        local focal_max = (lens.focal_max or lens.focal_length)
                        local FminL     = (lens.FminL or lens.manual_aperture)
                        local FmaxL     = (lens.FmaxL or lens.manual_aperture)
                        return string.format("%s/1 %s/1 %s/1 %s/1", tostring(focal_min), tostring(focal_max), tostring(FminL), tostring(FmaxL))
                end)

Can't find this in exiftool's tag list. It may be this instead:

0xa432 LensInfo rational64u[4] ExifIFD (4 rational values giving focal and aperture ranges, called LensSpecification by the EXIF spec.)

Found other example in other forum which use "exifEx:"... Which one is to use?

Quote from: zLOST on January 21, 2019, 10:45:30 PM
The unfortunate fact is, that the min/max aperture values and lens_specs don't work the way i want them to. But technically those are not important at all for normal people..
What do you need exactly?
#83
Quote from: zLOST on January 21, 2019, 10:22:42 AM
Btw: is there any chance to get rid of those memory-related crashes after each shot?
Quote from: a1ex on January 18, 2019, 12:00:10 PM
Maybe backing out b0a2f95 (i.e. re-applying 065ceae) could help.
You can find the build I have in local at this download page (for 5D3,5D2,7D,6D,50D)
Should also avoid camera freezes while recording raw videos.

I was trying to make lens serial number as a string in lua, but I get a crash log with the modified lua_lens.c:

/***
Lens functions

@author Magic Lantern Team
@copyright 2014
@license GPL
@module lens
*/

#include <dryos.h>
#include <string.h>
#include <lens.h>
#include <focus.h>
#include <module.h>
#include "lua_common.h"

static int luaCB_lens_index(lua_State * L)
{
    LUA_PARAM_STRING_OPTIONAL(key, 2, "");
    /// Get/Set the name of the lens (reported by the lens)
    // @tfield string name
    if(!strcmp(key, "name")) lua_pushstring(L, lens_info.name);
    /// Get the lens id
    // @tfield int id readonly
    else if(!strcmp(key, "id")) lua_pushinteger(L, lens_info.lens_id);
    /// Get the serial number of the lens
    // @tfield string serial
    else if(!strcmp(key, "serial")) lua_pushstring(L, lens_info.lens_serial);
    /// Get/Set the focal length of the lens (in mm)
    // @tfield int focal_length
    else if(!strcmp(key, "focal_length")) lua_pushinteger(L, lens_info.focal_len);
    /// Get/Set the minimum focal length of the lens (in mm)
    // @tfield int focal_min
    else if(!strcmp(key, "focal_min")) lua_pushinteger(L, lens_info.lens_focal_min);
    /// Get/Set the maximum focal length of the lens (in mm)
    // @tfield int focal_max
    else if(!strcmp(key, "focal_max")) lua_pushinteger(L, lens_info.lens_focal_max);
    /// Get the current focus distance (in mm). Only updated in LiveView.
    // @tfield int focus_distance readonly
    else if(!strcmp(key, "focus_distance")) lua_pushinteger(L, lens_info.focus_dist * 10);
    /// Get the raw relative focus motor position, in steps.
    /// This counter is 0 at camera startup, its range depend on the lens,
    /// and is updated only when the focus motor moves. It will lose track
    /// of the lens position during manual focus, unless you use a focus-by-wire lens.
    /// Details: [www.magiclantern.fm/forum/index.php?topic=4997](http://www.magiclantern.fm/forum/index.php?topic=4997).
    // @tfield int focus_pos readonly
    else if(!strcmp(key, "focus_pos")) lua_pushinteger(L, lens_info.focus_pos);
    /// Get the hyperfocal distance of the lens (in mm). Only updated in LiveView.
    ///
    /// Computed from focal length, focus distance and aperture, see Focus -> DOF Settings menu for options.
    // @tfield int hyperfocal readonly
    else if(!strcmp(key, "hyperfocal")) lua_pushinteger(L, lens_info.hyperfocal);
    /// Get the distance to the DOF near (in mm). Only updated in LiveView.
    ///
    /// Computed from focal length, focus distance and aperture, see Focus -> DOF Settings menu for options.
    // @tfield int dof_near readonly
    else if(!strcmp(key, "dof_near")) lua_pushinteger(L, lens_info.dof_near);
    /// Get the distance to the DOF far (in mm). Only updated in LiveView.
    ///
    /// Computed from focal length, focus distance and aperture, see Focus -> DOF Settings menu for options.
    // @tfield int dof_far readonly
    else if(!strcmp(key, "dof_far")) lua_pushinteger(L, lens_info.dof_far);
    /// Get whether or not auto focus is enabled.
    // @tfield bool af readonly
    else if(!strcmp(key, "af")) lua_pushboolean(L, !is_manual_focus());
    /// Get the current auto focus mode (may be model-specific, see PROP\_AF\_MODE in property.h).
    // @tfield int af_mode readonly
    else if(!strcmp(key, "af_mode")) lua_pushinteger(L, af_mode);
    /// Get whether the lens is currently autofocusing.
    ///
    /// This does not include manual lens movements from lens.focus or ML follow focus -
    /// only movements from Canon autofocus triggered by half-shutter / AF-ON / * button.
    /// It is updated several ms (sometimes hundreds of ms) after the half-shutter event.
    ///
    /// On cameras with continuous autofocus, the return value is unknown - please report.
    ///
    /// Known not to work on EOS M.
    // @tfield bool autofocusing readonly
    else if(!strcmp(key, "autofocusing")) lua_pushboolean(L, lv_focus_status == 3);
    /// Use to manually set the lens aperture value for non-chipped lenses (for metadata purposes)
    // @tfield bool manual_aperture
    else if(!strcmp(key, "manual_aperture")) lua_pushnumber(L, lens_info.aperture / 10.0);
    /// Use to manually set the len's minumum aperture value for non-chipped lenses (for metadata purposes)
    // @tfield bool aperture_min
    else if(!strcmp(key, "aperture_min")) lua_pushnumber(L, RAW2VALUE(aperture, lens_info.raw_aperture_min) / 10.0);
    /// Use to manually set the len's maximum aperture value for non-chipped lenses (for metadata purposes)
    // @tfield bool aperture_max
    else if(!strcmp(key, "aperture_max")) lua_pushnumber(L, RAW2VALUE(aperture, lens_info.raw_aperture_max) / 10.0);
    /// Get if the lens chipped
    // @tfield bool is_chipped readonly
    else if(!strcmp(key, "is_chipped")) lua_pushboolean(L, lens_info.lens_exists);
    else lua_rawget(L, 1);
    return 1;
}

static int luaCB_lens_newindex(lua_State * L)
{
    LUA_PARAM_STRING_OPTIONAL(key, 2, "");
    if(!strcmp(key, "name"))
    {
        LUA_PARAM_STRING(value, 3);
        strncpy(lens_info.name, value, sizeof(lens_info.name)-1);
    }
    else if(!strcmp(key, "exists"))
    {
        LUA_PARAM_BOOL(value, 3);
        lens_info.lens_exists = value;
    }
    else if(!strcmp(key, "focal_length"))
    {
        LUA_PARAM_INT(value, 3);
        lens_info.focal_len = value;
    }
    else if(!strcmp(key, "focal_min"))
    {
        LUA_PARAM_INT(value, 3);
        lens_info.lens_focal_min = value;
    }
    else if(!strcmp(key, "focal_max"))
    {
        LUA_PARAM_INT(value, 3);
        lens_info.lens_focal_max = value;
    }
    else if(!strcmp(key, "manual_aperture"))
    {
        LUA_PARAM_NUMBER(value, 3);
        lens_info.aperture = (int)(value * 10);
        lens_info.raw_aperture = VALUE2RAW(aperture, lens_info.aperture);
    }
    else if(!strcmp(key, "aperture_min"))
    {
        LUA_PARAM_NUMBER(value, 3);
        int tmp = (int)(value * 10);
        lens_info.raw_aperture_min = VALUE2RAW(aperture, tmp);
    }
    else if(!strcmp(key, "aperture_max"))
    {
        LUA_PARAM_NUMBER(value, 3);
        int tmp = (int)(value * 10);
        lens_info.raw_aperture_max = VALUE2RAW(aperture, tmp);
    }
    else if(!strcmp(key, "serial"))
    {
        LUA_PARAM_STRING(value, 3);
        strncpy((uint64_t)lens_info.lens_serial, value, sizeof(lens_info.lens_serial));
    }
    else if(!strcmp(key, "focus_distance") || !strcmp(key, "hyperfocal") || !strcmp(key, "dof_near") || !strcmp(key, "dof_far") || !strcmp(key, "af") || !strcmp(key, "is_chipped"))
    {
        return luaL_error(L, "'%s' is readonly!", key);
    }
    else
    {
        lua_rawset(L, 1);
    }
    return 0;
}

/***
Moves the focus motor a specified number of steps.

Only works in LiveView.
@tparam int num_steps How many steps to move the focus motor (signed).
@tparam[opt=2] int step_size Allowed values: 1, 2 or 3.

Step 1 may give finer movements, but may get stuck or may be very slow on some lenses.
@tparam[opt=true] bool wait Wait until each focus command finishes, before queueing others.

wait=false may give smoother movements, but may no longer return accurate status for each command,
and is known to **crash** on some cameras. The exact behavior may be camera- or lens-dependent.

__Do not disable it without a good reason!__

@tparam[opt] int delay Delay between focus commands (ms)

With wait=true, the delay is after each focus command is executed (as reported by Canon firmware).

With wait=false, the delay is after each focus command is started (without waiting for it to finish).

(_default_ 0 if wait=true, 30ms if wait=false)


@treturn bool whether the operation was successful or not.
@function focus
*/
static int luaCB_lens_focus(lua_State * L)
{
    LUA_PARAM_INT(num_steps, 1);
    LUA_PARAM_INT_OPTIONAL(step_size, 2, 2);
    LUA_PARAM_BOOL_OPTIONAL(wait, 3, true);
    LUA_PARAM_INT_OPTIONAL(delay, 4, wait ? 0 : 30);

    if (!lv) return luaL_error(L, "lens.focus() only works in LiveView.");
    if (is_manual_focus()) return luaL_error(L, "lens.focus() requires autofocus enabled.");
    if (is_continuous_af()) return luaL_error(L, "lens.focus() requires %s AF disabled.", is_movie_mode() ? "movie servo" : "continuous");

    lua_pushboolean(L, lens_focus(num_steps, step_size, wait, delay));

    return 1;
}

static int wait_focus_status(int timeout, int value1, int value2)
{
    int t0 = get_ms_clock();

    while (get_ms_clock() - t0 < timeout)
    {
        msleep(10);

        if (lv_focus_status == value1 || lv_focus_status == value2)
        {
            return 1;
        }
    }
    return 0;
}

/***
Performs autofocus, similar to half-shutter press.

Works in both LiveView and in plain photo mode.
@treturn bool whether the operation was successful or not.
@function autofocus
*/
static int luaCB_lens_autofocus(lua_State * L)
{
    int focus_command_sent = 0;

    if (is_manual_focus())
    {
        goto error;
    }

    /* these models won't AF with half-shutter in LiveView */
    int back_btn_af_lv = lv && (
        is_camera("5D2", "*") ||
        is_camera("50D", "*") ||
        is_camera("500D", "*")
    );

    if (back_btn_af_lv)
    {
        /* FIXME: this method fails on 60D, why? */
        int af_request = 1;
        prop_request_change(PROP_REMOTE_AFSTART_BUTTON, &af_request, 4);
    }
    else
    {
        lens_setup_af(AF_ENABLE);
        module_send_keypress(MODULE_KEY_PRESS_HALFSHUTTER);
    }

    focus_command_sent = 1;

    if (!lv)
    {
        for (int i = 0; i < 20; i++)
        {
            msleep(100);

            /* FIXME: this may fail on recent models where trap focus is not working */
            if (get_focus_confirmation())
            {
                goto success;
            }
        }

        goto error;
    }

    /* 3 = focusing, 1 = idle (most models), 2 = idle (100D) */
    if (wait_focus_status(1000, 3, 3))
    {
        if (wait_focus_status(5000, 1, 2))
        {
            goto success;
        }
        else
        {
            /* timeout */
            printf("[%s] focus status: %d (expected 1 or 2)\n", lua_get_script_filename(L), lv_focus_status);
            goto error;
        }
    }
    printf("[%s] focus status: %d (expected 3)\n", lua_get_script_filename(L), lv_focus_status);

error:
    lua_pushboolean(L, false);
    goto cleanup;

success:
    lua_pushboolean(L, true);
    goto cleanup;

cleanup:
    if (focus_command_sent)
    {
        if (back_btn_af_lv)
        {
            int af_request = 0;
            prop_request_change(PROP_REMOTE_AFSTART_BUTTON, &af_request, 4);
        }
        else
        {
            module_send_keypress(MODULE_KEY_UNPRESS_HALFSHUTTER);
            lens_cleanup_af();
        }
    }
    return 1;
}

static const char * lua_lens_fields[] =
{
    "name",
    "focal_length",
    "focus_distance",
    "hyperfocal",
    "dof_near",
    "dof_far",
    "af",
    "af_mode",
    NULL
};

static const luaL_Reg lenslib[] =
{
    { "focus",      luaCB_lens_focus },
    { "autofocus",  luaCB_lens_autofocus },
    { NULL, NULL }
};

LUA_LIB(lens)

Lens.lua

lenses =
{
...

    { name = "My Zoom Lens", focal_length = 105, manual_aperture = 4, focal_min = 70, focal_max = 200, serial = "123456789" },

...
}
function reset_lens_values()
...

  lens.serial = ""

...
end


The log I get:

[43909204] lua_script_task: NULL PTR (34333231,e1a00000)
pc=     180 lr= a21fe80 stack=1ae5b0+0x10000
entry=bc5ff0(984464)
e1a00000 38373635 e59ff014 e59ff014
e59ff014 e1a00000 e59ff010 e59ff010

Magic Lantern version : Nightly.2019Jan21.50D109
Mercurial changeset   : b1818aa3ae43+ (manual_lens_info) tip
Built on 2019-01-21 12:37:46 UTC by alex@PCAlessandro.
Free Memory  : 227K + 2617K


@a1ex how can I interpret these crash logs to get more infos?
#84
Quote from: zLOST on January 19, 2019, 12:52:38 AM
So, i wrote a simple dumper script and tested all the adapters i found with it:


===============================================================================
ML/SCRIPTS/ADAPTE~1.LUA - 2019-1-18 23:51:36 ----> no chip at all (Samyang 85/1.4)
===============================================================================

ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:51:37 - lens.name=
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:51:37 - lens.focal_length()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:51:37 - lens.focus_distance()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:51:37 - lens.hyperfocal()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:51:38 - lens.dof_near()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:51:38 - lens.dof_far()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:51:38 - lens.af()=false
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:51:38 - lens.af_mode()=3
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:51:38 - lens.autofocus()=false

===============================================================================
ML/SCRIPTS/ADAPTE~1.LUA - 2019-1-18 23:52:55 ----> with AF chip (M42 -> EOS)
===============================================================================

ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:52:55 - lens.name=1-65535mm
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:52:55 - lens.focal_length()=50
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:52:55 - lens.focus_distance()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:52:55 - lens.hyperfocal()=61676
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:52:55 - lens.dof_near()=561148697
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:52:55 - lens.dof_far()=1000000
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:52:55 - lens.af()=false
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:52:55 - lens.af_mode()=3
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:52:56 - lens.autofocus()=false

===============================================================================
ML/SCRIPTS/ADAPTE~1.LUA - 2019-1-18 23:53:16 ----> with AF chip (M42 -> EOS)
===============================================================================

ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:16 - lens.name=1-65535mm
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:16 - lens.focal_length()=50
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:16 - lens.focus_distance()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:16 - lens.hyperfocal()=61676
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:16 - lens.dof_near()=561148697
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:16 - lens.dof_far()=1000000
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:16 - lens.af()=false
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:16 - lens.af_mode()=3
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:16 - lens.autofocus()=false

===============================================================================
ML/SCRIPTS/ADAPTE~1.LUA - 2019-1-18 23:53:42 ----> Sigma 50/2.8 DG Macro (AF turned on)
===============================================================================

ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:42 - lens.name=EF50mm f/2.5 Compact Macro
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:42 - lens.focal_length()=50
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:42 - lens.focus_distance()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:42 - lens.hyperfocal()=30888
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:42 - lens.dof_near()=-340372800
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:42 - lens.dof_far()=1000000
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:42 - lens.af()=true
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:42 - lens.af_mode()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:53:45 - lens.autofocus()=false

===============================================================================
ML/SCRIPTS/ADAPTE~1.LUA - 2019-1-18 23:54:29 ----> with AF chip (praktica B -> EOS)
===============================================================================

ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:29 - lens.name=1-65535mm
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:29 - lens.focal_length()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:29 - lens.focus_distance()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:29 - lens.hyperfocal()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:29 - lens.dof_near()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:29 - lens.dof_far()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:29 - lens.af()=false
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:29 - lens.af_mode()=3
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:29 - lens.autofocus()=false

===============================================================================
ML/SCRIPTS/ADAPTE~1.LUA - 2019-1-18 23:54:53 ----> with AF chip (another M42 -> EOS)
===============================================================================

ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:53 - lens.name=1-65535mm
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:53 - lens.focal_length()=50
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:54 - lens.focus_distance()=0
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:54 - lens.hyperfocal()=61676
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:54 - lens.dof_near()=561148697
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:54 - lens.dof_far()=1000000
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:54 - lens.af()=false
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:54 - lens.af_mode()=3
ML/SCRIPTS/ADAPTE~1.LUA: 2019-01-18 23:54:54 - lens.autofocus()=false

Thank You for testing more adapters. Here is one of mine (second one has a broken contact so no chip doesn't work anymore, anyway basically info):

===============================================================================
ML/SCRIPTS/LENSDUMP.LUA - 2019-1-19 20:44:31  => PK -> EOS  and similiar to C/Y -> EOS
===============================================================================

lens.name=1-65535mm
lens.focal_length()=50
lens.focus_distance()=0
lens.hyperfocal()=94084
lens.dof_near()=-1735480800
lens.dof_far()=1000000lens.af()=false
lens.af_mode()=771
lens.autofocus()=false

It's the same with mine, so the method used until now is ok :)

Quote from: zLOST on January 19, 2019, 01:41:46 PM
I've just found what was wrong when setting params for my Samyang - lens.serial is expected to be integer, but this lens has string..

As a workaround for the serial number i've renamed "serial" in lenses{} to serialN, which is handled as string() by default, so i'm able to access it in xmp() and save. I suppose, that the serial==number() limitation is hardcoded somewhere in ML sources, right?
That's something @g3gg0 may review for us, as he worked here to adapt serial number conversion.
Don't know what is best to do here. Better to to wait for him to read this post.

Quote from: zLOST on January 19, 2019, 01:41:46 PM
I'm finally able to write the xmp file. Unfortunately only to the root of SD card - for some reason it still crashes when i try to use the dryos path, even when it looks fine.
This is how I modified xml.lua to solve the error due to the refactor:

function xmp.get_sidecar_filename()
    return dryos.shooting_card.dcim_dir.path ..  dryos.image_prefix .. string.format("%04d", dryos.shooting_card.file_number) .. ".XMP"
end

Quote from: zLOST on January 19, 2019, 01:41:46 PM
I'm finally able to write the xmp file. Unfortunately only to the root of SD card - for some reason it still crashes when i try to use the dryos path, even when it looks fine.
Could someone with LR/PS/anything else verify that this format is acceptable by software other than darktable&gimp? ;)
Adobe Bridge/Photoshop will show correct info for lens make,model and focal length
Serial number as 630312148, max aperture value as f/1.0

Quote from: zLOST on January 19, 2019, 01:41:46 PM
I've added four more params to lenses{}:
1] max_aperture and min_aperture, which are used to trim down the list of available Fnumbers plus they'll end up in the <exif:M[in|ax]ApertureValue>F22</exif:M[in|ax]ApertureValue> elements

2] FminL, FmaxL - apertures on wide/long ends of zoom lenses if they differ. Used in LensSpecification field.

Btw: i've checked exif data of my pics and the Exif.Photo.LensModel is really just a model without the lens brand (pics taken with trioplan were labeled by my old bash script)
Thinked before about that, but then added the "f_values" attribute to lenses, which enable the possibility to list only correct aperture for the selected lens, so I decided to don't introduce a redundant attributes.

Was thinking about to retrieve first and last values from the Manual Lens menu Aperture choice (which is updated from f_values if available otherwise use Fnumbers predefined list), to use as aperture_min and aperture_max.

I haven't exactly understood what FminL, FmaxL are for.

You remembered me to update xmp file to have all the values stored in ELNS block. So currently i have:

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.6-c011 79.156380, 2014/05/21-23:38:37        ">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:exif="http://ns.adobe.com/exif/1.0/"
    xmlns:aux="http://ns.adobe.com/exif/1.0/aux/"
    exif:ExifVersion="0230"
    exif:FNumber="4/10"
    exif:MinApertureValue="22/10"
    aux:Lens="My Lens"
    xmp:Label="test"
    exif:FocalLength="100/1"
    aux:SerialNumber="0"
    exif:MaxApertureValue="1.4/10">
  </rdf:Description>
</rdf:RDF>
</x:xmpmeta>

Mainly missing Focal Length range which is already handled by the lens.lua script, so I have only to add property to xmp

I'm trying to implement an idea to the ui.lua, which could allow to read all the lens name even if too long.
Not completely sure about splitting lens name into "make" and "model".

@a1ex When I try to backing out b0a2f95 using Sourcetree, it end up in duplicating the branch... so tried to do it manually and verified "Small-malloc test" and raw recording (this is not working good in last build due to the missing commit; camera freezes) with are working good (not sure about the counter next to the coloured camera icon while recording, it print some garbage to me instead of a recording timer).

I have in local all the changes. Maybe I can try upload a build in next days if I have time to finish experimenting with it
#85
Quote from: zLOST on January 18, 2019, 02:26:20 PM
My point of splitting lens name to brand+type was to keep the lens.name shorter than 32 chars. We can always concatenate these two fields in UI and when exporting the xmp, where it should not matter and should be used by LR/DT/anything to detect the used lens.
As used to work on code related to ELNS block, I initially believed you were referring to the actual file size saved on card... then understood after posting that you were talking abound lens name length showed in UI.

So yes it could be done. Slightly better could be to check if a lens name is to big to be showed in lens selection menu and truncate just the maker name, instead just print the whole name (make + model).

Noticed you modified the XMP lib's tag related to selected lens from "aux:" to "exif:".
Made some research and didn't fully come to a conclusion on which is better to use, as Canon stick with old tag system and doesn't come to troubles with tradition editing software.

Also noticed that "aux:Lens" just put the focal length range with my lens....
What are the advantage if we replace with the "exif:lensMake"/"exifEX:lensMake" and "exif:LensModel"/"exifEX:LensModel" attributes?

Quote from: zLOST on January 18, 2019, 02:26:20 PM
Plus i'd like to add few more exif fields to the xmp output (i wrote a simple bash script to "label" my pics - https://www.zlej.net/tmp/exif.txt and it would be great to see this done automatically by ML as i tend to forget what i had attached two weeks ago when shooting some pics..)
I looked at ExifTool's XMP tag list and XMP specification and found under tags used by Photoshop the string: "xmp:Label" which looks like it could be used for your purpose.

Reading an article from FastRawViewer his content doesn't looks forced to a predefined set; instead as being a simply string I tried to manual modify a .xmp file and get retrieved by Adobe Bridge as a new type of label.

Alternatively we could add a new custom tag to the xmp library (ex. under ML namespace), but should't be necessary.

To add a new xmp attribute to the script, follow these steps:
1. Add a new predefined properties to xmp.lua library (if you want the code to looks a bit cleaner, otherwise you could skip this step and adapt the second one):
"xmp.label = { name = "xmp:Label" }"

-- predefined xmp properties
xmp.lens_name = { name = "aux:Lens" }
xmp.lens_serial = { name = "aux:SerialNumber" }
xmp.focal_length = { name = "exif:FocalLength", format = "%d/1"}
xmp.aperture = { name = "exif:FNumber", format = "%d/10" }


2. Tell to the lens.lua script to save the new tag when taking a picture:
"xmp:add_property(xmp.label, function() return lenses[selector_instance.index].label end)"

-- Property to be written in .xmp file
xmp:add_property(xmp.lens_name, function() return lens.name end)
xmp:add_property(xmp.focal_length, function() return lens.focal_length end)
xmp:add_property(xmp.aperture, function() return (lens.manual_aperture * 10) end)
xmp:add_property(xmp.lens_serial, function() return lens.serial end)

Note: Here I'm retrieving value from a local variable of lens.lua script, instead of using something like "lens.label" as it is an API not available at the moment.
You need to add getter and setter functions in modules/lua/lua_lens.c to make API available to use and save value somewhere (ex. ML lens_info structure in /src/lens.h), then recompile ML.

Also I'm not sure if value get updated when switching lens by using this method and if you get an error for missing field.
If one of these happen try to add check for "label" inside the for cycle:

function update_lens()
    -- Reset lens_info structure to get correct values in Lens Info Menu and Metadata
    reset_lens_values()
    -- Update attribute from selected lens
    for k,v in pairs(lenses[selector_instance.index]) do
        -- avoid not found exception with the key "label"
        if k ~= "label" then
         lens[k] = v
        else
         -- update label value   
         xmp:add_property(xmp.label, function() return lenses[selector_instance.index].label end) -- may not be necessary
       end
    end
    -- Allow to write sidecar
    xmp:start()
    -- Update flag
    lensSelected = true
    -- Allow to write values in Lens Info Menu
    lens.exists = true
end


3. Add the attribute "label" to the corresponding lenses:

-- From your lenses Table version

lenses = -- {{{
{
    { make = "Carl Zeiss Jena DDR",     name = "Tessar 50mm f/2.8",             focal_length = 50,      manual_aperture = 2.8,  serial = "8333263",
label = "tessar50" },
    { make = "Industar",                name = "61 L/Z (MC) 50mm f/2.8",        focal_length = 50,      manual_aperture = 2.8,  serial = "8707286",
label = "industar61" },
    { make = "Meyer-Optik Gorlitz",     name = "Telemegor 180mm f/5.5",         focal_length = 180,     manual_aperture = 5.5,  serial = "1728275",
label = "telemegor180" },

....

} -- }}}


Looks like you already dive deep in the script structure, so you should not have particular problems to add the new tag
#86
Quote from: zLOST on January 18, 2019, 10:20:51 AM
Some of the recent changes in lua library had changed contents of dryos variables and the dryos.dcim_dir.path (used in get_sidecar_filename() @ xmp.lib) does not  work anymore.
Being on linux and using daktable+gimp i have to use IMG_1234.[CR2|JPG].xmp name to have it recognized and used by DT, so i've modified the get_sidecar to:

function xmp.get_sidecar_filename() -- {{{
    return dryos.shooting_card:image_path(1) .. ".xmp"
end -- }}}

This refactor is what is causing the issue. Adapting this branch to the new API should do the trick,
Was considering to fix in the PR after a1ex had a look again to the memory management backend.

Maybe try with "dryos.shooting_card:dcim_dir"

Quote from: zLOST on January 18, 2019, 10:20:51 AM
I made some changes in the XMP file format (to use the same as exiftool) and tried to save the xmp file line by line to lower the memory consumption..
Unfortunately now it crashes immediately after taking a picture (for a split of a second i can see an error with wiritng to the xmp file (which was working for me for a while, but apparently i broke something a bit later)) and all i end up with is a picture and an assert log
Quote from: a1ex on January 18, 2019, 12:00:10 PM
Right, I need to look into that. Maybe backing out b0a2f95 (i.e. re-applying 065ceae) could help.
Should be related to what a1ex said, I noticed the assert for first time in this new build, when switching lens selection; I can't remember if happened also to me under same circumstance now, but probably yes.

Quote from: zLOST on January 18, 2019, 10:20:51 AM
Btw: is there a way i could test these scripts in qemu on my own? restarting the camera, mounting the sdcard, copying scripts, unmounting sdcard, starting camera is pretty exhausting and annoying especially when all i find is yet another bug in my own code :)
I really wanted this was possible at current stage, will make much less stressful and time consuming, but we need to wait a little more :)

Quote from: zLOST on January 18, 2019, 12:26:12 PM
btw: even during those bright moments when i had the xmp file written correctly, the exif data in cr2 and jpg (when i've switched to shooting to both formats) were showing the original unaltered data.
It's minded to work like this: Write metadata to .xml sidecart file (and/or in .mlv if full-res picture or raw video) instead of playing with .cr2 as is considered to be dangerous from what I've read in old discussion in this thread.

Maybe a safe way to inject into .cr2 can be found?

Quote from: zLOST on January 18, 2019, 12:26:12 PM
I've also split the lens name to brand+model, so the lens name is shorter (MOG would eat 20 bytes off the name :) )

lenses = -- {{{
{
    { make = "Carl Zeiss Jena DDR",     name = "Tessar 50mm f/2.8",             focal_length = 50,      manual_aperture = 2.8,  serial = "8333263" },
    { make = "E. Ludwig",               name = "Meritar 50mm f/2.9",            focal_length = 50,      manual_aperture = 2.9,  serial = "1610554" },
    { make = "Meyer-Optik Gorlitz",     name = "Telemegor 180mm f/5.5",         focal_length = 180,     manual_aperture = 5.5,  serial = "1728275" },
    { make = "Samyang",                 name = "85mm f/1.4 AS IF UMC",          focal_length = 85,      manual_aperture = 1.4} --       serial = "A217D0264" }
--    { make = "", name = "", focal_length = , manual_aperture = , serial = "" },
} -- }}}

Shouldn't make really a difference in space usage... as Photoshop and similar, need to read the whole name to find correct lens correction profile.

Instead could be useful when you got really long lens name, as I can see from your pictures when selecting a lens from menu;

This could be implemented in the PR to have it in next build if you and others find useful; just need to concatenate "make" and "name" when writing ELNS block and XMP metadata.

Quote from: zLOST on January 18, 2019, 12:26:12 PM
I also had an issue where the lens.lua had crashed when i've selected the last lens in the list - 85mm Samyang. With something like "invalid parameter #3 for __nextval(", i can't remember now and since i'm procrastinating at work, i don't have my camera with me now to replicate it at the moment ;)

and one more thing - the serial number was written as "0" even when it was set cirrectly in xmp.properties.. no idea why..
Can you tried to reproduce this? I'm also interested to know if this is happening just in the latest build or not.
Note: the script iterate through attribute in lens table, It may be possible that is not finding the correct values after introducing "make" attribute.

Regarding serial number: save a .mlv and watch for metadata with the modified mlv_dump (compile from manual_leins_info branch). Just to understand if it's only related to XMP or if ML is't saving datas in memory.

Note: mlv_dump was modified in the pending PR to match metadata format, so I don't remember if was working good in old version (current build on ML site).

Quote from: zLOST on January 18, 2019, 12:26:12 PM
If you'd need any help with testing, let me know - i have 650D+6D and couple of non-chipped and chipped adapters to play with.
Yes, absolutely! I have just a couple of cheap adapter on which I based when writing the lens recognition of the script.

They show as "1-65535mm" for name and focal length.
Already refactored to a separate function just in case to make it easy to read and adapt.

function is_manual_lens()
  -- Adapter with no AF Chip -> ID = 0
  -- Adapter with AF confirm Chip -> name and focal length "1-65535mm"
  if (lens.id == 0 or lens.name == "1-65535mm" or lens.name == "(no lens)") then
    return true
  else
    return false
  end
end


Can you check if also your adapter works like this? I imagine should be the same even if different makers, except for Dandelion adapters.

Also need more feedbacks about Raw video recording stability if you are daily video user.
#87
Quote from: reddeercity on January 09, 2019, 04:33:30 AM
That's a CMOS[1] adjustment (Vertical Offset) & Head Timers c0f0713c & c0f07150 (vertical window size for liveview)
not sure if these are the same in 50d
Not quite sure abut CMOS[1] on 50D... his default value is 0x1 and doesn't seems to change from photo mode.
Tryed to increase by little steps but no feedback from LV image.

Instead CMOS[5] looks more interesting, because it's default value is 0x628 after switching to 5x mode and increasing to 0x629 will move image up, decreasing will move image down till image get duplicated/distorted.

Unfortunately small modifications from that value doesn't cover pink are with valid data, just transalate sensor image in upper area untill it gets white...
Didn't tryed increasing/decreasing by larger value, but if this is what you get from CMOS[1] on 5d2, maybe is what I'm looking for.

Quote from: reddeercity on January 09, 2019, 04:33:30 AM
Here a procedure I use to get extended height in 5x zoom(2144x1586) on 5d2 (default 2144x1074)
1-Slow Timer'B" down to 9.98 fps (C0F06014: 0xEDC)
2-Adjust Raw Height C0F06088: 0x66A04BA (1586x2144) we read it as 2144x1586
3-Adjust the Vertical Liveview window (head timers) C0F0713C from 0x476 -> 0x676  & C0F07150 from 0x49C -> 0x69C
Need to do so math for the C0F07150 head timers e.g. 0x49c=1180 vertical default for 5d2 (1074) we need 1586+52(OB offset)=1638
0x69c=1692 , C0F0713C 0x476=1142 (default) need 1586+52(OB offset)=1638  0x676=1654 more then we need but I think you get I the idea .
4-CMOS[1] Vertical Offset adjustment , 0xE6A (default)  change to 0xBOD (just need to play around cmos[1] trial & error)
5-Increase frame rate , c0f06014 0xEDC to 0x4something etc...
Yes, basically it's what I'm doing, except for CMOS. From photo mode 0xc0f06088 = c9d09bb, 0xc0f06014 = c9c and 0xc0f06008 = 4f504f5

Noticed that timers appears to have a little overhead based from math you pointed to me before, should I try to reduce timer and resolution (to mach cr2 and reduce black area) later when I get Full Resolution working?

Quote from: reddeercity on January 09, 2019, 04:33:30 AM
That's the basics , adjust slowly -- if you flip thought the adjustments too fast you can either lockup the cam or loose the image (liveview turns black)
At best most or this is just trial & error plus a few lucky breaks  :D
Cycling through video mode will usually help to get LV working when gets completely dark.

Quote from: reddeercity on January 09, 2019, 04:33:30 AM
Edit: Are you using the 50d 10-12bit build from the experimental download page
or did you use a build compiled from my source file with the add parts (redirect buffer for extended res.) for 50d ?
I'm using your source files with the addittion of 50D's stubs for CONFIG_EDMAC_RAW_PATCH support.
I still need to recompile with what you told me before to add extendeds resolutions.
#88
I'm trying to get full heigth from vanilla 5x just like a1ex and reddeercity already did, but doesen't appears to extend image stright off like previous full width experiment.

I'm getting that pink bottom like this and can't get clean image like this by just increasing Timer B and Head timers.
#89
Quote from: reddeercity on January 04, 2019, 12:51:35 AM
CMOS[2] should center it , check photo mode and see what it is.
I check to see by refreshing liveview with the half shutter button 
Seems the image is always right justified , and it can only be moved to the left from what I seen on 5d2 .
Found CMOS[4] is responsible for horizontal position on 50D, that's why i wasn't noticing any change in value while checking cmos[2]

Strange thing: after poking around cmos registers set to found what said above, for uknow reason now I get automatic centered image while entering liveview and setting full width:

Previuous automatic value:
CMOS[4] = 484
Centered Full Wide:
CMOS[4] = 404
Another Value fond early while logging photo mode, but not sure about
CMOS[4] = 40c


Quote from: reddeercity on January 04, 2019, 12:51:35 AM
That expected , did you try and rec a .mlv file ? Looks like a image dump
more then likely the pink lower bar with not be in the raw video
It was the same for the 5D2
First attempt result in a standard 2000x1079 mlv video....
Discovered that to increase image size while recording, I have to manually increase resolution in movie Tab -> raw video

Max available is 3520 which give a almost good video of 3520x1078 (a couple of vertical dark lines as wrote defore) from a dump of 4768x1078

Is this how is suppose to do or I'm missing something?
@reddeercity Mlv_lite and crop_rec doesn't compile for 50D in Crop_Rec-4k-5d2-magic-lantern_redercit_buffer_a1ex-code-10-22-2018
#90
Quote from: reddeercity on December 27, 2018, 07:43:23 AM
You should see the same list of reg's I posted not just cmos reg's  , that tells me either
didn't enabled the "ENGIO Reg's" in the advanced tab of adtg_gui.mo or you didn't refresh liveview
e.g. load a h264 of review a photo , this a must or nothing will work and you will not get access to the hidden reg's
Sorry, forgot to say that 50D doesn't have movie playback.
Already enabled "ENGIO Regs" and apparently I can find all relevant regs including adtg12[100c] that were mentioned here, just need to switch category to avoid headache after switching to LV end 3X mode :)

Anyway after some days of swpping batteries (damn LV drawn them quickly...) and trying to match full width, I'm still stuck on solving some problems:
1. There is a pink bar at the bottom of the frame when I increase reg 0xc0f06088 (more resolution, more pink area), no matther how TImer A is modified
2. Increasing width will make room for rigth side of framebut will result also in black bar... In other words image is not centered
    Expected to fix with CMOS[2] but no apparently usefull (Need to redo some testing about) and with 0xc0f06084 (small diff from default appears so leave room for left data but then increasing more will only result in moving image to rigth)
3. a couple of gray/green vertical line in the second half of the frame



First DNG is default ML preset, second DNG is attempt of full width:

0xc0f06008 : 0x27b04f5 (from 0x27b27b)
0xc0f06084 : 0x1004b (from 0x1004a)
0xc0f06088 : 0x45209bb (from 0x450452)


Not completely sure about photo mode register's values for FUll Resolution LiveView:

0xc0f06008 : 0x4f504f5
0xc0f06014 : 0xc9c
0xc0f06084 : 0x1004b (from default 1004a)
0xc0f06088 : 0xc9d09bb

They were retrived first time taking FRSP and watch previus values of regs in adtg_gui and then after taking a regular picture while not in LV.
Timing values and resolution appears more higher than needed, is this normal?

What is the relation between Timer A/B regarding FPS and rolling shutter?
I read somewhere on forum one time and can't find anymore (Also still need to finish read half of this thread)

Here is a spreadsheet where I'm trying to summarize what tested and trying not to forget their outcomes
#91
Yesterday I tried to understand what happen if I poke some regs, this is what I get in 5x mode with default settings:



Let's compare behaviour of 50d with 5d2:

If I increase Timer A it will lower FPS, if I decrease value I get more FPS, similar behaviour with TIMER B.

If I try to change image size using c0f06088, it allow me to increase by 1 (value => 0x4530452) and get 1080 vertical but it get upper bounded; tried to lower FPS value (10.572) changing TIMER A => 0x27b070b but no increase in resolution.
Instead if I try to change horizontal resolution (increasing or decreasing) I get distorted pink images...

I saw you modified also other regs (ADTG12[100c], c0f07XXX...) from the one you listed a couple of post above.
How did you find they were necessary? Did you randomly tried register or did you observed what register were changed by canon firmware using adtg_gui?
#92
Quick tested the new build:
Small-malloc test runs good, tried to run more times in a row without any problem :)
Api_test.lua failed at lv_test, will look again later.

Unfortunally it appears to be less stable when recording raw videos, like in previous builds without mem backend improvements for property handler...
Maybe fast_malloc is still needed?

Test I was running back to check raw rec:
Enter liveview and start a recording and then stop, if camera doesn't freezes exit liveview and repeat the same procedure (may fails when entering lives or after stopping rec); mlv_rec is usually less forgivable compared to mlv_lite.

In this build it fails on second run with mlv_rec and I got a camera freeze with mlv_lite when I was navigating ML menu in liveview mode after a recording

Lot of prop_request timeout in console and triggered an assert after selecting lens from menu:

ML ASSERT:
0
at ../../src/mem.c:799 (__mem_malloc), task PropMgr
lv:0 mode:3

PropMgr stack: 139c60 [139f70-138f70]
0x009D8CC4 @ 9e3fe0:139d10
0xUNKNOWN  @ 9d8da8:139cf0
0x0004E3FC @ 9fa3e4:139cd0
0x0004BB38 @ 4e438:139c90
0x0004B378 @ 4bb94:139c60

Magic Lantern version : manual_lens_info.2018Dec23.50D109
Mercurial changeset   : 0de7b671c52c (manual_lens_info) tip
Built on 2018-12-23 22:33:00 UTC by jenkins@nightly.
Free Memory  : 232K + 3150K
#93
Quote from: reddeercity on December 24, 2018, 12:33:00 AM
@aprofiti , Have try it this yet ? I'm courous to see it this work with the 10-12bit build from experimental download page .
If not let me know and I can build it on my 4k 5d2 d4 branch , you may need some of the code from there.
No, not exactly... I tried only to load your linked adtg_gui on top of 10-12bit build, but wasn't working due to linker unable to reference function; probably it's because wasn't compiled for that branch, so I have to retry when I have some spare time.

Crop_rec_4k build could be useful to work with, let me know if you add support for 50D

Edit: Downloaded your source code and applied CONFIG_EDMAC_RAW_PATCH support for 50D. Put in 5x mode and trying to understand what regs are related to resolution.
If I change timer A, image will be altered as expected, but if check resolution from movie tab it doesn't change, even by modifing CMOS regs
#94
Glad to hear this :)

Is the same also with 7D? If I remember correctly it was crashing also on this model when dfort tested it
#95
Quote from: dfort on December 16, 2018, 05:37:37 PM
The 50D might be easier to port -- @aprofiti are you following this?
Yes, I kept reading what reddeercity is posting and maybe I can jump doing some tests in the next weeks, but I need some help from you guys.

Looking at register map to have a better idea of what is going on here, but I feel the need of more documentation about...

From what I understood, first I need to figure out which registers are responsible of height and width of liveview/capture image and then figure out how much fps can be pushed on each resolution, using raw_diag to check bounds for timer values. Is this right?

I tried to poke some registers with adtg_gui in iso-reaserch branch, but no visible effects on image size...
Even changing resolution from raw video menu and log values doesn't seems to show any useful info (well no info at all...)

Modified Cmos[1] and Cmos[2] but nothing changed, leaving these register: C0F06008, C0F06084, C0F06088... after figured out how to increase resolution

Do I need to switch to crop before make anything?
If I remember right I need to push the "zoom" button to switch to 5x, but it doesn't do anything. I think I'm forgetting something about....

Started to read again from the beginning of this thread and I would like to know if is still needed to find/adapt buffer to accommodate larger image size.
#96
Reverse Engineering / Re: Sensor Factory Calibration
December 17, 2018, 01:22:26 AM
Quote from: Greg on December 16, 2018, 04:31:41 PM
These logs are incomplete.
Try 100us or 50us.
Tried again with 50us and got infos for iso 200 and iso 400 but wasn't working with iso 100/800/1600/3200 (neither 100us or 200us).

Iso 200:

EDMAC#9: addr=0x31832c conn=15 cbr=0 name='''''' size='''4832x4'''
EDMAC#0: addr=0x5a10a64 conn=2 cbr=0 name='''''' size='''480x16'''
EDMAC#1: addr=0x5a12c64 conn=28 cbr=0 name='''''' size='''(476, skip 36) x 176'''
EDMAC#2: addr=0x400637c conn=0 cbr=0 name='''''' size='''8456x3228'''
EDMAC#6: addr=0x5a2ade4 conn=18 cbr=0 name='''''' size='''4096x18, 3072'''
EDMAC#8: addr=0x3de078 conn=0 cbr=0 name='''''' size='''2000x224'''
EDMAC#9: addr=0x3d3a9c conn=15 cbr=0 name='''''' size='''8x3228'''

Before and after 1\25 +5EV (mean values and calibration changes on different runs)


Iso 400:

EDMAC#9: addr=0x3265c4 conn=15 cbr=0 name='''''' size='''4832x4'''
EDMAC#0: addr=0x5a10a64 conn=2 cbr=0 name='''''' size='''480x16'''
EDMAC#1: addr=0x5a12c64 conn=28 cbr=0 name='''''' size='''(476, skip 36) x 176'''
EDMAC#2: addr=0x400637c conn=0 cbr=0 name='''''' size='''8456x3228'''
EDMAC#6: addr=0x5a2ade4 conn=18 cbr=0 name='''''' size='''4096x18, 3072'''
EDMAC#9: addr=0x3d3a9c conn=15 cbr=0 name='''''' size='''8x3228'''
EDMAC#8: addr=0x3de078 conn=1 cbr=0 name='''''' size='''2000x224'''




Quote from: dfort on December 16, 2018, 05:20:52 PM
make MODEL=50D
Thank you! Had to make small changes to minimal.c and prop_values.c to solve some errors of missing stubs (sync_caches() and display_idle())

This is what I in console when running in Qemu:

[EDMAC#9] Starting transfer from 0x31832C to <15>, 4832x4, flags=0x10000
[EDMAC#9] 19328 bytes read from 31832C-31CEAC.


How do I change iso from there?
#97
Reverse Engineering / Re: Sensor Factory Calibration
December 16, 2018, 02:29:57 PM
I'm trying to replicate on 50D using EDMAC Log, but I'm a bit stuck because it seems it's missing some infos...

Here is the CR2 ISO 100 log

EDMAC#0: addr=0x5a10a64 conn=2 cbr=0 name='''''' size='''480x16'''
EDMAC#1: addr=0x5a12c64 conn=28 cbr=0 name='''''' size='''(476, skip 36) x 176'''
EDMAC#2: addr=0x400637c conn=0 cbr=0 name='''''' size='''8456x3228'''
EDMAC#6: addr=0x5a2ade4 conn=18 cbr=0 name='''''' size='''4096x18, 3072'''
EDMAC#8: addr=0x3de078 conn=0 cbr=0 name='''''' size='''2000x224'''
EDMAC#9: addr=0x3d3a9c conn=15 cbr=0 name='''''' size='''8x3228'''
EDMAC#12: addr=0x5a2ade4 conn=14 cbr=0 name='''''' size='''4096x41, 128'''
EDMAC#16: addr=0x1f50000 conn=23 cbr=0 name='''''' size='''4096x13, 752'''
EDMAC#3: addr=0x2014088 conn=5 cbr=0 name='''''' size='''7400x4096'''
EDMAC#4: addr=0x143ec070 conn=22 cbr=0 name='''''' size='''((1212, skip 2412) x 395, 1212, skip -1431480) x 2,   (1200, skip 2424) x 396'''
EDMAC#10: addr=0x4000048 conn=0 cbr=0 name='''''' size='''((2884, skip 5572) x 3231, 2884, skip -27321392) x 2,   (2828, skip 5628) x 3232'''
EDMAC#3: addr=0x1454c07c conn=5 cbr=0 name='''''' size='''3260x4096'''
EDMAC#4: addr=0x1f12a30 conn=3 cbr=0 name='''''' size='''48x9x396'''
EDMAC#10: addr=0x4071962 conn=0 cbr=0 name='''''' size='''(((1036, skip 7420) x 13, 1036, skip -110040) x 8,   (1036, skip 7420) x 13, 1036, skip -50708) x 396'''
EDMAC#11: addr=0x5a12c64 conn=33 cbr=0 name='''''' size='''512x176'''
EDMAC#13: addr=0x1f10000 conn=3 cbr=0 name='''''' size='''432x446'''
EDMAC#3: addr=0x1b00f00 conn=6 cbr=0 name='''''' size='''3840x1079'''
EDMAC#11: addr=0x1b00000 conn=6 cbr=0 name='''''' size='''(3840, skip -3840) x 1079'''
EDMAC#3: addr=0xd00000 conn=3 cbr=0 name='''''' size='''(((120, skip 3444) x 2, 120, skip -7128) x 29,   (84, skip 3480) x 2, 84) x 396'''
EDMAC#11: addr=0x1b00000 conn=3 cbr=0 name='''''' size='''1440x252'''


This is what I've done:
- Compiled ML from iso-research branch
- Enabled modules edmac.mo, adtg_gui.mo and raw_diag.mo
- In EDMAC Tool menu I have set Log very 2000us
- Start logging EDMAC by pressing half shutter
- Quickly press half-shutter again to take a cr2 photo

Also how to compile qemu-frsp? if I use the make file from it's folder it tells me that it's missing Camera MODEL.
Do I need to copy minimal.c to /src directory?
#98
Figured out what is causing the crash when running "Small-block malloc" test.

These are the parameters of the allocators on both branch:

Values from lua_fix merge:

        //Malloc Allocator
        .preferred_free_space = 384 * 1024,
        .minimum_free_space = 256 * 1024,

        //Shoot malloc Allocator:
        .try_next_allocator = 1,

        .minimum_alloc_size = 64 * 1024,
        .minimum_free_space = 256 * 1024,

Values from manual_lens_info:

        //Malloc
        .preferred_free_space = 128 * 1024,
        .minimum_free_space = 64 * 1024,

        //Shoot Malloc
        .minimum_alloc_size = 5 * 1024,


Test will run fine in QEMU If I revert using the old parameters.

@a1ex They are from commit 0e56fe7, What parameter I have to use?
#99
I'm trying to find stubs for 77D, using 200D as a reference.

This is what I have at the moment:

/** Startup **/
NSTUB( ROMBASEADDR, firmware_entry )
NSTUB(0xE00400EC,  cstart)                 /* calls bzero32 and create_init_task(..., init_task, ...) */
NSTUB(0xDF00D285,  bzero32)                /* zeros out a data structure. From sub_E0428334
      LDR             PC, =(loc_DF00D284+1) */

NSTUB(0xDF006515,  create_init_task)       /* low-level DryOS initialization. From sub_E0427890
      LDR             PC, =(sub_DF006514+1) */
NSTUB(0xE0040215,  init_task)              /* USER_MEM size checking, dmSetup, termDriverInit, stdlibSetup etc */
NSTUB(0xe065e278,  dcache_clean)           /* loop with MCR p15 c7,c10,1; DSB */
NSTUB(0xe065e34c,  icache_invalidate)      /* loop with MCR p15 c7,c5,1; c7,c1,6; c7,c1,0; ISB */

/** Tasks **/
NSTUB(0xDF008F7E,  task_create)            /* used to start TaskMain, GuiMainTask etc */
NSTUB(0xDF0087FE,  msleep)                 /* argument is always multiple of 10 */
//NSTUB(    0x????,  current_task)           /* from task_create; pointer to the current task structure */
//NSTUB(    0x????,  current_interrupt)      /* from interrupt handler (VBAR + 0x18); where the interrupt ID is stored */

/** Dumper **/
NSTUB(0xe007fc46,  dump_file)              /* tries to save a file to either "A:/%s" or "B:/%s"; calls FIO_RemoveFile/CreateFile/WriteFile/CloseFile/Flush */

/** Memory info **/
NSTUB(0xe02640b4,  malloc_info)            /* Malloc Information */
NSTUB(0xe026414c,  sysmem_info)            /* System Memory Information */
NSTUB(0xe01eaf80,  memmap_info)            /* Exception vector, DRYOS system memory etc */
NSTUB(0xe0164ca6,  smemShowFix)            /* Common Lower, Common Upper etc */

/** Memory allocation **/
NSTUB(0xDF0079D3,  GetMemoryInformation)   /* called from AllocateMemory */

/** Debug messages **/
NSTUB(0xDF006E6D,  DryosDebugMsg)          /* lots of debug messages; format string is third argument */

/** Eventprocs (call by name) **/
NSTUB(0xe04d8aee,  call)                   /* many functions called by name (lv_start, lv_stop etc) */

/** GUI timers **/
NSTUB(0xe04d499a,  CancelTimer)            /* from error message */
NSTUB(0xe05aad76,  SetHPTimerAfterNow)     /* from error message */
NSTUB(0xe05aadca,  SetHPTimerNextTick)     /* same "worker" function as SetHPTimerAfterNow */
NSTUB(0xe04d48e4,  SetTimerAfter)          /* from error message */

/** Interrupts **/
//NSTUB(    0x????,  pre_isr_hook)
//NSTUB(    0x????,  post_isr_hook)
//NSTUB(   0x?????,  isr_table_handler)
//NSTUB(   0x?????,  isr_table_param)

/** MPU communication **/
NSTUB(0xE01E781F,  mpu_send)                  // "dwSize < TXBD_DATA_SIZE"
NSTUB(0xE058866B,  mpu_recv)                  // passed as last argument by InitializeIntercom and eventually stored into mpu_recv_cbr
NSTUB(    0x7CF4,  mpu_recv_cbr)              // mpu_recv is called indirectly through this function pointer
NSTUB(   0x887D4,  mpu_send_ring_buffer)      // ring buffer used in mpu_send
NSTUB(    0x7CD8,  mpu_send_ring_buffer_tail) // ring buffer index incremented in mpu_send
NSTUB(   0x88694,  mpu_recv_ring_buffer)      // ring buffer used in SIO3_ISR, subroutine that processes two chars at a time
NSTUB(    0x7CD0,  mpu_recv_ring_buffer_tail) // ring buffer index incremented in the above subroutine

/** Misc **/
NSTUB(0xe11f93d4,  vsnprintf)              /* called near dmstart; references "01234567", "0123456789", "0123456789abcdef" and "0123456789ABCDEF"; second arg is size; the one called by DebugMsg only knows %s */

Still missing a couple of references to data structures.
After figuring out it should be able to run the same minimal code as current state of 200D.

If someone want to double check and find the remaining stubs, please write down here your finding.

EDIT: More address found. Still missing last isr related stubs

NSTUB(    0x1020,  current_task)           /* from task_create; pointer to the current task structure */
NSTUB(    0x1008,  current_interrupt)      /* from interrupt handler (VBAR + 0x18); where the interrupt ID is stored */

/** Interrupts **/
//NSTUB(    0x????,  pre_isr_hook)
//NSTUB(    0x????,  post_isr_hook)
NSTUB(   0x6D0C0,  isr_table_handler)
//NSTUB(   0x?????,  isr_table_param)
#100
I'm trying to see where it fails using Qemu.

First run saved a couple of log in CF and "Small-malloc test" appears prints debug info in console.
Observed it was allocating 1600 block (which 1000 of these should be from fast_malloc).

Here is the crash log of second run:

ASSERT: pvAddr
at Memory\Memory.c:170, RscMgr:ff867b7c
lv:0 mode:0

RscMgr stack: 13ed20 [13ef98-13df98]
0xUNKNOWN  @ ff86f9b0:13ef90
0xUNKNOWN  @ ff99058c:13ef68
0xFF98FFE8 @ ff82aa6c:13ef40
0xUNKNOWN  @ ff990018:13ef30
0xUNKNOWN  @ ff9900a0:13ef10
0xFF8AD684 @ ff8ae2a8:13eef8
0xFF8AA0D4 @ ff8ad73c:13eec8
0xFF869068 @ ff8aa4c0:13ee58
0xFF868868 @ ff8690e4:13ee40
0xFF86874C @ ff86890c:13ee28
0xFF86AFB0 @ ff868788:13ee10
0xFF867B54 @ ff86afc8:13ed60
0xFF814AC0 @ ff867b78:13ed58
0x0004B378 @ 4b84c:13ed20

Magic Lantern version : Nightly.2018Sep29.50D109
Mercurial changeset   : cc361edea9e6+0040e6ccea8d+ (manual_lens_info)
Built on 2018-09-29 00:21:17 UTC by [email protected].
Free Memory  : 64K + 56K


Qemu console of second run:

ASSERT : Memory\Memory.c, Task = RscMgr, Line 170

AllocateMemory 40
TASK:[RscMgr]
  20:0x8000
  19:0x8000
  18:0x4
  17:0xff86afc4
  16:0x8b2900
  15:0x28
  14:0x8000
  13:0x63eaac
  12:0x19980218
  11:0x13ed60
  10:0x13eddc
   9:0x8000
   8:0xff816904
   7:0xac0078
   6:0
   5:0x63eaac
   4:0x8000
   3:0x8000
   2:0xff98c694
   1:0x387a4  1290: 12935.424 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = RscMgr
  1291: 12935.424 [STARTUP] ERROR ASSERT : Line 170
  1292: 12935.424 [STARTUP] ERROR ASSERT : pvAddr
  1293: 12937.216 [STARTUP] startupErrorRequestChangeCBR (0x1d)
  1294: 12937.216 [STARTUP] startupErrorRequestChangeCBR : ErrorSend (101, ABORT)
[MPU] Received: 08 06 03 03 65 01 00 00  (unknown - unnamed)
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
  1295: 12959.232 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1296: 12959.232 [STARTUP] ERROR ASSERT : Line 170
  1297: 12959.232 [STARTUP] ERROR ASSERT : pvAddr
  1298: 12959.232 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1299: 12959.488 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1300: 12959.488 [STARTUP] ERROR ASSERT : Line 170
  1301: 12959.488 [STARTUP] ERROR ASSERT : pvAddr
  1302: 12959.488 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1303: 12960.000 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1304: 12960.000 [STARTUP] ERROR ASSERT : Line 170
  1305: 12960.000 [STARTUP] ERROR ASSERT : pvAddr
  1306: 12960.000 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1307: 12960.256 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1308: 12960.256 [STARTUP] ERROR ASSERT : Line 170
  1309: 12960.256 [STARTUP] ERROR ASSERT : pvAddr
  1310: 12960.256 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1311: 12960.512 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1312: 12960.512 [STARTUP] ERROR ASSERT : Line 170
  1313: 12960.512 [STARTUP] ERROR ASSERT : pvAddr
  1314: 12960.512 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1315: 12961.024 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1316: 12961.024 [STARTUP] ERROR ASSERT : Line 170
  1317: 12961.024 [STARTUP] ERROR ASSERT : pvAddr
  1318: 12961.024 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1319: 12961.024 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1320: 12961.024 [STARTUP] ERROR ASSERT : Line 170
  1321: 12961.024 [STARTUP] ERROR ASSERT : pvAddr
  1322: 12961.280 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1323: 12961.536 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1324: 12961.536 [STARTUP] ERROR ASSERT : Line 170
  1325: 12961.536 [STARTUP] ERROR ASSERT : pvAddr
  1326: 12961.536 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1327: 12961.792 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1328: 12961.792 [STARTUP] ERROR ASSERT : Line 170
  1329: 12961.792 [STARTUP] ERROR ASSERT : pvAddr
  1330: 12961.792 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1331: 12962.048 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1332: 12962.048 [STARTUP] ERROR ASSERT : Line 170
  1333: 12962.048 [STARTUP] ERROR ASSERT : pvAddr
  1334: 12962.048 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1335: 12962.304 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1336: 12962.304 [STARTUP] ERROR ASSERT : Line 170
  1337: 12962.304 [STARTUP] ERROR ASSERT : pvAddr
  1338: 12962.304 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1339: 12962.816 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1340: 12962.816 [STARTUP] ERROR ASSERT : Line 170
  1341: 12962.816 [STARTUP] ERROR ASSERT : pvAddr
  1342: 12962.816 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1343: 12963.072 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1344: 12963.072 [STARTUP] ERROR ASSERT : Line 170
  1345: 12963.072 [STARTUP] ERROR ASSERT : pvAddr
  1346: 12963.072 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1347: 12963.328 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1348: 12963.328 [STARTUP] ERROR ASSERT : Line 170
  1349: 12963.328 [STARTUP] ERROR ASSERT : pvAddr
  1350: 12963.328 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1351: 12963.584 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1352: 12963.584 [STARTUP] ERROR ASSERT : Line 170
  1353: 12963.584 [STARTUP] ERROR ASSERT : pvAddr
  1354: 12963.584 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1355: 12963.840 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1356: 12963.840 [STARTUP] ERROR ASSERT : Line 170
  1357: 12963.840 [STARTUP] ERROR ASSERT : pvAddr
  1358: 12963.840 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1359: 12964.352 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1360: 12964.352 [STARTUP] ERROR ASSERT : Line 170
  1361: 12964.352 [STARTUP] ERROR ASSERT : pvAddr
  1362: 12964.352 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1363: 12964.608 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1364: 12964.608 [STARTUP] ERROR ASSERT : Line 170
  1365: 12964.608 [STARTUP] ERROR ASSERT : pvAddr
  1366: 12964.608 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1367: 12965.120 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1368: 12965.120 [STARTUP] ERROR ASSERT : Line 170
  1369: 12965.120 [STARTUP] ERROR ASSERT : pvAddr
  1370: 12965.120 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1371: 12965.376 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1372: 12965.376 [STARTUP] ERROR ASSERT : Line 170
  1373: 12965.376 [STARTUP] ERROR ASSERT : pvAddr
  1374: 12965.376 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1375: 12965.632 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1376: 12965.632 [STARTUP] ERROR ASSERT : Line 170
  1377: 12965.632 [STARTUP] ERROR ASSERT : pvAddr
  1378: 12965.632 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1379: 12966.144 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1380: 12966.144 [STARTUP] ERROR ASSERT : Line 170
  1381: 12966.144 [STARTUP] ERROR ASSERT : pvAddr
  1382: 12966.144 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1383: 12966.400 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1384: 12966.400 [STARTUP] ERROR ASSERT : Line 170
  1385: 12966.400 [STARTUP] ERROR ASSERT : pvAddr
  1386: 12966.400 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1387: 12966.656 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1388: 12966.656 [STARTUP] ERROR ASSERT : Line 170
  1389: 12966.656 [STARTUP] ERROR ASSERT : pvAddr
  1390: 12966.656 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1391: 12966.912 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1392: 12966.912 [STARTUP] ERROR ASSERT : Line 170
  1393: 12966.912 [STARTUP] ERROR ASSERT : pvAddr
  1394: 12967.168 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1395: 12967.424 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1396: 12967.424 [STARTUP] ERROR ASSERT : Line 170
  1397: 12967.424 [STARTUP] ERROR ASSERT : pvAddr
  1398: 12967.424 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1399: 12967.680 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1400: 12967.680 [STARTUP] ERROR ASSERT : Line 170
  1401: 12967.680 [STARTUP] ERROR ASSERT : pvAddr
  1402: 12967.680 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1403: 12967.936 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1404: 12967.936 [STARTUP] ERROR ASSERT : Line 546
  1405: 12967.936 [STARTUP] ERROR ASSERT : 0
  1406: 12967.936 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1407: 12968.192 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1408: 12968.192 [STARTUP] ERROR ASSERT : Line 170
  1409: 12968.192 [STARTUP] ERROR ASSERT : pvAddr
  1410: 12968.192 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1411: 12968.448 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1412: 12968.448 [STARTUP] ERROR ASSERT : Line 170
  1413: 12968.448 [STARTUP] ERROR ASSERT : pvAddr
  1414: 12968.448 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1415: 12968.704 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1416: 12968.704 [STARTUP] ERROR ASSERT : Line 546
  1417: 12968.704 [STARTUP] ERROR ASSERT : 0
  1418: 12968.704 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1419: 12968.960 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1420: 12968.960 [STARTUP] ERROR ASSERT : Line 170
  1421: 12968.960 [STARTUP] ERROR ASSERT : pvAddr
  1422: 12968.960 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1423: 12969.216 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1424: 12969.216 [STARTUP] ERROR ASSERT : Line 170
  1425: 12969.216 [STARTUP] ERROR ASSERT : pvAddr
  1426: 12969.216 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1427: 12969.472 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1428: 12969.472 [STARTUP] ERROR ASSERT : Line 546
  1429: 12969.472 [STARTUP] ERROR ASSERT : 0
  1430: 12969.472 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1431: 12969.728 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1432: 12969.728 [STARTUP] ERROR ASSERT : Line 170
  1433: 12969.728 [STARTUP] ERROR ASSERT : pvAddr
  1434: 12969.728 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1435: 12969.984 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = CtrlSrv
  1436: 12969.984 [STARTUP] ERROR ASSERT : Line 170
  1437: 12969.984 [STARTUP] ERROR ASSERT : pvAddr
  1438: 12969.984 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
ASSERT : ShootMemory.c, Task = RscMgr, Line 1112
ASSERT : ShootMemory.c, Task = RscMgr, Line 1114
ASSERT : PackMemory\PackMem.c, Task = run_test, Line 479
ASSERT : Memory\Memory.c, Task = RscMgr, Line 170

AllocateMemory 40
TASK:[RscMgr]
  20:0x8000
  19:0x8000
  18:0x4
  17:0xff86afc4
  16:0x8caa88
  15:0x28
  14:0x8000
  13:0x63eaac
  12:0x19980218
  11:0x13ed60
  10:0x13eddc
   9:0x8000
   8:0xff816904
   7:0xac0078
   6:0
   5:0x63eaac
   4:0x8000
   3:0x8000
   2:0xff98c694
   1:0x30798  1439: 13002.752 [STARTUP] ERROR ASSERT : ShootMemory.c, Task = RscMgr
  1440: 13002.752 [STARTUP] ERROR ASSERT : Line 1112
  1441: 13003.008 [STARTUP] ERROR ASSERT : Error == SUCCESS
  1442: 13003.008 [STARTUP] ERROR ASSERT : ShootMemory.c, Task = RscMgr
  1443: 13003.008 [STARTUP] ERROR ASSERT : Line 1114
  1444: 13003.008 [STARTUP] ERROR ASSERT : Error == SUCCESS
  1445: 13003.008 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1446: 13003.008 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1447: 13003.264 [STARTUP] ERROR ASSERT : PackMemory\PackMem.c, Task = run_test
  1448: 13003.264 [STARTUP] ERROR ASSERT : Line 479
  1449: 13003.264 [STARTUP] ERROR ASSERT : IsChunkSignature( hChunk )
  1450: 13003.264 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
  1451: 13003.520 [STARTUP] ERROR ASSERT : Memory\Memory.c, Task = RscMgr
  1452: 13003.520 [STARTUP] ERROR ASSERT : Line 170
  1453: 13003.520 [STARTUP] ERROR ASSERT : pvAddr
  1454: 13004.800 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x1d => 0x1d)
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 546
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : Memory\Memory.c, Task = CtrlSrv, Line 170
ASSERT : ShootMemory.c, Task = RscMgr, Line 1112
ASSERT : ShootMemory.c, Task = RscMgr, Line 1114


Maybe there is something with the changes from lua_fix in allocator selection or dimension?