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.


Topics - Marsu42

Pages: 1 2 3 [4] 5 6 7
76
General Development / CONFIG_ARRAY_ELEMENT impossible in modules?!
« on: July 11, 2013, 04:08:44 PM »
I'm trying to use the method from hdr.c for array variables in my module, but it won't work - is it me or isn't this supported in modules (yet? if so, please do add :-)) ... this is part of my (abridged) module code:

Code: [Select]
static int8_t mymodule_var[2];
CONFIG_ARRAY_ELEMENT("mymodule.var.0", mymodule_var, 0, -1);
CONFIG_ARRAY_ELEMENT("mymodule.var.1", mymodule_var, 1, -1);

MODULE_CONFIGS_START()
    MODULE_CONFIG(mymodule_var)
MODULE_CONFIGS_END()

... and this is the compiler error:

Code: [Select]
[ CC       ]   mymodule.o
mymodule.c:6:1: error: '__config_mymodule_var' undeclared here (not in a function)
make[1]: *** [mymodule.o] Error 1
make[1]: Leaving directory `/ml/magic-lantern/modules/mymodule'
make: *** [mymodule] Error 2

77
Feature Requests / AF point switch based on level indicator?
« on: July 09, 2013, 10:45:33 AM »
The shiny new cameras have a fw option to switch the af point based on landscape or portrait position - is it possible to backport this to the older generation like 60d, i.e. can we read the level indicator position outside lv? If so, it'd be great to be able to save a af pattern for each position that is auto-recalled if you turn the camera.

78
Feature Requests / How to use non-static values in menu structs?
« on: July 04, 2013, 04:18:42 PM »
EDIT: Doh, sorry, wrong subforum (was supposed to go into development general) :-\ ... maybe you could let users delete their own posts/threads? Anyway:

For the ml auto iso module, I'd like to use this...

Code: [Select]
        .children =  (struct menu_entry[]) {
            {
                .name = "Min. Av Shutter",
                .priv = &m42_aiso_shutter,
                [color=red].max = FASTEST_SHUTTER_SPEED_RAW/8-11,[/color]
                .icon_type = IT_PERCENT,
                .choices = CHOICES("OFF", "1/15", "1/30", "1/60", "1/125", "1/250", "1/500", "1/1000", "1/2000", "1/4000"),
                .help = "Preferred shutter for Av mode (+/- 0.5 EV result).",
                .help2 = "Selectable values starting from 1/15 in 1 EV steps.",
            },

... problem is that FASTEST_SHUTTER_SPEED_RAW is a model-specific constant and I have to grab it with a getter function from the core code.  But the menu struct stuff doesn't seem to accept any non-static values, any idea how to get around this?

79
General Development / [ANSWERED] How to get measured ec in M mode?
« on: June 16, 2013, 11:45:04 PM »
I'd like to copy 400plus' EC on M approach (described here: http://www.magiclantern.fm/forum/index.php?topic=4514.msg49214#msg49214) ...

I had a look at the code, and it's completely different than my, thus my question: How do I get the measured ec in M mode when the user engages metering? Based on that, I then could calculate the required iso and apply ec on m on top of that.

Here's the relevant 400plus code, what I want from ml is this "status.measured_ec" value.

Code: [Select]
// M mode: set ISO to match exposure
ec = - (status.measured_ec - persist.ev_comp);

// Normalize an apply new ISO
if (ec != EC_ZERO) {
if (settings.autoiso_relaxed)
ec = (ec - 1) / 3;

newiso = DPData.iso + ec;
newiso = CLAMP(newiso, settings.autoiso_miniso, settings.autoiso_maxiso);
newiso = EV_ROUND(newiso);

send_to_intercom(IC_SET_ISO, newiso);

80
I'm trying to add "EC on M" to the auto iso module - so far so good, it's basically adding/substracting some shutter or aperture and setting it (thanks for figuring out round_shutter...), respecting some limits. Problem is:

If I modify aperture/shutter in M mode, it immediately shows as if the user would have set it and doesn't work as ec in tv/av. So I have to correct the exposure value before and after taking the shot. Is there a way to "wrap" the Canon shot with ml functions, i.e. hook before and after it? If not, I'd have to try half shutter as before and somehow shoot task as after, but I don't think I'd get this to be really reliable :-\

81
General Development / [ANSWERED] CONFIG_FRAME_SHUTTER/ISO_OVERRIDE?
« on: June 16, 2013, 01:21:42 AM »
What's this set_frame_shutter_timer/iso() that's apparently so hot...

* is this a 1:1 replacement for lens_set_rawshutter/iso on supported camera bodies so I can use them in the ml auto iso module?
* ... or are the new functions only for lv, might be since I found them used in the CBR_VSYNC_SETPARAM?

Thx.

82
Um, what's the prop again please to change how the camera starts af (by backbutton (=1) or half shutter (=6))? Is this the same across all models? Thanks!

83
General Development / How to detect SHOOTMODE_C ?
« on: June 15, 2013, 03:34:20 PM »
I want to detect if the dial is on (one of the) C settings, but at least on 60D shooting_mode isn't detected SHOOTMODE_C but  the original mode saved as C, in my case SHOOTMODE_AV ... how do I manage tell C (i.e. AV saved as C) from real AV?

Btw sorry to be a bother but some things don't work as I expect and then you people who are more in depth with the code are likely to be able to help...

84
Feature Requests / Description box for modules
« on: June 15, 2013, 12:06:50 PM »
As it is now, the module "description" line is rather a "title" because it's so short and just one line. It'd be nice to have a real "description" line that pops up in a submenu-style box where the modules features & help text can be entered, now that we're not so tight on space anymore a few bytes more shouldn't matter? For modules that aren't self-explanatory or contain several features that'd be a great help.

Request: rename current "MODULE_STRING("Description", ...)" to "MODULE_STRING("Title", ...")" and add a "MODULE_BOX("Description", ...)" or something like that. Another option would be a multi-line ""MODULE_STRING("Description", ...)"  instead of the one-liner that is clipped now.

85
Not only seem to be some issues with ACR (nor) reading xmp files (see http://www.magiclantern.fm/forum/index.php?topic=5724.msg50383#msg50383) but I'm a big fan of tagging with keywords so I can quickly sort files in postprocessing.

Request: Add a "ML Deflicker" Keyword to the xmp files so you know which files have been ev-corrected by ml (so you can copy/past processing settings) and as a sideeffect you know your postprocessing software has read/processed them at all. Should be trivial to implement, as long as you don't juggle around with keywords it's just one added line.

86
Feature Requests / Different ml configs for Canon C modes
« on: June 12, 2013, 08:14:32 PM »
I know there is a "Rebelized" C-Mode patch in the queue, but this is something else I'd consider important and easy to implement, though I don't know if this feature request has come up in the past (couldn't find it):

Canon C Modes (60d: 1, 7d/6d: 2, 5d3: 3) are about saving an entirely different config for quick access. While that might be not the most flexible approach ever, it certainly works, and in the summer I use my C mode for a action mode (high iso, fast fps, servo af, spot metering, ...).

Problem is: If I have something set in the ml config like handheld mlu the C mode is worthless because the enabled ml feature defeats the purpose. So after choosing C I'd have to either recall another ml config (though picoc or whatever) or disable the intervening features manually, that takes time and the shot is gone.

Request: Add an option that for each Canon C mode ml loades another config, so there are (number of C modes) +1 generic config file.

Implementation: Should be simple, if a C mode is selected and there's no existing MAGIC-Cx.CFG (i.e. MAGIC-C1.CFG, MAGIC-C2.cfg, ...) copy the current settings, otherwise load the appropriate MAGIC-Cx.CFG file. If the user wants to delete the MAGIC-Cx.CFG file it could be done by the "reset config" item (or manually on the card, of course). At least that's my first idea, certainly can be  streamlined, if alex or someone else is willing to adopt the idea.

87
Feature Requests / [WONTFIX] Auto-HDR after failed Auto-ETTR
« on: June 11, 2013, 10:13:29 PM »
Auto-ETTR is so nice I'm getting too lazy for proper manual or even semi-automatic exposure :->, and here's the way to get even lazier (and save some shutter cycles which are burned by auto ettr):

When Auto-ETTR fails, i.e. the scene has too much dynamic range, ml should give the user the option to do proper bracketing right away, capturing *only* the frames that aren't already taken (more or less). Otherwise doing a manual ml bracket afterwards takes time to initiate and it's likely the camera takes the *same* (more or less) frames again that auto-ettr already has.

The drawback is that the auto-ettr frames aren't "properly" spaced as real bracketing would, but personally I wouldn't care since +-1ev can easily be done in post before merging and tonemapping. It would just be nice if ml could add some frames with the spacing set in the ml bracket options, certainly better than simply failing auto-ettr.

Btw. adding a 2nd overexposed bracketing frame also makes sense when the result of auto-ettr is that there's much data in the deep shadows which might be affected by noise after postprocessing.

88
Feature Requests / [DONE] ML Auto ISO (as a module)
« on: June 11, 2013, 10:11:23 AM »
Recently my most used ml feature was axed: ml auto iso, it is supposed to be superseded by ettr and/or the dev(s) lost interest in it as far as I understand it. For me personally this isn't an issue because I re-patched it into my local build, so I'm fine as long as the patch applies more or less - but others might not be so lucky.

Request: re-add ml auto iso, as a module if it need be (maybe ml goes the modularized way anyway, probably not a bad idea)

Rationale: ml auto iso made two vital things possible that at least I have been missing as long as having a dslr and using auto iso: prevent the lens from going wide open in Tv and override Canon's shutter speed decision (either too fast for landscape or too slow for action) in Av mode. ETTR is completely different and does *not* replace this because it needs up to 2 junk shots to calibrate, while ml auto iso is/was a quick "good enough exposure" mode for action with selectable depth of field (Av with ml auto iso) for macro/landscape/walkaround with selectable motion blur stopper (Tv with ml auto iso).

Edit 1: Also if anybody is up to it feel free to implement smaller than full iso steps (though this seems to need some wizardry since ml currently uses Canon's algorithm as far as I understand it). But it was working as it was and a bit step up from bare Canon auto iso...

Plus: Also nice would be *upper* limits for either aperture (too small aperture = diffraction) and shutter (too high shutter = camera cannot use flash x-sync anymore) :-)

Edit 2: M mode also is no alternative, no only because it's slower but there is no "ec on m" and I ec on every other shot with the back wheel

89
Feature Requests / Custom tags in xmp sidecards for image review?
« on: June 06, 2013, 05:40:31 PM »
The ability of ml to generate xml files is great, and I wonder: I usually pre-review and rate image in-camera thanks to the quick lv button shortcut. Would it be possible to add other tags to the xmp file like (custom) keywords that are then read into lightroom? If this is possible it would be a great timesaver because if I could pre-sort the images next to the very basic rating like now, for example decide which shots are good but slightly out of focus so they're only ok for web size.

90
Feature Requests / Handheld MLU: custom upper limit
« on: June 06, 2013, 05:26:35 PM »
I've come to like this feature with my non-IS 17-40L lens and the severe iso limit of the crop sensor - but imho the 1/2...1/125s limit is completely arbitrary, so it would make sense to let the user at least set the upper limit. Yes, I can set it to "always on" and enable it on a shot-by-shot basis, but if there's the auto shutter speed option it should be done right :-)

91
Feature Requests / Auto-ETTR feature requests
« on: June 06, 2013, 05:13:32 PM »
I've been trying auto-ettr a lot today, it's really a terrific feature, great work! The one real limit is the need to take one trash pic or enable lv, but of course than cannot be helped. I have some feedback since I feel this great feature deserves to be as usable as possible for as many people as possible:

1. the unavoidable request: Please add an option to allow ettr to open the aperture to user settable limit (so the dof doesn't get too small). Ideally there would be a priority option what to do in what sequence: raise iso (until Canon limit), lower shutter (until set limit), open aperture (fixed like now or until set limit). Rationale: If looking for a proper exposure for example on my 17-40L I'd rather go from f8 to f5.6 (wide open would be f4) then raise iso further, and if auto-ettr doesn't do it for me I have to do it manually.

2. DONE auto-ettr doesn't seem to work with "image review" off? If so, ml should set it to 2s to avoid confusion EDIT or at least give a warning message in the menu.

3 EDIT DELETED because you can overexpose the 1st shot, but have a 2nd to get the 3rd to ettr.

4. DONE option to prevent 2nd shot before ettr calculation: I stood at a very busy street in bright sunshine and could neither hear the ettr ready beep nor see the display. Sure I could just wait some, but it would be nice to have an option to block the 2nd shot until the ettr calculation is done, otherwise the 2nd is like the 1st... if blocking is not possible maybe an option to do the 2nd shot automatically once ettr calculation is complete?

5. EDIT DELETED because ml cannot re-load previous shots as raw and ettr them.

92
I can't help being curious: There is this lv_rec module that doesn't work on my 60d (yet?) due to undefined symbols that are only there (yet?) for digic5 650d/6d/5d3/eosm - what is this module? Will it be available on digic4 also - I got raw_rec working by now...

93
Forum and Website / Is there a "This is what ML can do" page?
« on: April 18, 2013, 09:25:16 AM »
When telling people to check out ml I'm always wondering if there's a simple page that explains what ml can do for you (and the Canon fw cannot) with simple descriptions and sample videos and shots for the features.

When looking at the current website it's all about new ports, legal and tech considerations, a faq with lot of text, sample videos/shots but nothing to actually explain what the user did with ml and what the result was, or what usuability enhancements ml has over Canon. No, I'm not volunteering to add this to the site :-p but if anyone else has some spare time an "introduction" page would be a good idea.

94
General Development / Dev Request: UI for mapping functions to buttons
« on: April 11, 2013, 01:12:05 AM »
The smaller camera models, and even the bigger ones like 60d are not very good at customization - Canon only allows for a very limited mapping like some functions to set. With ml it's generally easy to implement a more extensive system, I just added a non-lv meta key with timeout similar to the lv-shortcuts function.

The problem is that I can either hardcode some function mapping (what button does what), but with the current menu system is not designed to do a n:m mapping of one of all available functions to one of all available buttons that generate an event code. It's the same with the 600dplus Rebel ui in the recent pull request, there's no way for the user to choose what arrow keys do what.

Imho it would be a great step forward for ml if there would be a pretty ui that visualizes all available buttons, lets the user select them and then choose what functions should be mapped. There are plenty of Canon and ml functions that would be nice to toggle without going through the menu - either on/off functions (for example bracketing on/off) or binary toggle keys (for example toggle between one shot and servo af).

I'm not able to code such an ui, but I'd like to propose the idea to the people who are if the idea seems reasonable?


95
General Development / af patterns: is afp_len always the same?
« on: April 10, 2013, 07:02:13 PM »
I just added the option to remember different af points/patterns to my sticky modes feature, it works fine.

* I am wondering if the afp_len is different for different points/patterns, or is it always the same on one camera model? As far as I see it, afp_len is always 7 on my 60d and thus wouldn't have to be saved for each mode or at all.

96
After much frustration, I realized the values in property.h for AF_MODE_AI_FOCUS & AF_MODE_AI_SERVO are wrong for my 60D ... imho something is completely wrong with short props like PROP_AF or it has model-specific values in platform/xyz - below are the values that are saved from the camera and work when setting it.

Doh, now I need some time off, I like taking pictures but this is frustrating - and I again realize your stellar work that has made the current framework possible.

Code: [Select]
diff -r db64fd3c5bdc -r 4e501b44d217 platform/60D.111/gui.h
--- a/platform/60D.111/gui.h Wed Apr 10 14:54:10 2013 +0200
+++ b/platform/60D.111/gui.h Wed Apr 10 15:38:04 2013 +0200
@@ -70,4 +70,7 @@
 
 #define BTN_ZEBRAS_FOR_PLAYBACK BGMT_UNLOCK // what button to use for zebras in Play mode
 
+#define AF_MODE_AI_FOCUS 514
+#define AF_MODE_AI_SERVO 257
+
 #endif
diff -r db64fd3c5bdc -r 4e501b44d217 src/property.h
--- a/src/property.h Wed Apr 10 14:54:10 2013 +0200
+++ b/src/property.h Wed Apr 10 15:38:04 2013 +0200
@@ -64,11 +64,9 @@
 #define PROP_USBDEVICE_CONNECT  0x8004000a
 #define PROP_MVR_MOVW_START0    0x80000020 // not sure?
 #define PROP_MVR_MOVW_START1    0x80000021
-#define PROP_AF_MODE            0x80000004 // 0 = one shot, 3 == manual focus, 202 = ai (dumb) focus, 101 = ai servo (slightly better)
+#define PROP_AF_MODE            0x80000004 // 0 = one shot, 3 == manual focus, ai focus & ai servo are model-specific
 #define AF_MODE_ONE_SHOT   0
 #define AF_MODE_MAN_FOCUS  3
-#define AF_MODE_AI_FOCUS 202
-#define AF_MODE_AI_SERVO 101
 #define PROP_MVR_REC            0x80030002
 #define PROP_LV_LENS            0x80050000
 #define PROP_LV_0004            0x80050004

97
General Development / 2nd level submenus?
« on: April 10, 2013, 11:52:26 AM »
I tried to add a 2nd level submenu to the sticky modes feature, but it didn't work - see near sticky_modes_display_values in https://bitbucket.org/hudson/magic-lantern/pull-request/72/sticky-modes-new-bracketing-sequence-delay/diff)

Did I do something wrong (certainly possible my these manual menu structures) or are 2nd level submenus simply not supported currently? Is there any other place in the menu structure where 2nd level submenus already exist so I have a template to copy/paste?

98
General Development / Refactor/Relocate PROP_HANDLER
« on: April 09, 2013, 12:51:36 PM »
While adding some code I noticed one thing that doesn't make wading through the code easier: the PROP_HANDLER statements are all over the place and just happen to be near the feature they were originally intended for, not matter what happened in the meantime.

I know refactoring/relocating shared code generally causes a lot of confusion and merging problems, but for my 2 cents if you do anything like that sooner or later, imho concentrating all PROP_HANDLERS in one location would be a good idea, even if there are less static and more extern vars. The features would then integrate their hooks into the handlers, and this would make merging easier afterwards.

One example I just stumbled across was the PROP_HANDLER for PROP_AF_MODE that was taken by some obscure 5d3 feature, with just one line of code - and I didn't even realize that the whole handler was in a #ifdef and why the handler didn't respond :-\

99
General Development / [SOLVED] Cannot change the af mode with my code
« on: April 08, 2013, 12:54:52 PM »
I can change drive, iso, metering, ae just fine - but the camera doesn't want to change the af mode ... any idea why?

Code: [Select]
lens_wait_readytotakepic(64);
new_af_mode = ONE_SHOT;
prop_request_change(PROP_AF_MODE, &new_af_mode, 4);
msleep(10);

100
I installed PROP_INT and PROP_HANDLER for drive, af, iso, metering and ae where they didn't exist - everything works fine (except af, see other question in thread). However in lens.c I saw that before changing the prop there is a lens_wait_readytotakepic() and afterwards a short msleep() - is this necessary or good practice for changing props in general like the ones I mentioned?

Code: [Select]
void lens_set_drivemode( int dm )
{
    lens_wait_readytotakepic(64);
    prop_request_change( PROP_DRIVE, &dm, 4 );
    msleep(10);
}

Pages: 1 2 3 [4] 5 6 7