FYI, the workarounds for the green cast (aka wrong black level) bug are very well known to those used to read sticky topics
http://www.magiclantern.fm/forum/index.php?topic=11664.0http://www.magiclantern.fm/forum/index.php?topic=11942.0Now, why does it happen at low bit depths?
My best guess is that our raw backend sometimes decides to compute the black level at the same time with the bit depth switch. There are some sanity checks to avoid computing the black level from an invalid image, but they are not 100% effective. Disabling them should increase the probability of encountering this bug.
The only other tasks (besides raw recording) that could trigger a refresh on the raw parameters under normal usage are the raw overlays, so you now know what to disable until this issue is fixed.
The fix would be in the raw backend: bit depth changes should be done in raw.c and guarded by raw_sem, and lower bit depths should be handled differently. Some possibilities (not yet sure what to choose):
* disable all raw processing (e.g. overlays) at lower bit depths
+ minimal amount of coding
- no overlays while recording at lower bit depths (including grayscale previews and so on)
* perform all raw processing on 16-bit buffers, as in raw_twk:
+ fast (all raw processing will be faster)
- may requires custom memory management for raw buffers, as Canon code reserves memory for a 14-bit buffer
- will overflow outside LiveView, as we cannot allocate a continuous block larger than a 14-bit full res picture
- on the fly conversion to 16-bit could work, but gives additional complexity
* convert lower bit depths to 14-bit, with raw_twk code:
+ would reuse current 14-bit code
- no speed gains from raw_twk
* create the low bit depth image from the main 14-bit raw buffer, instead of edmac_copy_rectangle
+ would reuse current 14-bit code
+ a similar code structure would also work for lossless compression
- no speed gains from raw_twk
* variations of the above
I don't know how to read those logs but my guess is that it looks like you're low on memory.
Free Memory : 144K + 3569KFree Memory : 135K + 3562K
From mem.c, look for "malloc" and "AllocateMemory" at preferred_free_space. The above is not a low memory condition; quite the opposite. Some background info
here.
Looks like you're loading way too many modules. Try loading just the one's you're testing first.
This advice is perfectly valid; not just for memory reasons, but also for other kinds of code interactions. For example, a module might start its own tasks, and those are a scarce resource on certain cameras. Also, raw_rec and mlv_rec are known to conflict with each other on functions exported to other modules.
I'm thinking to place a warning on the Modules tab, to be displayed if you load too many modules. They are not meant to be loaded all at once.
