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

#1
Nitfreak, first thanks for the hard work, I haven't posted but have been tinkering with the firmware since one of the earlier Alphas.

After avoiding another hobby interest, I have finally been sucked into contributing and am working on some minor feature enhancements (non 70D specific).  I am currently working out of the Unified branch, but only have a 70D so I will probably make a fork of it as well to test changes.

I don't want to be the guy asking for dates(they really aren't relevant), but wanted to know your thoughts on merging with the nightly builds.  Are you hoping to "finalize" the 70D branch and get most or all features working 100% before committing, or to stabilize the core features and merge earlier knowing that additional work is needed?
#2
Feature Requests / Re: HDR ISO Shifting finer increments
September 24, 2015, 03:19:23 AM
dfort, thanks for the thoughts.  I was weighing the options you had listed and had pretty much decided the 70D fork with cross hacks from your repository for compiling would be the way to go.  I will just use notepad ++ to merge my unified derived shoot.c with nitfreaks and just maintain both files independently as the code changes are really trivial.  While Nitfreaks 70D branch has been rock solid for me, I doubt it will be merged soon considering the lag for much smaller commits.
#3
Feature Requests / Re: HDR ISO Shifting finer increments
September 23, 2015, 04:20:44 AM
dmiligan's tips are useful as always, but I'm in the boat of trying to figure out how to fork the 70D repository while committing to the central nightly project.  I don't want to get too far off topic, but any ideas?
#4
Dfort, do you have a list of changes you made to get unified to build?  I pulled a copy of the central repository and just like you mentioned, it fails to build.  Once I get that up and running, I'll get tinkering with the 70D branch.
#5
Feature Requests / Re: HDR ISO Shifting finer increments
September 22, 2015, 01:52:15 AM
Ok, it compiles.  I had one typo in my above code, the comma needs to be removed from the end of the line

"Half: Bracket with both ISO (50%) and main variable (50%).\n"

Total code increase is 192 bytes, most of that is in the additional menu item text, but the bit shift was less efficient than I had hoped.

I'm still figuring out how to get shoot.c into my bit bucket Repository (it is public now)
#6
dfort, my build was of the universal (marked EOS M) branch you linked to in the guide just as a test.  The 2 byte difference was from the zip algorithm in 64 bit.  Once unzipped, I have the same 2,167,786 byte size.  A proper MD5 hash probably isn't needed to confirm.
#7
dfort, great job on the write up, I was able to get msys2 up and compiling with relatively little fuss on a 64 bit Windows 8 box.  I did find that Mercurial's suggestion window to restart was more of a requirement as hg was not recognized until after a full restart of Windows.

Just to validate, my build of the nightly branch at the time of the post was 1,551,114 bytes, what are you seeing?
#8
Feature Requests / Re: HDR ISO Shifting finer increments
September 20, 2015, 04:06:53 AM
dfort, thanks for the link, I'm installing it now.  I haven't put anything up on bitbucket yet, my hobby time has been scouting locations for the upcoming eclipse.  I'll post when I get something that at least has a chance of compiling.
#9
Feature Requests / Re: HDR ISO Shifting finer increments
September 18, 2015, 02:25:08 AM
Never mind about the scripting, I finally found dmilligan's thread for his LUA work at http://magiclantern.fm/forum/index.php?topic=14828.0

I'm still going to work on getting a build environment for the ISO ramping, but it looks like I have something else to play with.
#10
Feature Requests / Re: HDR ISO Shifting finer increments
September 17, 2015, 03:53:54 AM
DeafEyeJedi, you are welcome to try a build with this.  I am on the road and wont be able to put up a complete .c file with the changes on bitbucket, but between my post and dmilligan's bit shift, it may all come together.

On a slight tangent, is scripting still left out of modern builds?  I have a shoot on the 27th and am looking at backup options in case I cant compile for the 70D in time.
#11
Feature Requests / Re: HDR ISO Shifting finer increments
September 16, 2015, 12:54:59 AM
Oh the joys of setting up a build environment.  Sadly dmilligans cloud compile setup doesn't work for new non paying users due to changes in the TOS and the pre-built virtual box image from a few years ago hits a critical error loading linux mid way thru and very little is shown about the message.

I guess I get to roll my own from scratch.  There are a plethora of setup guides on this site, but after reading and following many of them from Audionuts link, I'm still a little in the dark about building under Windows, I gave up Linux in the infancy of 2.6.x
#12
Feature Requests / Re: HDR ISO Shifting finer increments
September 15, 2015, 03:08:47 AM
I'm going to take the plunge and get virtual box set up.  I'm still a little fuzzy on the details as many of the well written guides are a bit contradictory, but I guess that is part of the fun.  At least the 70D branch still uses the unified shoot.c so I won't be fighting between 2 versions.
#13
Feature Requests / Re: HDR ISO Shifting finer increments
September 14, 2015, 02:50:42 AM
dfort, I wasn't exactly looking for 1/4 increments on the time/ISO variables, but to split the EV increment (I usually use 2, but have used 3 when pushed to do so) with most of the EV set with time adjustments and a smaller portion set with ISO changes.  I believe 1/2 or 1/3 (depending on settings) increments are all that are available on most models, but I think ML  does math in 1/8th increments based on the /8 statements and the naming of the ev_x8 variable.  I haven't traced out the code to figure out what is actually saved in max_auto_iso, iso0, ev_x8, but I was hoping someone could point out the fallacy of my idea.

dmilligan, I am familiar with rev management systems in theory only, I have wanted to set one up for my projects, but never could justify the time.  I'm pretty sure I won't be able to set up the build test environment to validate my changes that I would need to do before I would feel comfortable submitting a pull.

I am likewise unfamiliar with the blame process to figure out why the menu details display is iso/ISO.  I don't know the character limit of this display on other cameras, but on the 70D I think Full, Half, Quarter or ISO, 1/2 ISO, 1/4 ISO would be appropriate.

If you or anyone else is already set up to try this change out and submit a pull, I would love to see it submitted.  While it would be fun to do it myself, I just don't think it will happen.
#14
Feature Requests / Re: HDR ISO Shifting finer increments
September 13, 2015, 04:05:08 AM
dmilligan, You are absolutely correct.  I only suggested a look up table as it decoupled the order of the menu from actual values in the chart (I can't see the need for a 3/4 setting, but this would enable it).  My programming experience is typically not on resource limited platforms, but this seems like a good way to economize as long as it is documented that the menu order is critical.

Out of curiosity, do you have any thoughts as to its merits for inclusion?  I am after all just a weekend hack photographer/programmer.
#15
Feature Requests / HDR ISO Shifting finer increments
September 13, 2015, 12:20:41 AM
I have an application for a very large dynamic range shot and wanted to use ISO shifting to get the most out of the camera.  Unfortunately when set to half, I hit ISO limits way before shutter speed becomes an issue. There are about 5 orders of magnitude of shutter speed range, but little more than one worth of usable ISO.  It seems reasonable to have a smaller increment than half.  Ideally a process that gives more control over when and how ISO shifting kicks in could be implemented, but that is beyond the scope of this request.

I have some software experience, but am not at the point that I can fully implement, build, test, and upload a project of this complexity.  With that said, I dug into shot.c and found it should be a reasonably simple process to add a Quarter shift option assuming the ISO rounding math works out.  An "Eighth" option could probably be added as well, but I am starting simple.  I have listed snippets below that would be a start to implementing this, I don't know variable naming conventions so the new name is arbitrary.

I apologize for the long post, but am trying to do what I can to help.  Feel free to ignore it if I am being too presumptuous.

Updates probably needed to shoot.c Changes marked in red

Add menu items under menu_entry shoot_menus[]

                .name = "ISO shifting",
                .priv       = &hdr_iso,
                .max = 3,
                .help =  "Also use ISO as bracket variable. Range: 100 - max AutoISO.",
                .help2 = " \n"
                         "Full: try ISO bracket first. If out of range, use main var.\n"
                         "Half: Bracket with both ISO (50%) and main variable (50%).\n",
                         "Quarter: Bracket with both ISO (25%) and main variable (75%).\n",
                .choices = CHOICES("OFF", "Full", "Half", "Quarter"),
                .icon_type = IT_DICE_OFF,

Under hdr_iso_shift, the existing code takes advantage of an inline statement to select between one of 2 factors. While this is efficient code, it needs to be replaced by a look up table  that sets a division factor (I'll call the new variable hdr_iso_shift_factor) based on the menu item chosen.  "1 Full" needs to be set to 1, "2 Half" needs to be set to 2, and "3 Quarter" needs to be set to 4.  For code organization purposes, this could be put in several different areas.  The code is trivial, but I will assume hdr_iso_shift_factor has already been set by the time the code below runs.


static int hdr_iso_shift(int ev_x8)
{
    hdr_iso00 = lens_info.raw_iso;
    int iso0 = hdr_iso00;
    if (!iso0) iso0 = lens_info.raw_iso_auto;

    if (hdr_iso && iso0) // dynamic range optimization
    {
        if (ev_x8 < 0)
        {
            int iso_delta = MIN(iso0 - MIN_ISO, -ev_x8 / hdr_iso_shift_factor); // lower ISO, down to ISO 100

            // if we are going to hit shutter speed limit, use more iso shifting, to get the correct bracket
            int rs = lens_info.raw_shutter;
            int rc = rs - (ev_x8 + iso_delta);
            if (rc >= FASTEST_SHUTTER_SPEED_RAW)
                iso_delta = MIN(iso0 - MIN_ISO, iso_delta + rc - FASTEST_SHUTTER_SPEED_RAW + 1);

            iso_delta = (iso_delta+6)/8*8; // round to full stops; also, prefer lower ISOs
            ev_x8 += iso_delta;
            hdr_set_rawiso(iso0 - iso_delta);
        }
        else if (ev_x8 > 0)
        {
            int max_auto_iso = auto_iso_range & 0xFF;
            int iso_delta = MIN(max_auto_iso - iso0, ev_x8 / hdr_iso_shift_factor); // raise ISO, up to max auto iso
            iso_delta = (iso_delta)/8*8; // round to full stops; also, prefer lower ISOs
            if (iso_delta < 0) iso_delta = 0;
            ev_x8 -= iso_delta;
            hdr_set_rawiso(iso0 + iso_delta);
        }
    }
    return ev_x8;
}

I'm not quite sure whats going on in MENU_UPDATE_FUNC and why ISO needs to be capitalized for "Full" option 1 and lower case for "Half" Option 2.  For a new "Quarter" option 3 setting this to ISO or iso would aid consistency, or all of them could be updated to reflect the actual setting more closely.

        MENU_SET_RINFO("%s%s%s",
            hdr_sequence == 0 ? "0--" : hdr_sequence == 1 ? "0-+" : "0++",
            hdr_delay ? ", 2s" : "",
            hdr_iso == 1 ? ", ISO" : hdr_iso == 2 ? ", iso" : hdr_iso == 3 ? ", ISO" : ""
        );

Now for the obligatory thanks to all of the Devs, yes, this is my first post, but I have been a long time user and love the work being done on the 70D branch.  I have always found what I needed with the search and just now had a real need to create an account.