Here's a (more or less) stable build which has this. To use it, press
Q on the silent picture option in ML menu, and then SET/DISP to adjust
the resolution.
How it works:
- It will take a matrix of small silent pics, in zoom x5 mode.
- All those pics are saved in the same 422 file
- You need to have the camera on a tripod and the scene should be
almost stationary (a pic is taken in a few seconds).
- Works with intervalometer and HDR bracketing modes.
- 422-jpg.py from this zip is able to decode them (and works
much faster on regular 422 files).
- 422-jpg.exe (6 MB) is here:
https://bitbucket.org/hudson/magic-lantern/downloads/422-jpg.exe
There may be some cache problems, so if you get the old file, try
another browser.
Other fixes in this build:
- HDMI support is a bit better (see "Ext monitor fix" thread for details)
- When you change a setting from Expo menu in LiveView, all the other
settings will disappear from the screen temporarily.
- Some minor stuff here and there (like spotmeter moved in the center,
silent pics working in almost all modes...)
New link for 422-jpg, without caching issues:
https://bitbucket.org/hudson/magic-lantern/downloads/422-jpg-v2.exe
On Fri, Jan 21, 2011 at 11:38 PM, JaKoB <jako...@gmail.com> wrote:
> everything works real nice but when the HDMI is plugin the Camera locksup
>
> --
> http://magiclantern.wikia.com/
>
> To post to this group, send email to ml-d...@googlegroups.com
> To unsubscribe from this group, send email to
> ml-devel+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/ml-devel?hl=en
na its not working its giving me error 80
--
Sorry... my trying to moving histogram to the right crashed the HDMI
mode. Fixed now.
(something like this: http://people.rit.edu/andpph/text-slit-scan.html )
This is implemented as a third mode of silent pictures. Default
setting should be a good start.
With this, I also have some interesting findings about the video buffers:
- The two buffers we are using are refreshed at 12.5 fps.
- There is a variable which changes at 25fps, regardless of selected
video mode (not sure if it changes with pal/ntsc) at 0x1e24c (found
with mem-spy).
- A loop with msleep(1) will get 100fps.
- To test the refresh rate of a variable, call test_fps from zebra.c
and uncomment the FPS display.
So, one of these is true:
- The buffers we've found are not used for recording, nor for screen display
- test_fps is buggy
And also:
- There's no visual improvement in trying to optimize zebra and focus
peaking (this means they won't be any faster); instead, it will be
better to slow down the zebra in order to save battery power.
- There may be buffers which are refreshed which higher frequency.
That could be a good hypothesis.
> "The buffers we've found are not used for recording" Did you try and write
> data into the (uncached address) of the screen segment and see if it is
> recorded?
No. But even at 50fps, the buffers are still refreshing at 12.5fps.
Maybe they have 4 buffers in this mode?!
{0x04000080, 0x0415407C,1360, 2048, 3744}, // seg 1
{0x10000080, 0x1015407C,1360, 2048, 3744}, // seg 2
{0x24000080, 0x2414FFFC,1335, 2048, 3744}, // seg 8
{0x34000080, 0x3415407C,1328, 2048, 3744}, // seg 10
So the conclusion is that my logic is buggy :)
LiveView buffer (the small one) is updated at 30fps and has 3 banks
(each one updated at 10fps). A pointer to this buffer is at 0x246c
(updated at 30fps).
HD VRAM (the bigger one) is updated at 25 or 30fps (depending on
PAL/NTSC setting) and has 2 banks (each one updated at 12.5 or 15fps).