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.

Messages - mucher

Pages: [1] 2 3
Camera-specific discussion / Re: Canon 7D
« on: October 03, 2014, 08:45:48 AM »
I haven't been following for a while, so it might be a huge task to follow up. May someone spare a second to kindly tell me if that 1/3 stop reduction in highlight register trick in 7D been solved (I forgot what it was called)?

Oh,  correct. I found it here:
EXPO_ISO_DIGIC is called, isn't it? Unsolved.

I remember that g3gg0 once mentioned that you can import all the dng/cdng sequences into AE, then save AE project, then import the AE project into Premiere. It works for me, thanks, but I am not much a user.

BTW, MLviewer couldn't convert to dng in my PC

Modules Development / Re: Full-resolution silent pictures
« on: July 26, 2014, 05:38:25 AM »
Curiously enough to ask if that means that we will not need to press 5X button to go into full pixel mode RAW recording in the future?

If somebody "accidentally" finds how to port these raws through that jpg pipeline...and, combining with that 1/3 stop highlight reduction, and... wrap it with sound into MLV format...I have dropped down in bed to think more about it. Ciao ;)

If you want to continue the port:
The compiled autoexec.bin freezes on the camera.

Too bad to hear that, I really wish that I could work on codes, but I don't think that I have possessed enough skills to be able to do that, so my fingers are crossed.

I remember that, several months ago, one of the contributors posted some codes for 7D 2.0.5 in 7D RAW thread, it might need a simple recompilation, but the post sank very deep later.

Archived porting threads / Re: Magic Lantern for 7D alpha 2
« on: November 26, 2013, 12:27:16 PM »
The several times that I have test shot with ML raw video shows that ML raw recording is quite savy on battery, a fully charged battery can last pretty long time (say an afternoon plus). That is unexpected because I have piles of batteries in stock (some were prepared for the flashgun).

Btw, anyone knows how to get CHDK working on 7D? I have some quite slow old cards lying around, and I am contemplating shooting dng instead which is directly stolen from some buffer inside the 7D, for I don't trust Canon for its CR2 very much.

Though quite some people say that it is changing sensor, but I don't believe it very much. Changing a 5D sensor costs around $1000, changing a rare species like C100's sensor changes for $500 dollars? I would say no way.

General Chat / Re: New 1DX firmware adds a few ML features
« on: October 24, 2013, 12:37:28 AM »
The 1dx owners don't know what they're missing, ml already has expo lock, the stable 2.3 ml or the auto_iso module have unlimited min. shutter speed in av (and aperture in tv), the module also has ec on m :-)

I didn't know that, for I used to only use the module. Start willing to try already. Wish somebody will tell me that if there is anyway that I can start ML without flashing the camera's firmware.

General Chat / Re: New 1DX firmware adds a few ML features
« on: October 23, 2013, 05:32:42 AM »
These 3 features look nice, wish they can come down to 7D

Archived porting threads / Re: Magic Lantern for 7D alpha 2
« on: September 30, 2013, 03:31:40 PM »
The latest Britom's build is quite stable to me, test shooting raw one afternoon, no ERR encountered. Cannot remember any significant issues, but the write speed varies a lot.

General Development Discussion / Re: [7D] Broken EXFAT + booton/bootoff fir?
« on: September 22, 2013, 02:07:12 AM »
Good luck, then 8)

General Development Discussion / Re: [7D] Broken EXFAT + booton/bootoff fir?
« on: September 21, 2013, 06:56:50 PM »
I know nothing about the DryOS, but the Linux built-in the file systems into its kernel or build it as a module, and my wildest guess is that the DryOS is also like this, so to mount it, I blindly believe, you need to add the module to the kernel first.  8)

Raw Video / Re: How long is the raw video that I filmed in Magic Lantern?
« on: September 09, 2013, 07:25:00 AM »
14-16mins, but your camera is probably getting overheated first.

General Development Discussion / Re: Non-realtime raw video compression
« on: September 04, 2013, 06:21:42 PM »
The Digic4 sounds like a 80086(that is Intel's processor before 286) without a floating-point co-processor.

When C100 becomes C500, all I can imagine is hearing some 4 letter words from Canon...... ;D

The power management thread seemingly keeps tremendous amount of CPU cycle to itself. There might be some ways to stop the power saving thread while running ML tasks, because the camera is running tasks, no point to do power saving.

Modules Development / Re: Magic Lantern (RAW) Video format v2.0
« on: August 15, 2013, 03:59:51 PM »
I think their Q/DQ methods tie up the CPU too much, these tasks are really slow to complete, and on a slow cpu the things get even worse. There might be ways to free up the CPU from these seeking jobs to let it do what CPU is supposed to do -- like compressing files. I still sturbbonly believe that the DIGIC4 is fast enough to do something like /4 an interger. :D

Modules Development / Re: Magic Lantern (RAW) Video format v2.0
« on: August 12, 2013, 07:47:59 PM »
I have got the feeling that the SD speed looks a bit low.

Modules Development / Re: Magic Lantern (RAW) Video format v2.0
« on: August 04, 2013, 03:36:08 PM »
two buffers wont give us any improvement imho.
to be correct, we already have n buffers, where n is up to 70 or so on 5D3.
and these buffers get assigned dynamically to CF or SD.

i know we can do another improvement.
right now i am playing with two buffering methods on both queueing and dequeueing.

some problem that is making it hard to get optimal results, is the non-censecutiveness of memory buffers.
we can allocate e.g. memory for 70 frames. but this memory is fragmented, it it not continuous.
this means we have some groups of 2, 8, 20 or any other number of frames (we call it slots btw) that are continuous.
but the best for writing speed is to write a consecutive block of nearly 32MiB at once.

buffer layout e.g.: [____] [__] [_____________] [________] [__]

method a) pick the first available free buffer
this method walks through the list of slots and checks for a free one.
it does not care if the previous or next buffers are directly behind the free one.

method b) use alex' algorithm that tries to place frames so that we get the largest block with frames in order.
this was necessary for the old writer where the frames had to be in order

better method:
search for the largest free space and try to fill it up.
strategy behind: build the largest block with frames in any order so that we get highest transfer speed

buffer layout e.g.: [____] [__] [______x1234x___] [________] [__]
the fifth frame would get enqueued at x, even if there is a lot of other free space

method a) there are two writer threads (CF and SD) that are listening on a queue.
dispatcher thread scans the buffers for the largest consecutive block and places a write job into the queue.
the next "free" thread receives this job and writes it, no matter if SD or CF.

method b) again two threads, but every thread has its own queue.
the dispatcher places the largest found block in the queue for CF, the faster device, and the smallest block in the queue for SD.
strategy: try to keep the CF thread busy with the largest blocks to achieve the highest write rate. SD doesnt suffer that much
from writing smaller blocks. (remember, ~32MiB writes give the fastest possible transfer rate. on SD the speed difference isnt that high with smaller blocks)

i think mehtod b) gives the best results.

but to get back to your idea. one possible improvement could be this:
make the dispatcher aware that it should only qeueue writes to SD from large blocks, if there is nothing else.
background: we dont want the slow SD to permanently disturb the queueing by building large blocks.

[____] [12] [3________] [________] [__]

in this case the SD algorithm will pick frame 3.
this could lead to such fragmentation:
[____] [12] [_____789_] [________] [__]

but CF would benefit from writing large blocks so SD would probably be just annoying.

so i am thinking of building a sorted list of buffers and their sizes.
SD will always try to clear the smallest buffer areas, where CF tries to clear the larger ones.

There should be an arbitration system between CF write thread and SD write thread, I guess, and, possibly, a powerful one.

A sorting list should be a good idea. My wild thought is that it might be good to keep a list of RAW file's address, and let the CF/SD write threads to sort according the list. The question is how much RAW files they can fetch each time by each of them -- then there is a need of arbitration system.

Archived porting threads / Re: Magic Lantern for 7D alpha 2
« on: August 04, 2013, 11:42:56 AM »
I did some quick tests in my garden with silent pics burst this afternoon. ;)

The SilentPic Mode is beautiful, knocking H.264 out, but only it stops after 1-2 seconds, I really hope to get the jpg output from LV back as the Alpha2 used to do, but couldn't find the setting everywhere I looked. May somebody show me the way?

Modules Development / Re: Magic Lantern (RAW) Video format v2.0
« on: August 04, 2013, 10:26:32 AM »
i am wondering that it might be faster to create two different buffers for the twoslots or even two buffers to write to the same slot. just a mere thought on the write speed

General Chat / Re: CompactFlash to SSD adapter for 5DM3 or 5DM2
« on: July 29, 2013, 11:54:20 AM »
Comparing with SSD, CF card prices are ridiculously high, can I understand that CF cards are more difficult or more expensive to produce?

Archived porting threads / Re: Magic Lantern for 7D alpha 2
« on: July 28, 2013, 08:44:24 AM »
britom, thanks. I finally got it loaded.

arrinkiiii, thanks for solving the red light blinking issue.

Unable to boot twice, solved the issue easily by pulling the battery out, probably because I hot-pulled the CF card.

But the Qscale factor shrinks to -8 (used to be -16 plus GOP1), or it will stop recording in several seconds. Still unable to save that "Video Hack" option. But it is good enough for now.

Thanks again. G3gg0, Audionut, Pelican, britom, arrinkiiii, ...

Archived porting threads / Re: Magic Lantern for 7D alpha 2
« on: July 26, 2013, 10:32:00 AM »
I have no luck with Audionut's latest build @reply 721 neither.

Archived porting threads / Re: Magic Lantern for 7D alpha 2
« on: July 25, 2013, 04:58:45 AM »
I guess that I am one of those "luna"s.  I load Audionut's autoexec.bin with Alpha 2 into 7D, nothing happens. I mean really nothing, the ML didn't load into camera. I download everything in Audionut's 7D build directory and put them all in CF card's root directory. And start up the camera again. Nothing happens, again. I don't visually see that my camera is damaged neither.

Pages: [1] 2 3