[ML] 5D2 Overlay & Focus

9821 views
Skip to first unread message

Antony Newman

unread,
Dec 12, 2010, 7:38:36 PM12/12/10
to Magic Lantern firmware development
Here's a quick video of some ongoing 5D2 experimentation.

http://www.youtube.com/watch?v=kMMWeouFqsA

Regards,
Antony

Antony Newman

unread,
Jan 3, 2011, 4:36:57 AM1/3/11
to Magic Lantern firmware development
Here's a quick update on the 'Focus Assist' function.

http://www.youtube.com/watch?v=-nW25AtYjAk

AJ.


James Donnelly

unread,
Jan 3, 2011, 6:04:51 AM1/3/11
to ml-d...@googlegroups.com
Personally I think this is one of THE killer features made possible by ML, so thanks for making it happen, looks really good.

Is it going to be possible to modify the zoom factor of the focus assist overlay independently of adjusting its size?

Is there much more work needed to get this committed to ML?  I would love to start playing with the code to learn from it.




--
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

Antony Newman

unread,
Jan 3, 2011, 5:03:27 PM1/3/11
to ml-d...@googlegroups.com
Hi James,

The Overlay (currently) displays a 1 : 1 image from he the hd_vram buffer to the Overlay memory used by LCD or HDMI.
The zoom is therefore dependent on the number of pixels in the hd_ram (vs the display device overlay pixel size).

Input: hd_vram - x res
==================
Not_Recording (x1) 1024 pixels
Not_Recording (x5) 1120 pixels
Not_Recording (x10) 1120 pixels
Recording 1872 pixels

Currently, the centre of the Overlay disc in hd_vram(x,y) is recalculated whenever the resolution changes - so it should stay in the same place even when record in pressed.

I did initially play with huge pieces of asm to do zoom - but I kept running out of memory compiling the code (although now I've removed the 'huge' font ... and so there would have been space to keep it in).  Zooming beyond the 1:1 display doesn't help you focus .. and so I don't think its worth putting back in.  

How does it work
===============
I started with ML;  Commented out all code that does screen update (that I couldn't switch off).
ML periodically calls my code, which then handles Vector Cropmark, Icons, Zebra & Overlay (about 4000 lines of C & assembler).

ML Compatibility
==============
Edge Detection: I removed it from my code as, even when I emulated the Marshal monitor red tinting it didn't help you focus any better.

Histogram or Waveform: I haven't coded. If you have Zebras .. do you need these? ML does its screen updates differently.  Either (1) ML could plots these where my code was not drawing, or (2) my code could be altered to have a cutout for ML to plot, or (3) I was convinced these are required, and write some asm to work these out/plot at the bottom of the screen (or maybe the unused sides when in HDMI mode)

Audio meters: If Vector cropmark is set below line 33 - these can work exactly as they are.  My feeling is that this icon could be relocated to the bottom of the screen (in a compressed form), so that all the available vram picture under the Over can be seen (helps you see what's about to come on screen / may help you focus).

AJ

Moira O'Brien LIPF

unread,
Jan 3, 2011, 7:45:03 PM1/3/11
to ml-d...@googlegroups.com
Fantastic work AJ - I understand now where your questions came from.

Personally I find that the histogram is more valuable than zebras (which I find distracting when filming).  I would be more than happy to see the audio meters relocated to the bottom of the screen.  It would mean sacrificing the Canon Info display which I do sometime use as it is easier for my (ageing) eyes to read than the ML onme - but I can live with that.

I will be happy to test this out when you are ready to share it.

with kind regards

Moira

Moira O'Brien LIPF



AJ

Antony Newman

unread,
Jan 4, 2011, 12:54:40 AM1/4/11
to ml-d...@googlegroups.com
Hi Moira,

I don't have much experience of which Canon menus are actual used (ie active) when recording. 

Could you send me a photo of the back of your 5D when in use. 

I'll set my camera to the same, and (try) and get my display information in empty space (if there is any)

Thanks for the offer of testing.

AJ

Jason Carrier

unread,
Jan 4, 2011, 4:38:46 AM1/4/11
to ml-d...@googlegroups.com
it would be nice to have the audio meters turn on and off with a button, and i dont know if this has been implemented yet since i cant yet use ML (60d) but it would be nice to have the option to control audio gain while recording



AJ

--

Thomas Berndt

unread,
Jan 4, 2011, 11:31:39 AM1/4/11
to ml-d...@googlegroups.com

Hello AJ,

 

Good Job! That was actually the functionality I was waiting for all the time! If your code is ready for some serious testing let me know! :-)

 

Again! Good Job and keep up the good work!

Cheers!

Thomas

Antony Newman

unread,
Jan 4, 2011, 12:47:28 PM1/4/11
to ml-d...@googlegroups.com

"Personally I find that the histogram is more valuable than zebras (which I find distracting when filming).  I would be more than happy to see the audio meters relocated to the bottom of the screen.  It would mean sacrificing the Canon Info display which I do sometime use as it is easier for my (ageing) eyes to read than the ML onme - but I can live with that."  [Moira]


Moira.  I had a quick think today about your email.

Here's what is currently happens:

+) The Zebras that I have in the Overlay & Zebra code are drawn inside the Cropmarked area, and not on the Overlay
+) I've changed the Peak level up from 240 to 255 (255 being the maximum).  This means it only shows 'Red' hatch when you really have peaked (ie not all the time).
+) I've changed the Low level up down from 10 to 2 (0 being the minimum).  This means it only shows 'Blue' hatch when you really have peaked (ie not all the time).
+) I found the size of the ML zebras checkers too large. (8 x 8) pixels.  When you panned the camera, the pattern would looks like it Jumps (didn't like that). Secondly, lack of detail - just a blob.   I've used 4x4 - which (in my opinion) looks fine.
+) I have a option that reduces Zebras impact (draw every other line).  They both look good - Not sure which people would prefer.


Next : Histogram.

If you think this is useful - I will write one.    As this requires a large amount of data to process - audio meters (the icing on the cake) can wait.   Do you mind if we start of scratch an we decide the best interface that has the least CPU overhead?

Q1) What are you actually looking for when you look at the histograms?  That all the picture information is not Too Bright or Too Dim?

Q2) Rather than details information on the number of pixels on the screen that are an exact Brightness level... could we break this down into ranges? ( Eg   0-15.  16-31 ....... 240-255).  The exact levels in each range could be decided up front.   If Yes - I can start coding this - I just need to know the minimum number of ranges that we need.   (in cause you are wondering, I want to store all the level counts in CPU 'registers' which means I don't have to write to memory = works like lighting)

Q3) Display of data. Horizontal?  Vertical?  Colour?  Can we design exactly what is needed.  Where would you want this (hopefully on the bottom of the screen!)

AJ

Antony Newman

unread,
Jan 4, 2011, 1:24:17 PM1/4/11
to ml-d...@googlegroups.com
"it would be nice to have the audio meters turn on and off with a button, and i dont know if this has been implemented yet since i cant yet use ML (60d) but it would be nice to have the option to control audio gain while recordin"  [Jason]

Jason,  I know next to nothing about the ML menu's .. I'll leave this to the ML gurus.

I had originally used the 5D2 Dial to make the Overlay rotate clockwise / anticlockwise .... only to discover that the DryOs also uses it to control functions when recording (ahhh).  And so I removed that method of taking key input.

5D2 Buttons in use

[Play] is used to rotate the position of the overlay 90 degrees (only to be used when recording right now as LiveView uses play .. and the DryOs changes the location of the HighDef videoram buffer ... and I haven't worked out where it moved too).

[Trashcan] Activate / deactivate Zebra & Overlay (also clears screen)

[Joy Up/down/right/left/+any digonal] Move the origin of the data uses in the overlay (ie within hd vram)

[Magnify -] Cycle through size of Overlay (small, medium, fullscreen).   The first two are just circles, the last one stretches into an ellipse that uses most of the screen.




REMOTE CONTROL
I think the ideal solution would be for at least one button to be remotely controllable (eg on / off) .. or ideally all of them.
I guess we need someone interested enough to want to develop one.

Using this gadget that TH mentioned in an earlier email would be fab!
http://www.viewfactor.net/index.php/products/impero.html

AJ

Moira O'Brien LIPF

unread,
Jan 4, 2011, 1:56:26 PM1/4/11
to ml-d...@googlegroups.com
On 4 January 2011 17:47, Antony Newman <antony...@gmail.com> wrote:

"Personally I find that the histogram is more valuable than zebras (which I find distracting when filming).  I would be more than happy to see the audio meters relocated to the bottom of the screen.  It would mean sacrificing the Canon Info display which I do sometime use as it is easier for my (ageing) eyes to read than the ML one - but I can live with that."  [Moira]


Moira.  I had a quick think today about your email.

Here's what is currently happens:

+) The Zebras that I have in the Overlay & Zebra code are drawn inside the Cropmarked area, and not on the Overlay
+) I've changed the Peak level up from 240 to 255 (255 being the maximum).  This means it only shows 'Red' hatch when you really have peaked (ie not all the time).

Agreed
 
+) I've changed the Low level up down from 10 to 2 (0 being the minimum).  This means it only shows 'Blue' hatch when you really have peaked (ie not all the time).

Agreed
 
+) I found the size of the ML zebras checkers too large. (8 x 8) pixels.  When you panned the camera, the pattern would looks like it Jumps (didn't like that). Secondly, lack of detail - just a blob.   I've used 4x4 - which (in my opinion) looks fine.

This sounds a lot better than Trammel's version.  I look forward to seeing this.  The existing ML only has over exposure peaking, no under exposure.  Depending upon how well this works it might be a good alternative to histogram.
 
+) I have a option that reduces Zebras impact (draw every other line).  They both look good - Not sure which people would prefer.

Will be interested in seeing this and the effect on the display.
 
Could you do a quick video to demonstrate these developments?


Next : Histogram.

If you think this is useful - I will write one.    As this requires a large amount of data to process - audio meters (the icing on the cake) can wait.   Do you mind if we start of scratch an we decide the best interface that has the least CPU overhead?

I don't mind at all starting from scratch.  If you can make it more memory efficient then so much the better.  However, I don't consider audio meters to be the icing on the cake - for me they are probably the most important feature and I will trade them for the histogram (especially if your enhanced zebras work well).
 

Q1) What are you actually looking for when you look at the histograms?  That all the picture information is not Too Bright or Too Dim?

I am looking at the overall distribution of pixels to find the optimum curve with the midtones being the highest level and no clipping on the whites or the blacks.  In essence I am looking for the MAXIMUM pixel information to be recorded. See the attached photo which has a reasonable distribution with only a small amount of over peaking (as you can see from the zebras).  Note that the existing histogram has a lowered opacity on the background - only the whites are displayed at full opacity..
 

Q2) Rather than detailed information on the number of pixels on the screen that are an exact Brightness level... could we break this down into ranges? ( Eg   0-15.  16-31 ....... 240-255).  The exact levels in each range could be decided up front.   If Yes - I can start coding this - I just need to know the minimum number of ranges that we need.   (in cause you are wondering, I want to store all the level counts in CPU 'registers' which means I don't have to write to memory = works like lighting)

This is an interesting idea and worth trying out.  I would say that steps of 10 would give sufficient information.  15 may be too large a step. 

Q3) Display of data. Horizontal?  Vertical?  Colour?  Can we design exactly what is needed.  Where would you want this (hopefully on the bottom of the screen!)

Position - if we can keep the background opacity low, then the current position is fine. The bottom of the screen is going to get very congested as that seems to be your preferred position for the audio meters. I will be happy to chat off list to go into more detail on design etc.  My phone no is after my signature. 

I would be interested in hearing other users comments on this email, especially on the relative importance of the three facilities ie:

Zebras
Histogram
Audio Meters

Moira
+353 876 214532

Photo1.jpg

M.v.M.

unread,
Jan 4, 2011, 2:36:00 PM1/4/11
to ml-d...@googlegroups.com
  Matthias von Mutius here..
Zebras are very useful when doing run and gun stuff, not hitting 100% white is essential and must be when done really  done with a purpose, So Over is needed and will probably not be seen very much :-) but when seen corrected. Under-Zebras are not used in broadcast cameras, why ? Well black is black is black....
Smaller checkers are always welcome as long as they are still visible as zebra...

Histograms: very useful to check your gamma, when most stuff is in the middle you know you are okay.. For a useful histogram lets have more info on high and low  values for example: 0-5 6-12 13-25 26-50 51-90 91-145  146-200 201- 219 220- 242 243-249 250-255, This will show more important regions more detailed, maybe the values can be better visible if the display is showing an exaggerated profile, like setting the highest existing group to 100% and adjusting the rest accordingly ? so we could see at one glance what kind of look (low-key-high-key) we will get.   

Thanks for reading Matthias

"Antony Newman" <antony...@gmail.com> schrieb:
--

Moira O'Brien LIPF

unread,
Jan 4, 2011, 2:48:04 PM1/4/11
to ml-d...@googlegroups.com
Sorry for slightly disagreeing with you Matthias but coming from a stills photography background I am always looking for detail in both then highlights and the blacks - so, while I agree that black is black, I do want to know how much of the image is completely black.

Moira

Alex

unread,
Jan 4, 2011, 2:49:46 PM1/4/11
to ml-d...@googlegroups.com
My 550D clips low light levels to pure black in video mode, that's why
I've put lower zebra threshold at 10. And this happens indoors at
normal lighting levels imo (iso 800 @ f5.6), not candlelight...

Shooting the same stuff at iso 1600 came out perfect.

For histogram, I think 10 bins or so are sufficient.

Antony Newman

unread,
Jan 4, 2011, 3:27:25 PM1/4/11
to ml-d...@googlegroups.com
Moira,

Thanks for the photo!



"I don't mind at all starting from scratch.  If you can make it more memory efficient then so much the better.  However, I don't consider audio meters to be the icing on the cake - for me they are probably the most important feature and I will trade them for the histogram (especially if your enhanced zebras work well)."

ML Existing
In ML, when you want the Histogram, you also activate the preparation of data for the waveform. 
The waveform is stored in a matrix that is 360x256 (x4 bytes) = 360 KBytes  (That's quite a chunk of memory to cleared & filled)
The Histogram is 128 bins (x4 bytes)   (updated for every pixel .. that a lot of IO)

AJ 15 bins x 10bits
My 'not-quite-worked-out' solution is to store everything that we need in 20 Bytes.
The routine will process entire lines of vram, and accumulate the all the 'bins' values with 5 registers (1reg = 4Bytes).

If there's a maximum of 720 pixel per std_vram line .. you need 10 bits to describe that bin.
5 regs x 32bits/10bits = 15 bins. 

This could mean the bins are only written at the end of each line (probably around 100 times faster).

AJ


== I was going to delete this part of the email - you can ignore it ==

AJ
more bins - tricky
Slightly more 'tricky' assembler required here to empty bins when they get full.
Lets say 6 bits allowed per bin.   It can 'count' up to 63 times occurrences of brightnesses in its band before having to update memory (and zero its counter).  This would mean that a memory update would be required every 64 pixels (ish).

6bits = 5 bins per Register.    5 bins x 5 regs = 25 bins.

AJ Even More bins - more tricky
I could squeeze another 3 bins in 10bit mode.   18 bins!   (who thought bins could be so exciting?)
And if I was very daring .. another 2 bins. 20 bins!  That would make the gap around 13.   0..12,   13..25...
The issue with more complex code is that there are diminished returns .. ie it will not run like lightning!










M.v.M.

unread,
Jan 4, 2011, 3:53:00 PM1/4/11
to ml-d...@googlegroups.com
Well Moira, thats what I use the histogram for while checking my exposure, basically before pressing REC. When the conditions start to change I mostly fear loosing the highlights, because blown out whites are ugly and there is no way to fix in post, so when the zebra shows up I know this scene is lost. I need to find a new angle as a cutaway or start all over again. Example: my world is documentary work, somebody tells you his story, suddenly the sun comes out behind clouds or a door is opened etc. blown out whites are for a short moment happening. What is going on when suddenly the scene is darkening ? It is mostly usable if your audience can understand why everything is getting darker NOW. You may need a cutaway to the clouds as well but not as quick and not before the change happens because the scene is still mostly usable, and can even be corrected to some extend in post. 
 And finally I see mostly always some parts in a scene that are black, the telephone line in the sky, the black in street signs and very often dark shadows on sunny days. I know and I see them as black on the screen of the camera as does my naked  eye. This is the way our seeing works, we naturally and automatically always expose for the high-lights and accept blacks in real life as existing..  

 And filming is always just mimicking natural vision behaviour..

Thanks for reading Matthias


"Moira O'Brien LIPF" <mo...@moiraobrien.com> schrieb:

Ba...@aol.com

unread,
Jan 4, 2011, 4:31:11 PM1/4/11
to ml-d...@googlegroups.com
It may not be actually clipping.   One thing we learned from  CIneform is that the image coming out of the camera has more details in the highs and lows than we are seeing in the raw file footage. 
 
In a message dated 1/4/2011 11:50:17 A.M. Pacific Standard Time, broscu...@gmail.com writes:
My 550D clips low light levels to pure black in video mode, that's why
I've put lower zebra threshold at 10. And this happens indoors at
normal lighting levels imo (iso 800 @ f5.6), not candlelight...

Shooting the same stuff at iso 1600 came out perfect.

For histogram, I think 10 bins or so are sufficient.

Piers

unread,
Jan 4, 2011, 6:51:41 PM1/4/11
to ml-d...@googlegroups.com
I'm curious whether anyone's seen this in practice: I have an AVCHD Lite camera that comes into FCP always clipped, and only by running it all thru Color can I get my blacks back. Canon (550D in my case) I haven't had to do that.

I'm not saying that the head/bottom room isn't there, but I haven't had to delve into it.

PG

Chris Barcellos

unread,
Jan 4, 2011, 8:58:03 PM1/4/11
to Magic Lantern firmware development
Here is a discussion of the known issue, and solutions:

http://www.dvinfo.net/forum/canon-eos-5d-mk-ii-hd/140690-5d-mk-ii-crush-black-issue.html

Piers

unread,
Jan 4, 2011, 9:39:36 PM1/4/11
to ml-d...@googlegroups.com
We're getting OT, I guess, but those are from a year ago. I haven't really seen this on my 550 - just wondering if I'm lucky, or the 550D's different, or we have some change in QuickTime or FCP (or L&T) to deal better with this?

Antony Newman

unread,
Jan 5, 2011, 3:26:46 AM1/5/11
to ml-d...@googlegroups.com
Thankyou all for the insights into this.

+) I note that in ML it averages two pixels intensities.  Does this matter / not really?

I currently scribbling asm ideas down on post-it notes - and have arrived at (what I think is) two solutions

Solution - 1 - Register resident

There would be 21 levels ranges
+) [0] by itself (it won't be counted, in the asm, but will be worked out at the end as total pixels - total counted)

+) 20 ranges of the remainder with minimum resolution of 4.    [0-3 (really 1-3)],    [4-7],   [8-12] .....[248-251]...[252-255]
    (so    [4-11] would be valid, as would   [12-23]   )

+) There are 12 ranges in the Marshall false colour on http://www.marshallmonitors.com/products/monitors/V-LCD50-HDMI/
     [0 = Fusia] + 11 ranges.    We would have 20, and could elect where we want more detail.
     If we did line up with False colour, the Histogram Icon could use colour that match the same IRE bands

Estimated CPU impact = 8 cycles per two pixels (in calculating the bins)
Estimated Read & Writes per line contention = 20.

Solution - 2 - Store to memory

Use existing ML C logic with slight correction now that we know that luma is 8bit.

 There would be 255 actual levels
+) [0] by itself (it won't be counted, in the asm, but will be worked out at the end as total pixels - total counted)

+) 255 pixel bins

Estimated CPU impact = 6-10 cycles (depending on Cache hit) per two pixels (in calculating the bins). 
Estimated Read & Writes per line contention = max of 720 (depending on Cache hit)



I'll should get some time later in the week .. and could code both to get a feel of their impact.

AJ

 


Alex

unread,
Jan 5, 2011, 3:29:59 AM1/5/11
to ml-d...@googlegroups.com
Two pixel averaging was there for speed... I guess.

Antony Newman

unread,
Jan 7, 2011, 8:43:39 AM1/7/11
to ml-d...@googlegroups.com
Histo Caculation
============
I will be coding for either 64 bins ( or maybe 128).
 
I am more inclined to process each pixels individual luma and 64 bins, rather than add the luma up of two pixels and use 256bins (existing code)..
 
Histo display
=========
Currenly thinking of using a Horizontal lines.  Lines at the botom Luma=0.  Lines at the top=100%.
I'm also inclined to use a Colouring similar to the Marshal 'False' colour (so you know which Level these correspond to).
(may also be interesting if a FalseColour option is ever available).
 
If you can think of excellent compact way to show this information - let me know ASAP.
 
 
Canon 'Under/Over Exposure' icon
=========================
In Moira's photo - this was displaed along with the other Canon Icons.
 
Question 1) If you the Histogram .. do you need the Canon Icon?  
 
Question 2) If the histogram is a replacement for the under/over exposed canon display - which of the Canon icons do we actually need when shooting video?
 
Thanks.
AJ
 

Alex

unread,
Jan 7, 2011, 8:52:07 AM1/7/11
to ml-d...@googlegroups.com
64 bins is fine. Horizontal histogram... it's pretty strange (all
graphics programs I know display the histogram like it's now, with
vertical bars).

A compact way to show under/over exposure would be as a percentage. A
(logarithmic maybe) graphical display (like the audio meters, but
small, like an icon) might help.

Moira O'Brien LIPF

unread,
Jan 7, 2011, 10:52:41 AM1/7/11
to ml-d...@googlegroups.com
On 7 January 2011 13:43, Antony Newman <antony...@gmail.com> wrote:
<snip>
 
Histo display
=========
Currenly thinking of using a Horizontal lines.  Lines at the botom Luma=0.  Lines at the top=100%.
I'm also inclined to use a Colouring similar to the Marshal 'False' colour (so you know which Level these correspond to).
(may also be interesting if a FalseColour option is ever available).
 
If you can think of excellent compact way to show this information - let me know ASAP.

Given that real estate is limited either display vertical bars at the bottom of the screen or horizontal bars (so what, Alex, that no one else does this)  on the right side of screen - in either case with low opacity background as at present.
 
 Canon 'Under/Over Exposure' icon
=========================
In Moira's photo - this was displaed along with the other Canon Icons.
 
Question 1) If you the Histogram .. do you need the Canon Icon?  

No
 
Question 2) If the histogram is a replacement for the under/over exposed canon display - which of the Canon icons do we actually need when shooting video?
 
If the font size of the ML display is increased (for me) then none of the Canon display is necessary except the battery info.

Moira

 

Antony Newman

unread,
Jan 9, 2011, 4:26:23 PM1/9/11
to ml-d...@googlegroups.com
Not sure if there my web-cam has enough resolution to effectively demonstrate the 'low impact' Zebras .. but here it is.

http://www.youtube.com/watch?v=a5t18bQ7m64

AJ

JaKoB

unread,
Jan 9, 2011, 4:58:45 PM1/9/11
to ml-d...@googlegroups.com
wow my 5d2 is ready for this lol

Moira O'Brien LIPF

unread,
Jan 9, 2011, 7:42:26 PM1/9/11
to ml-d...@googlegroups.com
Much more friendly AJ! Well done.

When can we have this and the focus assist to try out?

Moira


On 9 January 2011 21:58, JaKoB <jako...@gmail.com> wrote:
wow my 5d2 is ready for this lol

Antony Newman

unread,
Jan 10, 2011, 3:26:28 AM1/10/11
to ml-d...@googlegroups.com
Thanks Jakob /  Moira.

Before releasing a test version - I will complete the 'core' (which is over 6,000 lines of code so far)  to the point it is unlikely to change.
This will enable me to effectively troubleshoot any issues subsequently found.

My activity list is as follows:

Core
+) Histogram for non-false colour options (this is in the debugging the assembler code stage. 75% complete) [quite involved]
+) Audio meters & Display.  This is (I believe) another task that may use a lot of CPU power. [investigate and maybe write]

Non-core
+) Add menu options for Vector Cropmarks  [should be easy]
+) ML persisting of data into config [investigate and utilise - should be easy]
+) Lens based input

Regards,
AJ

Alex

unread,
Jan 10, 2011, 3:29:54 AM1/10/11
to ml-d...@googlegroups.com
AJ,

> ML persisting of data into config [investigate and utilise - should be easy]

CONFIG_INT("var.name", var_name, 5) // setting name from magic.cfg, C var name, default value

Only works with unsigned (16bit maybe) and strings. That's it.

--

Antony Newman

unread,
Jan 10, 2011, 3:44:22 AM1/10/11
to ml-d...@googlegroups.com
Thanks Alex!

Antony Newman

unread,
Jan 11, 2011, 8:01:43 AM1/11/11
to ml-d...@googlegroups.com
MENU
 
I was doing a having a look at the  "Add menu options for Vector Cropmarks  [should be easy]" task .. and didn't see a nice way to get input of numbers (eg 720) for cropmarks.
 
I've introduced a bit of a hack into menu.c (as I don't want to change every other menu) in ML.
 
I use a global variable set to Zero when the menu line is diplayed.  If the menu changes teh value (eg to 16), the next menu is only moved down 16 pixels rather than the default of 32 (or whetever large font is).
 
This should allow me to use Large fonts and small font where needed .. and also .. If I set the 'y' to change by Zero, I'll be able to display a 'Slot machine' style number input (3 digits on one line, the use can move the cursor between each one cycle between them).  This means that in about 30 clicks you can set a number from 0..999.
 
AJ

 

Antony Newman

unread,
Jan 13, 2011, 8:29:00 PM1/13/11
to ml-d...@googlegroups.com
Here's what the Menu currently looks like ...

http://www.youtube.com/watch?v=jh6EsMl3ZPQ

AJ

ba...@aol.com

unread,
Jan 14, 2011, 12:01:00 AM1/14/11
to ml-d...@googlegroups.com
Anthony:

I am wowed.... very nice.

Is this ready for prime time and if so, can you point me to source.
I have grown accustomed to false colors on my Marshall, but would be
cool for times I don't have monitor up...


...

-------------------------------------------------------

Sponsored links:
Rock Hard Erections. All New Formula
Attacks the Root Fast
www.capitolbird.org/pharma.html

http://www.youtube.com/watch?v=jh6EsMl3ZPQ

AJ

--

James Donnelly

unread,
Jan 14, 2011, 4:42:53 AM1/14/11
to ml-d...@googlegroups.com
On 14 January 2011 01:29, Antony Newman <antony...@gmail.com> wrote:
Here's what the Menu currently looks like ...

http://www.youtube.com/watch?v=jh6EsMl3ZPQ


Congratulations, amazing work.   I admire your dedication and skill.

Antony Newman

unread,
Jan 14, 2011, 8:27:59 AM1/14/11
to Magic Lantern firmware development
Thanks for the comments!
 
Tasks to complete:
+) Debugging "Histogram-caculator-for-Zebra" region.  This needs about 8 hours in one session. (ie the weekend)
+) Audio - monitoring and diplay.  This will take an elapsed week
+) Storing config data.  This will require a little bit of time as I may need to enable users to 'add' new vector cropmarks on the fly (I haven't investigated this yet).
 
This represents the 'core' of the code.  I'd rather share this when I know its all works as intended!
 
Guess 2-3 weeks?
 
AJ 
 

Ba...@aol.com

unread,
Jan 14, 2011, 11:20:35 AM1/14/11
to ml-d...@googlegroups.com
Thanks for the update.
 
--

Alex

unread,
Jan 15, 2011, 3:23:14 AM1/15/11
to ml-d...@googlegroups.com
AJ,

For vector cropmarks, I suggest to look at some existing work (i.e.
don't reinvent the wheel). Examples:
* http://chdk.wikia.com/wiki/Grids (code seems to be simple enough to be ported)
* try to find out how to use the built-in SVG engine, as Trammell
suggested in the fonts thread (I'm sure you can do that).

On the other hand, I'm thinking not to remove the BMP cropmark
support, because anyone can make one in Paint (or another image
editing program). It's very flexible and convenient for users. If they
are refreshed only when needed, this may be a good solution. RAM usage
is around 350k and can be optimized a lot.

On the other hand, you may have a generic option in menu (outline or
letterbox) for most common aspect ratios (i.e. 4:3, 3:2, cinemascope)
which won't need extra input files.

What do you think?

Antony Newman

unread,
Jan 15, 2011, 6:35:29 AM1/15/11
to ml-d...@googlegroups.com
Alex,

ML/Zebra.c

I'm happy to co-exist my code with Zebra.c and its support for cropmarks as long as:

+) The huge static arrays are replaced by Mallocs (I don't want to starve the DryOs & my code of memory)
+) I can change the sleep timer in Zebra.c can be optionally increased to every second


Cropmarks

I have not spent much time looking at CHDK forum.   There may be some overlap.
I am interested in having a high speed graphics engine with the video tools you need integrated into core.

From this perspective, I my cropmarks aim is to:
+) have two areas - inside the crop marks where the engine renders False colours and Zebras
+) Outside the cropmarks area where the vector border of the cropmarks can be displayed

The Focus Assist 'Overlay' has a vector matrix that describes where it will be drawn - and the engine ignores this area when updating the Zebras.

Scaling:  Whilst not totally tested, the aim of this is to recalibrate the 480p cropmarks depending on which screen mode is being displayed (LCD, HDMI)


Cropmarks Graphics inside 'cropmark region'

I have not written this into the engine.  It is possible that the engine could be extended to cater for this - better to get something that works out rather than build everything I could dream of into it.

I will post of video of how the completed GUI works for cropmarks (finished it yesterday) ... but I need to concentrate on a assembler debug a the routine that processes histogram & zebra.


ScaledVectorGraphics
I didn't think the DryOs had scaled vector graphics.   If you search for "Rectangle" in the subroutine list - you'll (I think) see the drawing routines that it uses.  All the code seems to hard code switches based on what the vram resolution is (or which engio struct is being used).

Dryos Fonts: I have not investigated these - but did find the Bitmap images of the 'Loading' screen, and (I think Dryos) bitmap fonts stored in memory.

I know very little about the dryos graphics routines beyond this - probably needs someone to investigate how they work (if we need to use them).



"On the other hand, you may have a generic option in menu (outline or
letterbox) for most common aspect ratios (i.e. 4:3, 3:2, cinemascope)
which won't need extra input files."


I have have generic options - but they need to be calibrated (eg by taking exsiting 'square' cropmarks bmps and working out which pixel positions they are drawn at).

AJ

Antony Newman

unread,
Jan 15, 2011, 8:07:49 AM1/15/11
to ml-d...@googlegroups.com
Here's the Vector Cropmarks GUI:

http://www.youtube.com/watch?v=__xHleg7oiY

AJ

Alex

unread,
Jan 16, 2011, 5:18:19 AM1/16/11
to ml-d...@googlegroups.com
Scaling cropmarks: good idea. There may be artifacts for bitmap
cropmarks, or wrong thickness for vector ones, but I think it's
usable.

I've used scaling code in the focus peaking code (because the hd image
vram and lcd vram have different sizes). It may be very slow for
images, though. How fast is the integer division on ARM? A look-up
table may help and it's not that big.

About your "crap" hacks: I think they suggest there's another problem
in another part of the code. At least that was my conclusion after
debugging LUA (which uses LOTS of mallocs and reallocs).

Antony Newman

unread,
Jan 16, 2011, 7:24:45 AM1/16/11
to ml-d...@googlegroups.com
Lookuptables:

When the user moves the magnified image (focus assist overlay) - it calculates where the circle (or ellipse) intersects with the screen pixels - which use square roots - on the fly.  I put as much of the final calculation in the lookup table as I can. 

For the YUV transformation I started down the numerical analysis root with hundreds of bits of paper to see I could spot the 'pattens' so that I could convert from YUV directly.  When the CPU time for the calculation started taking longer than the alternative (computing 3 indicies + a lookup) -> I went down the lookup root.     (I create the YUV index in around 6 CPU cycles now).     My next choice was where to put my the entire lookup in Cache (8192 bytes), or cached / uncached memory.    Ultimately  I decided to put it in cached memory, and not 'steal' the cache  (the frame rate was already plenty fast enough).

Transformation:  I was going to put this in the other thread, but was guessing you've already checked to see if any of the other buffers has a pixel ratio that you are more able to use.  If you are not processing at full resolution - then you could use a vram buffer that maps perfectly on the overlay.

Crap-hacks:  My current guess is that the task scheduler uses Interrupts to stop the ARM executing your C (or asm) code.  And that the other task is using too much dma.  This is only a theory based on the fact that when I switched off (ie commented out)  ML 'audio_meter_task'  and turned off the 'zebra task' - my code no longer required  long long pauses in non-memory intensive locations to stop it 'freezing' (I have never got 'err77' on my display - the task just seemed to freeze). 

A second theory is that the the DryOs has difficultly with too many tasks (or maybe where they don't hand back enough time to it using 'msleep()').

My intention is to have all screen updates handled by a single task - as this will let me more easily regulate what the user sees.  (the only exception being when the 'ML menu' is displayed when my screen update task hibernates). 

There are some DryOs 'task information' (along with memory info) routines that I have not looked at that may be useful for health-checking what the tasks are doing (eg they are not hogging the CPU expectantly).

AJ

Antony Newman

unread,
Jan 16, 2011, 7:50:03 AM1/16/11
to ml-d...@googlegroups.com
Alex,

There is one other side effect that has happened since i've deactivated the zebra task & audio-meter - which is that ML no longer seems to get 'stuck' in bootup (ie refusing to go into live-view).  I don't know if this is coincidence - but this issue seems to have vanished (I hope for-ever!).  

I'm only one day into this - and maybe the 'getting stuck' only happened to me (!).

AJ

Alex

unread,
Jan 16, 2011, 7:52:07 AM1/16/11
to ml-d...@googlegroups.com
The audio module crashes LUA badly, so you might just have located a
bug in the audio meter...

But the zebra (at least the 550D one) seems to work fine.

Moira O'Brien LIPF

unread,
Jan 16, 2011, 7:53:30 AM1/16/11
to ml-d...@googlegroups.com
No Anthony, getting stuck is a common occurrence when doing anything other than accessing ML menus, changing ISO. Aperture, Shutter Speed or actually filming or replaying.  Any other action tends to hang the camera when returning to live view.

Moira





AJ

Moira O'Brien LIPF

unread,
Jan 16, 2011, 7:55:38 AM1/16/11
to ml-d...@googlegroups.com
On another matter Anthony, I noticed an email re audio not playing back.  I looked at the past messages and see that Trammel claimed to have cured this in 0.1.6, but my audio has never, and is still not, working in playback in-camera.

How is this working for you with your current builds?

Moira

Alex

unread,
Jan 16, 2011, 8:02:54 AM1/16/11
to ml-d...@googlegroups.com
On the 550D, Deti fixed the audio playback issue with this patch:

https://bitbucket.org/hudson/magic-lantern/changeset/ae555a0ee358

Moira O'Brien LIPF

unread,
Jan 16, 2011, 8:28:30 AM1/16/11
to ml-d...@googlegroups.com
Thanks for that Alex, but not being a techie, how do I apply this patch to ML?

Moira

Alex

unread,
Jan 16, 2011, 8:38:06 AM1/16/11
to ml-d...@googlegroups.com
As far as I know, only Antony and Trammell are the developers who work
on the 5D2.

I can compile ML for 5D2 and apply patches, but I'm not able to test
it, so the chances of breaking something are high.

On Sun, Jan 16, 2011 at 3:28 PM, Moira O'Brien LIPF

Antony Newman

unread,
Jan 16, 2011, 8:49:09 AM1/16/11
to ml-d...@googlegroups.com
Alex,

I have Not seen a coding error the ML code that I'm rewriting - although it is possible that using 'C' to draw the ML audio meters was 'too fast'.

[Note: rewriting the audio meters because (i) ML have a slighltly different coordinate system to mine and (ii) I separate screen update into draw-after-a-screen-clear and draw-update (for speed), and (iii) I am likely to write an accelerated horizontal line drawing in pure asm ('twill be used by both this and the horizontal histogram). ]

Moria,

I have not applied any patches to my ML environment since I took the 2.0.4 compatible version.
As my icons use ML fonts (for the numbers), I have however taken the latest 'proportional' fonts.

The ML audio splits into two components:  (1) Collecting/Processing the audio data, and (2) displaying it.

Right now I working on the (2), and keeping ML's existing audio processing.

AJ

Antony Newman

unread,
Jan 16, 2011, 9:45:49 AM1/16/11
to ml-d...@googlegroups.com
Alex,

Thanks for a link to the patch.   At some point I will look at how the code repository works.

Clicking on audio.c in the repository this jumped out at me:

static uint8_t
db_peak_to_color(
int db
)
{
if( db < -35 )
return 0x7f; // dark blue
if( db < -20 )
return 0x7f; // dark blue
if( db < -15 )
return 0xAE; // bright yellow
return 0x08; // bright red
}

It's not bug per se - but there is an option there for greater granularity of displayed colour.

AJ

Antony Newman

unread,
Jan 16, 2011, 4:37:51 PM1/16/11
to ml-d...@googlegroups.com
Here's and update video:

http://www.youtube.com/watch?v=F-NWOwp9jbk

What I'd like to do next is make sure that the other information that we need is displayed on the screen (at the bottom).
If there were selectable 'Sets' of information - what information would be most useful?

AJ

JaKoB

unread,
Jan 17, 2011, 12:15:14 PM1/17/11
to ml-d...@googlegroups.com
looking forward to the 5d2 ML update..

Antony Newman

unread,
Jan 18, 2011, 6:50:25 PM1/18/11
to ml-d...@googlegroups.com
Here's another update ...

http://www.youtube.com/watch?v=SbVSKYGOD38

(strange strange Youtube number ... nothing todo with me!)

AJ

JaKoB

unread,
Jan 18, 2011, 6:56:33 PM1/18/11
to ml-d...@googlegroups.com
!drool!

James Donnelly

unread,
Jan 18, 2011, 7:03:41 PM1/18/11
to ml-d...@googlegroups.com
I disagree AJ, I think you should hence forth be known by your official SKYGOD moniker.

The interface looks very polished compared to ML as it is now.  I like the use of colours, and the arrangement looks well thought out.

Antony Newman

unread,
Jan 19, 2011, 8:01:39 AM1/19/11
to ml-d...@googlegroups.com
Alex,

I next get a chance to work on this Thursday or Friday (I'm at an internet cafe at the moment).

I had very quick look at ML code to persist menu data::

The following line of code is ambiguos (for me) - as unsigned may compile to either 16 or 32 bits (my 'C' knowledge is not very good in this area).

(config.h)
#define CONFIG_INT( NAME, VAR, VALUE ) \
_CONFIG_VAR( NAME, 0, unsigned, VAR, VALUE )


and
(config.c)

if( var->type == 0 )
{
*(unsigned*) var->value = atoi( cfg->value );
} else {
*(char **) var->value = cfg->value;
}



Not sure yet if  I will either be adding my own data type (Unsigned int) or may change the existing type to be 'unsigned int'.

My preference is to change the existing type .. you may be interested in doing the same (main benfit, you'll be able to store memory addresses with worry if they get trunctated). 

If there are any other 'unsigned' types in the ML code ... it would be wise to understand if they are writing int DryOs memory, as the Dryos uses a mixture of 8,16,and 32 bits numbers.  Internally (ie in ML), I woud recommend use of 32 bits as much as possible (its faster). 

The only expection would be if you are packing your variables to avoid use of Stack to pass them between procedures (which I am guiltly of for most of my asm library).

AJ


On 10 January 2011 08:29, Alex <broscu...@gmail.com> wrote:
AJ,

> ML persisting of data into config [investigate and utilise - should be easy]

CONFIG_INT("var.name", var_name, 5) // setting name from magic.cfg, C var name, default value

Only works with unsigned (16bit maybe) and strings. That's it.

Alex

unread,
Jan 19, 2011, 8:43:59 AM1/19/11
to ml-d...@googlegroups.com
This section definitely needs a bit of cleanup. I'd replace the data
type with int32_t. My guess is that unsigned is there because
Trammell's reimplemementation of atoi (which is used when reading
config file) does not handle signed numbers.

By replacing blindly unsigned with int32_t it didn't work (it seems to
break the audio module). Also, I have some ugly hacks for qscale
because of this.

Antony Newman

unread,
Jan 19, 2011, 12:50:47 PM1/19/11
to ml-d...@googlegroups.com
Alex,

I'm not that familiar with ML types.

I was going to suggest 'unsigned int' (this being what I use everywhere = native ARM type that I use everywhere).

If the ML atio doesn't handle  32 bit numbers .. I think we can called the DryOs function instead (from the top of my memory).

If the anyone needs 'signed ints' .. it might be easier to do the conversion after getting the data (or maybe introducing a new type?).

Eg: The ML code uses  -ve numbers to store / calculate Db.   All my audio routines use +ve numbers and only switch to -ve in the 11th our (to display to the user).

AJ

Antony Newman

unread,
Jan 19, 2011, 9:17:05 PM1/19/11