[ML] 5D2 Overlay & Focus

[Antony Newman]

Here's a quick video of some ongoing 5D2 experimentation.

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

Regards,
Antony

[Antony Newman]

Here's a quick update on the 'Focus Assist' function.

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

AJ.

[James Donnelly]

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]

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

[Antony Newman]

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]

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]

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]

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

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

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

[M.v.M.]

  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]

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]

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]

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

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]

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]

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]

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]

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]

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]

Two pixel averaging was there for speed... I guess.

[Antony Newman]

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]

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]

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]

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]

wow my 5d2 is ready for this lol

[Moira O'Brien LIPF]

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]

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]

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]

Thanks Alex!

[Antony Newman]

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]

Here's what the Menu currently looks like ...

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

AJ

[ba...@aol.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]

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]

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]

Thanks for the update.

 

--

[Alex]

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]

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