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 ... 7
26
Tragic Lantern / Help needed with mini_iso calibration for 6D
« on: February 02, 2014, 09:41:52 PM »
Yo 6d users (and esp. 1%), your help is needed to get the new mini_iso module working on the 6d:

Alex has now support for it and raw_diag also works on the 6d, problem is that for well known reasons he's currently not too enthusiastic about the whole 6d thing unless some TL back-merging is done. But if someone wants to give it a try and calibrate for the 6d, I'm sure he'll pm you the link to the dev binary.

This needs to be done (again), I did only part of it and haven't got time to continue: https://docs.google.com/document/d/1neb3q36YeQm6HuPTy6-cMmcnVTswsRXSQ-sNSCCLM_Q/edit#

This is what I found:

* the module works, mini_iso @ neutral with 0ev gain settings is identical to Canon & I calibrated it. It does show the desired effect to gain dynamic range - so far, so good.

* problem is: the module refuses to force the values into to the desired white level range set in the options (acr, dcraw, ...). The question is if I did something wrong, or there's something different on 6d than 5d3/60d where it works just fine.

* todo for you: repeat the series so that we can see if my measurements were wrong or the module really isn't working on the 6d as expected.

# --

Here's my 6d calibration:
# Config file for module mini_iso (MINI_ISO.MO)
black.opt = 0
calibrated.gain.100 = -29
calibrated.gain.200 = -32
calibrated.gain.400 = -37
calibrated.gain.800 = -39
calibrated.gain.1600 = -42
calibrated.gain.3200 = -51
calibrated.gain.6400 = -53
calibrated.gain.12800 = -153

Here's the sheet (I didn't do the last row of f0.0), black was always 2047 or 2048, white sometimes changed by a minor amount on multiple tests:

;white/0.0;dr/0.0;white/2.8;dr/2.8;ml/gain;ml/eq.iso
100 Canon;15331;11,458;15498;11,470;-0,29;82
100 ML@0;15331;11,455;15498;11,470;;
100 ML@-1;;;10485;11,802;;
200 Canon;15331;11,450;15498;11,459;-0,32;160
200 ML@0;15331;11,446;15498;11,460;;
200 ML@-1;;;10312;11,768;;
400 Canon;15331;11,304;15498;11,316;-0,37;310
400 ML@0;15331;11,282;15498;11,302;;
400 ML@-1;;;10727;11,649;;
800 Canon;15331;11,072;15498;11,087;-0,39;610
800 ML@0;15331;11,030;15498;11,083;;
800 ML@-1;;;10846;11,403;;
1600 Canon;15331;10,644;15498;10,668;-0,42;1195
1600 ML@0;15331;10,544;15498;10,560;;
1600 ML@-1;;;11025;10,965;;
3200 Canon;15331;10,022;15498;9,858;-0,51;2247
3200 ML@0;15331;9,868;15498;9,867;;
3200 ML@-1;;;11635;10,366;;
6400 Canon;15331;9,280;15500;9,032;-0,53;4432
6400 ML@0;15333;9,040;15500;9,030;;
6400 ML@-1;;;11836;9,555;;
12800 Canon;15331;8,283;15502;8,030;-1,53;4432
12800 ML@0;15334;8,037;15502;8,017;;
12800 ML@-1;;;15500;9,003;;

27
General Development / Read metering directly (other than AE)?
« on: January 08, 2014, 08:34:55 AM »
Both my auto_iso module (in M mode for EC) and the autoexpo module work by calculating the Bv from reading the AE value.

Unfortunately, this doesn't seem to be immensely reliable, at least on my cameras (60d, 6d is even worse) the AE reading can overflow and also very often returns values completely off the scale, causing a metering lag since ML has to wait for a correct reading and potentially causing mis-exposure when the lighting changes quickly... currently I couldn't really recommend this mode for critical shooting, while auto_iso in Av/Tv naturally always falls back to a correct Canon exposure setting.

Pravdomil mentioned a potential possibility of directly reading the metering w/o the AE problems, is this an actual possibility? Sorry if this is a dupe, is there has been any further discussion on this I'd be grateful for a link to it.

28
General Development / Do have iso160-multiples have more dr & less noise?
« on: January 08, 2014, 06:25:58 AM »
The ML Wiki http://magiclantern.wikia.com/wiki/ISO says only the ML version of iso160 multiples have an advantage, while with Canon the raw file is the same.

I repeated this theory in the CR forum, and another poster wrote that this is wrong bases on DxO data - now I am really confused, is the wiki outdated and are at least newer cameras different even when shooting raw? Here's the discussion link w/ the diagrams:

http://www.canonrumors.com/forum/index.php?topic=18951.msg354527#msg354527

If iso100 multiples don't prove to be "best" after all, I'll modify the auto_iso module accordingly with an option to use iso160 multiples instead.

29
Feature Requests / Focus stacking with different dof on final shot?
« on: December 11, 2013, 09:27:26 AM »
This is a long-standing idea of mine, but I never came around to do it (yet):

When doing a focus stack, it could be useful to do the last shot behind the object with a wider aperture resulting in more background blur. You can then combine the stacked object with the blurred background in post, potentially resulting in a nicer result and keeping the number of frames down because you can use f8-f13 on your macro lens which would result in a less pleasant background w/o this modification.

I think it's easily implemented, just add a menu option with the requested "final" aperture, then add this difference to the shutter on the final shot, done. What do you think, does it make sense?

30
The "External Speedlite Control"->"Flash function settings" is basically just like the Q menu, but for many vital flash features - it's a really nice new menu vs. 60D and nearly vital if you don't own a big flash with its own lcd panel.

Problem is: This menu is tiresome to reach, and it cannot be pinned to "My Menu" directly. I would like to have this menu on the Q key, either as a replacement for the shooting menu or as double-click Q.

Question 1: The current way to do this (w/o scripting) would be to write a module that intercepts the Q key. Is there any way to get this flash menu on screen *directly* through a Canon api call, or do I have to simulate the long keychain MENU->R->R->D->D->SET->U->Up->SET ?

Question 2: If there's no direct way, how do I detect that the Canon menu is currently active, so that I know that I have to exit and re-enter it to make the keychain work?

31
Feature Requests / Extend Canon C modes by saving/restoring config data
« on: November 26, 2013, 06:07:24 PM »
I'm on a 6D with 2 C modes, and I still feel limited by it, Canon is very crafty as making this a distinction between cameras as the 5D3 as graced with 3 C modes...

... so here's a request for our pro ML hackers, I would have no idea how to do it:

Canon has to save all the setting data for their C modes *somewhere*, correct? If ML could find these data blocks, they could be saved and restored, resulting in an unlimited number of Cx "sets" to chose from for different situations. If this data is written if the camera is *not* in that particular C mode I see no danger from this approach (unlike the old ML mode switch), because modifying the actual camera settings is done by the Canon fw and if the data came from the camera, so it has to be valid.

Does this idea sound interesting? Any thoughts on how to find, save & restore these Cx mode setting data blocks?

32
Feature Requests / Read focal length outside LV and adjust expo accordingly
« on: November 20, 2013, 02:36:28 PM »
It seems the Canon fw can read the focal length and adjust the min. shutter speed in full auto mode, so there has to be a way to read this value somehow even if it hasn't been found yet ... this would be invaluable for example for the auto_iso module and so on which set a min. shutter speed in Av.

33
Feature Requests / Silent pics delayed trigger
« on: November 16, 2013, 03:56:29 PM »
This is one of Alex' own ideas, but I think it should be promoted to an official request to remind him once he's back :-) ...

... the idea is to continuously capture silent pics into the buffer, but *only* to save them after pressing halfshutter. This fixes the main problem with burst pics and fast action and the reason I don't use it for this - if the action starts, at least part of it be over once you managed to press the button.

The UI should show how much time at what fps is currently in the buffer so you can estimate when to save it - and/or there could be a menu option to save a fixed amount of xyz frames/time backlog after pressing halfshutter and from there on as much as the buffer holds.

34
The current display of 1/xyz shutter values or f/xyz aperture values in ML is not "correct" as it doesn't correspond to the Canon steps with 1/3ev and 1/2ev  exposure level increments, but is simply calculated by dividing the 8-step av/tv values.

This seems a bit strange and hackish (it's one of the first things I noticed when installing ml back than), and for display in the core and in modules (like autoexpo and auto_iso) there could be ...

* a fixed lens_format_shutter() with SYM_1_SLASH that adheres to Canon
* a new and correct lens_format_aperture() function with SYM_F_SLASH

I know this is not exactly essential, but if someone comes around to it, it would be very nice to have :-)

35
One question that has always been puzzling me: Why are the numerical values of Canon's shutter like this? We've got nice conversion macros now for APEX (thanks, pravdomil!) , but I don't understand the reason why Canon chose their values in the first place.

Code: [Select]
#define APEX_TV(raw) ((int)(raw) - 56)
#define APEX_SV(raw) ((int)(raw) - 32)







36
How do I add the code from a pull request to the main repo to my own repo fork (for example, if I want to try the adv_int module)?

All I can see is a possibility to get a diff for individual commits, but not for the whole pull request - and I am not able to divert a pull request via fork or compare to my own repo either.

37
General Development / Proposal: Continue boot on wrong autoexec.bin
« on: October 17, 2013, 10:28:36 PM »
Sorry if you feel bombarded with "this would be a good idea" threads, but here's another one that I feel should be addressed when using different models in parallel and swapping cards between cameras (yes-i-know-this-is-not-recommended, but large-gb-cards-do-not-grow-on-trees):

1. Make settings model-specific, for example by moving them to sub-directories. This esp. would prevent reading wrong props from the config file - the code is supposed to double-check this, but I wouldn't bet on it, esp. if I wrote it :-p so imho completely avoiding bricking would be safer. Also, the config file isn't really compatible anyway because different cameras use different features (or need different settings) - so why not simply separate the configs altogether?

2. Continue boot on incompatible autoexec.bin - this is a minor annoyance, but anyway: If I switch cards (I have different sizes) between 6d & 60d and a single-model autoexec.bin is on them, the cameras simply fail to boot. This not only gives me a near heart attack each time, but also prevents me using them in case even without ml. Would it be possible to simply continue booting the camera without ml instead of halting it?

Thanks for taking the time to evaluate these :-)

38
Since nightly is the new stable, it could be that new module pull requests are delayed if they aren't production quality. Imho this hinders testing & feedback, and that's what a trunk source code is for - not to provide daily updated production builds. To enhance the process, I propose two additions to the module's README.rst fields:

1. Code Quality: Staging or Production. This should go along with an option in the module debug section to load only modules that are production quality, so no development modules hamper a stable ml experience - on the other hand new modules could get merged faster since they are now marked as work in progress.

2. Model compatibility: Tested / Untested / Not working . Currently, modules are implicitly expected to work with all cameras. For some modules this is difficult or impossible to achieve, so these flags (like ::Compatibiltiy:: +60d +6d -100d -eosm) would help to filter modules. Rationale:

* Some modules won't work on some models at all, like dot_tune w/o camera afma - currently they only show horrible debug messages about some strange core functions not being found. The new flag would enable ml disable loading this module if it's known not to work.

* Newer models are sometimes quite different - I just painfully discovered this for button management and iso setting when moving from 60d->6d. So the modules' authors can only code for one or two platform, and hope for the best for the rest, if they are willing to make the effort to support all cameras at all. The new flag would make clear what camera the module is tested or intended for.

39
Feature Requests / Disable "Junkie mode" & quick access to Canon menu
« on: October 09, 2013, 02:51:23 PM »
The new "Junke Mode" is really nice and all, but I find myself never using it. Instead I suggest an option to get close the ml menu(s) and get to the Canon menu asap when pressing BGMT_MENU (menu.c), Q is already there to close submenus as well as open them.

I could submit a pull request for this, but only if there is a chance of getting this option merged, otherwise I'll just use it locally. Opinions, please?

40
General Development / Set information in the vf like ! - possible?
« on: October 08, 2013, 02:09:03 PM »
Are there any hooks at all to set information in the viewfinder, line the ! symbol next to the battery that the 6D has?

If so, it would be very useful for other purposes than Canon intended but as a signal from ml w/o needing to take the eye off the vf.

41
General Development / Please clean up core code warnings
« on: October 07, 2013, 07:06:10 PM »
This might be considered over the top by some(?), but it'd be nice if a dev could clean up the warnings the core ml code has when compiled with -Wall ... it's mostly -Wformat stuff that can be cleaned up with an explicit cast.

Yes, I could simply disable this warning, but if adding code to the ml core I want to see all warnings in case I break something - so if anyone volunteers who has write access to the repo and doesn't have to go through a lengthy pull process - go ahead :-)

42
If trying to do anything model-specific in a module, you need to know the camera model (or write a #ifdef branch in a core file). I added a simple function to do this...

https://bitbucket.org/Marsu42/ml-aiso/commits/2a3c70033184ebf9810f976462bfad55600f509e#chg-src/module-glue.c

... but word is camera_model_short would be better suited since it doesn't need to be extended: char camera_model_short[8] = CAMERA_MODEL; ... Now, here's are my problems:

1. I don't know the names that are returned, there has to be a list so the modules can check what for example the CONFIG_5D3 equivalent is for a module

2. I never really understood how to handle strings, please give a code sample how to funnel this information from a core getter function to a module, and how to check it there. Yes, sorry, I'm not a hardcore coder, but imho this functionality should be there for the modules.

I hope someone is willing to help with this, I just invested 2 days into re-writing auto_iso as a module and figuring out a quick non-gui way to switch it, despite that the Canon fw seems to be determined the prevent any reasonable idea ... but for the heavy stuff I need help from the real devs.

43
Feature Requests / [ALREADY DONE] Speed up cropmarks rendering?
« on: October 02, 2013, 12:38:56 PM »
I just have to ask again, sorry if it's been answered 1000x: Is there any way to speed up cropmarks rendering? With the current speed, it's too slow for me to use all the time, and esp. cycling through multiple composition overlays (thirds, golden cut, ...) takes ages.

Feel free to [WONTFIX] if this has gone into and there's no way to do it.

44
Problem: With the 6D, apart from multicontroller up/down (which cannot replace the 7d/5d joystick) you need to use *both* wheels to get to the af point you want to select. For me, both methods aren't very quick, I rather liked the 60D method with the wheel simply rotating through all available af points (it's only 11/9+1 after all), in practice this is quicker than using multiple buttons or wheels.

Suggestion: Forward-port the 60D selection method to the wheels (or any other method of selection that is quicker than the current 6d method, I'm open to suggestions :-)).

Edit: I solved it myself, at least partially, by enabling the af pattern point selection... single-wheel navigation is still to be done: https://bitbucket.org/Marsu42/ml-pull1/commits/2daffdce2c0354bdb94924069f047a59bd3309dc

45
Currently you can +1 rate by pressing the lv button (which I cannot get to work on the 6d outside lv, though 1% says it should). Anyway:

Problem: You can only +1 rate, for decreasing the rating you have to +5 rate by clicking 5x. Plus moving the finger from the back dial/multicontroller left/right to the lv button takes a little time which does accumulate if rating 1000+ shots.

Suggestion: In addition to lv button, rate +1 with multicontroller UP, rate -1 with DOWN

Edit: ok, ok, I've done it myself :-p ... https://bitbucket.org/hudson/magic-lantern/pull-request/245/rating-use-up-down-for/diff

46
Feature Requests / bracketing in m: tag files with +/- ev
« on: October 01, 2013, 12:37:11 PM »
Problem: When doing Canon or ML bracketing in M mode (like you're supposed to :-)), the files don't contain the ev spacing tag like Av/Tv files do ("AEB Bracket Value" in exiftool). This is a pity since this is very useful to display/sort hdr source images (like in Lightroom) or to use hdr software that use this value, if it's missing you have to specify it manually (like in Photomatrix).

Suggestion: Add an xmp sidecar to the cr2 that specifies the bracketing value used.

47
Feature Requests / dual_iso: Add min. ev gain (& min. delta ev gain)
« on: October 01, 2013, 12:12:49 PM »
I've written something like this before (sorry for the dupe) In the mega-thread, but here it's goes again as a dedicated feature request:

Problem: With the current "dumb" +/- ev options, you're quickly running into high iso values that don't make any sense, and specifiying absolute isos makes (to me) even less sense when shooting in changing light.

Suggestions (a few more advanced options for dual_iso won't matter :-p):

1. Add a "Min. EV gain" option ... if the ev gained drops below this, do a shot w/o dual_iso

2. Additionally add a "Min. EV delta" option ... if each of the higher iso values don't add more than this ev gain, use a lower iso value instead ... this will prevent dual_iso from choosing too high values that don't add any useful dr gain

Btw there was a declined pull request about somehting like this, and I agree hardcoding iso values is not the way to do it: https://bitbucket.org/hudson/magic-lantern/pull-request/229/dual-iso-fix-comments-limit-isos-on-7d-and/diff

Edit: deleted off-topic item about high iso differences help.

48
Feature Requests / dual_iso: base +/- ev option
« on: October 01, 2013, 12:04:12 PM »
I'm putting this into feature requests since I'm not such a big fan of mega threads and mixing discussion with requests:

Problem: With dual_iso being designed to lift shadows, using the original Canon metering doesn't make sense because in a high dr scene the metering will tend to the middle, i.e. clipping both blacks and whites. So with "just" turning on dual_iso you'll get blown highlights unless adding a - ec ... but that will underexpose "alternate frames only".

Suggestion: Add a "Base EC" option (like +/-1/2/3ev) that is only applied for dual_iso shots, thus you can quickly enable it and have "bracketing in one shot" for high dr scenes. The ec would modify aperture/shutter in the usual way just like bracketing does.


49
General Development / Button management core/modules
« on: September 28, 2013, 10:17:56 AM »
Well, I'm not much of a C coder, but I can offer some ideas - "Those who can't do, teach", you know :-p ...

Problem: With more features and modules, assignment of buttons to functions gets confusing. I'm currently writing a hotkey module for use outside lv, but keeping up do date in which situations another functions for example does something with SET is a pita.

Currently: Currently modules have CBR_KEYPRESS, and then, nobody knows what keys they intercept or what they do with them - in the core it's even worse, you can hook into the shoot task everywhere and use keys.

Suggestion: Modules (and also the core itsself, for that matter) should explicitly register keys with the core as either blocking (only they want to tie a function to it) or non-blocking (everybody else also can afterwards). For blocking functions, the core could then issue an "ok, nobody else is using it" return code or fail with a hint which other function was quicker - so if the user cannot use function 1 which wants to use SET, he/she knows what to disable. Also the "register" function should have a "override Canon" switch for taking away buttons from Canon like SET. The core could also then easily print a list of keys that do something with ml in a help menu.

What do you think - is this useful or overengineering (and anybody else wondering what his SET currently does - Canon function, ettr, af, ...)? Anybody with good C coding ability volunteering :-p ?

50
I think the values for shutter/apertrue/iso around the code, even if sometimes ammended with a comment, are hard to read and prone to error. I suggest replacing them with #define - there are not *that* much values after all, and if they are buried in some .h file they won't get in the way while the code will get easier to read... comments on this idea?

Edit: Also, instead of adding a numerical 8 it should be RAW_FULL_STOP or something like this... this would change this line from auto_iso

Code: [Select]
int ref_tv = 88 + 8*(aiso_av_shutter-1);

into this:

Code: [Select]
int ref_tv = RAW_SHUTTER_30S + RAW_FULL_STOP*(aiso_av_shutter-1);

Pages: 1 [2] 3 4 ... 7