Magic Lantern Forum

Developing Magic Lantern => General Development => Topic started by: stevefal on September 28, 2013, 08:50:23 AM

Title: Bars facelift
Post by: stevefal on September 28, 2013, 08:50:23 AM
I'd like to propose a facelift for the top and bottom LV bars. The goals are:

- better visibility in more situations
- more information displayable
- neutral coloring
- uniform layout

(http://i.imgur.com/APcM3VN.gif)


- Backgrounds are semi-transparent a la histogram background
- Bottom bar uses Argand 28 rather than 32 - greater density and more visible - no outlines
- Items are neutral white unless caution (yellow) or warning (red)
- Justified spacing - shifting is possible when data changes
- Using symbols is encouraged to save space
- Shoot the moon? Individually hide-able, sizable (S-23, M-28, L 32) and configurable content
Title: Re: Bars facelift
Post by: a1ex on September 28, 2013, 08:54:12 AM
I like it, looks very elegant.
Title: Re: Bars facelift
Post by: xNiNELiVES on September 28, 2013, 09:37:21 AM
Yes elegant but I would like to add the colored information still colored in the new theme. Just a personal opinion. Everything seems to blend together without it...
Title: Re: Bars facelift
Post by: stevefal on September 28, 2013, 09:44:57 AM
I don't have the coding chops to build it, but I envision an API that does the generic layout and lets core ML features and modules register displayable items. The user could select which items should appear in bar N, the client feature/module would post updates (text + color + maybe minWidth), and the server would take care of layout, drawing, clearing, redrawing etc.

It would give module developers an easy way to communicate via LV and without splattering other overlays.
Title: Re: Bars facelift
Post by: jose_ugs on September 28, 2013, 12:56:13 PM
Much better!
Title: Re: Bars facelift
Post by: arrinkiiii on September 28, 2013, 01:03:06 PM
Very nice indeed  :D
Title: Re: Bars facelift
Post by: Doyle4 on September 28, 2013, 01:31:21 PM
Really like!!

I like the idea suggested of been able to choose the info to be coloured, but other than that i really like.

Be nice to have a mini histogram in the bar too :) can choose to have standard or mini mode? Also be nice is battery satus was % for a more accurate reading?
Title: Re: Bars facelift
Post by: Stedda on September 28, 2013, 02:30:46 PM
Love it, ML is becoming very polished!

Thanks for all the hard work!
Title: Re: Bars facelift
Post by: pravdomil on September 28, 2013, 03:20:02 PM
nice, and do you have idea for movie mode? Sound, buffer, time etc?
For custom content we can use flexinfo?
Title: Re: Bars facelift
Post by: g3gg0 on September 28, 2013, 10:20:00 PM
i will extend flexinfo to be usable for both photo and LV mode.
additionally i will add dynamic content support. ;)
Title: Re: Bars facelift
Post by: pilgrim on September 28, 2013, 10:45:32 PM
Very beautiful, and surely useful. I like very much the battery indicator which more precise, also the Kelvin  :)  :)  indication.
The battery indicator from Canon is too simple, for safety (and cooler ARM) it's good to use the battery grip. But there is a moment I don't want to use the grip, because more discreet or because the stabilization, so accurate indicator for battery is very useful in the field. Thanks for the idea, and thank also the dev team   ;) , as always, who follow up. 
Title: Re: Bars facelift
Post by: stevefal on September 29, 2013, 12:12:24 AM
Quotebe nice to have a mini histogram in the bar too

"Histobar":

(http://i.imgur.com/yGgJ3zQ.gif)
Title: Re: Bars facelift
Post by: g3gg0 on September 29, 2013, 12:17:06 AM
okay, flexinfo is updated now.

see http://www.magiclantern.fm/forum/index.php?topic=4157.msg79244#msg79244
Title: Re: Bars facelift
Post by: g3gg0 on September 29, 2013, 01:01:25 AM
here some example implementation of your proposal.


diff -r b227e49bcedf src/flexinfo.c
--- a/src/flexinfo.c Sat Sep 28 23:59:18 2013 +0200
+++ b/src/flexinfo.c Sun Sep 29 00:57:41 2013 +0200
@@ -93,7 +93,38 @@
info_elem_t info_config_liveview[] =
{
     { .config = { { INFO_TYPE_CONFIG } } },
-    { .text = { { INFO_TYPE_TEXT, { 150, 20, 2, .name = "Note" }}, "<FlexInfo unconfigured>", COLOR_CYAN, INFO_COL_PEEK, INFO_FONT_SMALL } },
+    /* entry 1, top bar */
+    { .fill = { { INFO_TYPE_FILL, { 10, 60, 1, .w=700, .h=30, .name = "Top bar" }}, .color = COLOR_BG } },
+    /* entry 2, bottom bar */
+    { .fill = { { INFO_TYPE_FILL, { 10, 300, 1, .w=700, .h=30, .name = "Bottom bar" }}, .color = COLOR_BG } },
+   
+   
+    /* fill top bar */
+   
+    /* entry 3, time (leftmost) */
+    { .string = { { INFO_TYPE_STRING, { 15, 5, 2, .name = "Hrs", .anchor = 1, .anchor_flags = INFO_ANCHOR_LEFT | INFO_ANCHOR_TOP,  .anchor_flags_self = INFO_ANCHOR_LEFT | INFO_ANCHOR_TOP }}, INFO_STRING_TIME_HH24, COLOR_WHITE, INFO_COL_PEEK, INFO_FONT_MEDIUM } },
+    { .text   = { { INFO_TYPE_TEXT,   {  0, 0, 2, .name = ":",   .anchor = 3, .anchor_flags = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP, .anchor_flags_self = INFO_ANCHOR_LEFT | INFO_ANCHOR_TOP }}, ":", COLOR_WHITE, INFO_COL_PEEK, INFO_FONT_MEDIUM } },
+    { .string = { { INFO_TYPE_STRING, {  0, 0, 2, .name = "Min", .anchor = 4, .anchor_flags = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP, .anchor_flags_self = INFO_ANCHOR_LEFT | INFO_ANCHOR_TOP }}, INFO_STRING_TIME_MM, COLOR_WHITE, INFO_COL_PEEK, INFO_FONT_MEDIUM } },
+   
+    /* entry 6, free space  (rightmost)*/
+    { .text   = { { INFO_TYPE_TEXT,   { -15, 5, 2, .name = "GB",       .anchor = 1, .anchor_flags = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP, .anchor_flags_self = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP }}, "GB", COLOR_WHITE, INFO_COL_PEEK, INFO_FONT_MEDIUM } },
+    { .string = { { INFO_TYPE_STRING, {  -2, 0, 2, .name = "Space GB", .anchor = 6, .anchor_flags = INFO_ANCHOR_LEFT | INFO_ANCHOR_TOP,  .anchor_flags_self = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP }}, INFO_STRING_FREE_GB_FLOAT, COLOR_WHITE, INFO_COL_PEEK, INFO_FONT_MEDIUM } },
+   
+    /* entry 8, pictures */
+    { .string = { { INFO_TYPE_STRING, { -15, 0, 2, .name = "Pics", .anchor = 7, .anchor_flags = INFO_ANCHOR_LEFT | INFO_ANCHOR_TOP, .anchor_flags_self = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP }}, INFO_STRING_PICTURES_AVAIL_AUTO, COLOR_WHITE, INFO_COL_PEEK, INFO_FONT_MEDIUM } },
+
+    /* entry 9, temperature */
+    { .text   = { { INFO_TYPE_TEXT,   { -15, 0, 2, .name = "°C",   .anchor = 8, .anchor_flags = INFO_ANCHOR_LEFT | INFO_ANCHOR_TOP, .anchor_flags_self = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP }}, SYM_DEGREE"C", COLOR_WHITE, INFO_COL_PEEK, INFO_FONT_MEDIUM } },
+    { .string = { { INFO_TYPE_STRING, {  -2, 0, 2, .name = "Temp", .anchor = 9, .anchor_flags = INFO_ANCHOR_LEFT | INFO_ANCHOR_TOP, .anchor_flags_self = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP }}, INFO_STRING_TEMPERATURE, COLOR_WHITE, INFO_COL_PEEK, INFO_FONT_MEDIUM } },
+
+   
+    /* fill bottom bar */
+   
+    /* entry 11, ISO */
+    { .string = { { INFO_TYPE_STRING, { -15, 5, 2, .name = "ISO",      .anchor = 2, .anchor_flags = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP, .anchor_flags_self = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP }}, INFO_STRING_ISO, COLOR_WHITE, INFO_COL_PEEK, INFO_FONT_MEDIUM } },
+    { .text   = { { INFO_TYPE_TEXT,   {  -2, 0, 2, .name = "ISO icon", .anchor = 11, .anchor_flags = INFO_ANCHOR_LEFT | INFO_ANCHOR_TOP, .anchor_flags_self = INFO_ANCHOR_RIGHT | INFO_ANCHOR_TOP }}, SYM_ISO, COLOR_WHITE, INFO_COL_PEEK, INFO_FONT_MEDIUM } },
+
+
     { .type = INFO_TYPE_END },
};

@@ -1190,7 +1221,14 @@
     {
         case INFO_STRING_ISO:
         {
-            snprintf(buffer, maxsize, "(ISO)");
+            if(lens_info.iso == 0)
+            {
+                snprintf(buffer, maxsize, "%d", lens_info.iso_auto);
+            }
+            else
+            {
+                snprintf(buffer, maxsize, "%d", lens_info.iso);
+            }
             break;
         }
         case INFO_STRING_ISO_MIN:
@@ -1508,6 +1546,11 @@
             snprintf(buffer, maxsize, "%d.%d", fsg, fsgf);
             break;
         }
+        case INFO_STRING_TEMPERATURE:
+        {
+            snprintf(buffer, maxsize, "%d", EFIC_CELSIUS);
+            break;
+        }

         /* empty string */
         case INFO_STRING_NONE:
@@ -2987,8 +3030,9 @@
     {
         if(info_config_dynamic[pos].hdr.status == INFO_STATUS_FREE)
         {
-            /* this empty entry will be the returned one */
+            /* this empty entry will be the returned one. set it to CONFIG type so it wont get handled */
             item = &info_config_dynamic[pos];
+            item->type = INFO_TYPE_CONFIG;
             item->hdr.status = INFO_STATUS_USED;
             item->hdr.config = info_config_dynamic;
             item->hdr.config_pos = pos;
diff -r b227e49bcedf src/flexinfo.h
--- a/src/flexinfo.h Sat Sep 28 23:59:18 2013 +0200
+++ b/src/flexinfo.h Sun Sep 29 00:57:41 2013 +0200
@@ -131,6 +131,7 @@
#define INFO_STRING_FREE_GB_INT          41
#define INFO_STRING_FREE_GB_FLOAT        42
#define INFO_STRING_KELVIN_ICO           43
+#define INFO_STRING_TEMPERATURE          44

#define INFO_FONT_SMALL         0
#define INFO_FONT_MEDIUM        1
@@ -228,5 +229,10 @@
     info_elem_dynamic_t dynamic;
};

+/* register a new element that is unconfigured by default. set it to the type you need it to be and care for it yourself */
+info_elem_t *info_add_item();
+/* unregister a previously registered element */
+void info_free_item(info_elem_t *item);
+
#endif
#endif

Title: Re: Bars facelift
Post by: jose_ugs on September 29, 2013, 01:19:00 AM
Thumbs up for that Histobar! Looks like something that makes the best out of a bunch of pixels in there...
Title: Re: Bars facelift
Post by: a1ex on September 29, 2013, 07:48:30 PM
How do you define the histobar mathematically? and why not use a plain histogram?
Title: Re: Bars facelift
Post by: stevefal on September 29, 2013, 10:01:24 PM
The histobar is meant as a simplification that strips away information that doesn't factor in (my) decision-making when using the histogram. The goal is a way to communicate only these essential facts, graphically, compactly and very plainly:

- DR of the camera (11 stops in the example)
- DR of the scene (7 stops in the example)
- range above and below the scene (empty boxes)
- highlight and shadow clipping

I'll take a crack at the math:

- The bar displays one box per stop of camera DR in the current mode:
       dual ISO = 13 or fewer, depending on settings
       optimal RAW = 11
       sub-optimal RAW < 11, depending on settings
       JPG, H.264 = 8
- If DR is non-integral, always round up. That box is not worth a full stop, but it does represent additional range.
- The user can configure bin threshold as % of pixels in a bin (B%). One threshold for all bins. Default is...1%?
- The user can configure clipping thresholds as % of pixels at min and max (C-lo%, C-hi%). Defaults are...1%?
- A box lights if B% of pixels are in that bin.
- Top/bottom boxes change red/blue if C-hi%.C-lo% pixels are at max/min.
- All boxes between the highest and lowest ON boxes are ON, regardless of empty bins in between. The span represents dynamic range.

Nice-to-haves:

- Add a "Histobar" flavor in Falscolor that uses blue and red at min and max, for consistent signals.
- Offer optional 1/2 and 1/3 stop bins - 2x and 3x as many boxes.

P.S. I envisioned it being rendered via two in-font symbols, a la □□□■■■■■■. This way the same formatted string could be printed in different contexts, even different sizes, without the developer worrying much about layout. This goes along with the bar server idea I mentioned above.
Title: Re: Bars facelift
Post by: CFP on September 29, 2013, 10:07:43 PM
I love that design and I think a histobar would be really nice!

Please implement it, if it's possible and not to much work. :D
Title: Re: Bars facelift
Post by: g3gg0 on September 29, 2013, 11:51:44 PM
thats the current state of the implementation with flexinfo.
(http://upload.g3gg0.de/pub_files/7fe729af810f6aac90a2ebd8ecac68ce/VRAM2.BMP)
Title: Re: Bars facelift
Post by: g3gg0 on September 30, 2013, 12:33:34 AM
code committed - just go to line 104 in flexinfo.c and uncomment this

//#define i_want_to_test_flexinfo_bars 1

to be able to change colors of the fields, i added a new function.
some code (or module) can simply call:


extern info_elem_t *info_config_liveview;

/* get item TempBG which is a FILL element */
info_elem_t *item = info_get_by_name(info_config_liveview, "TempBG");
if(item)
{
    item->fill.color = COLOR_RED;
}
Title: Re: Bars facelift
Post by: stevefal on September 30, 2013, 01:59:42 AM
I uncommented 104, but dumb question, how/where do I turn on Flexinfo? I don't find a way to see it.

Can you help me understand how flexinfo relates to the bars idea? Is flexinfo proposed as a replacement implementation of the current bars?

Are you interested in the status display server idea I mentioned above? Bar server discussion ideas:

- auto-layout as element list, a la Android LinearLayout
- element manager with config UI so user can turn on/off elements
- default element type = text. Alternate "owner-draw" type lets module draw in the element window
- modules post formatted text strings to server, server redraws only when necessary
- owner-draw elements notifie module of dirty element, for repaint
- server and layout code are totally decoupled from content - it's like a listbox widget
Title: Re: Bars facelift
Post by: a1ex on September 30, 2013, 07:33:50 AM
Also apply this change, and the new bars will appear:

diff -r 136004f68e89 src/lens.c
--- a/src/lens.c Mon Sep 30 00:22:57 2013 +0200
+++ b/src/lens.c Mon Sep 30 08:14:34 2013 +0300
@@ -189,11 +189,7 @@
void
update_lens_display(int top, int bottom)
{
-    extern int menu_upside_down; // don't use double buffer in this mode
-    int double_buffering = !menu_upside_down && !is_canon_bottom_bar_dirty();
-
-    if (top) draw_ml_topbar(double_buffering, 1);
-    if (bottom) draw_ml_bottombar(double_buffering, 1);
+    info_print_screen();
}

int should_draw_bottom_bar()


+1 for all these points. If you ask me, I'd re-design flexinfo from scratch, with dynamic items only (no hardcoded items), automatic layout (no hard-coded xy coords, just some hints about item order) and a simplified menu interface (just on/off should be enough, but I wouldn't mind if there's a way to specify item order).

You can enable FEATURE_FLEXINFO_FULL (define it at the top of flexinfo.c) and you also get a menu (which is extremely configurable, but a bit overwhelming IMO - I highly doubt the user wants pixel-perfect control over each of the info items, and that's why I disabled it).
Title: Re: Bars facelift
Post by: g3gg0 on September 30, 2013, 09:56:19 AM
If you uncomment this line i said, it should print automatically.
maybe i missed to check in some .c file, sorry.

okay flexinfo would need some rewrite when we want to add different layout kinds.

the bars are intentionally fixed width, but anchored together.
when strings change their length, i wanted the others to position absolutely.
if you move one elements, the others move too - width is fixed
Title: Re: Bars facelift
Post by: ItsMeLenny on September 30, 2013, 12:00:25 PM
I like that layout proposal, however I prefer the coloured numbers and such.
Title: Re: Bars facelift
Post by: stevefal on September 30, 2013, 03:28:43 PM
Quote...I prefer the coloured numbers...

A few people have said this, so I want to clarify. Colored numbers are part of the proposal, but used sparingly. For example, I don't use dark green for happy numbers but do use yellow and red for sad numbers (glacier shot). This makes the alert conditions more noticeable since they are exceptions. Also, readability depends on contrast between foreground and background, so coloring should be designed carefully.
Title: Re: Bars facelift
Post by: Doyle4 on September 30, 2013, 06:34:03 PM
Quote from: stevefal on September 29, 2013, 12:12:24 AM
"Histobar":

(http://i.imgur.com/yGgJ3zQ.gif)

Man that is sweet!
I agree with what i think a1ex was saying which is try the old look but in the same place? or would it be possible to add numbers to the box's so when using Aettr you can make sure you are hitting the correct metering for example time lapse -0.2?

But looking good man!, as for color font i think it should be a choice wether to use white or color, but i love the cleanness of white.
Title: Re: Bars facelift
Post by: stevefal on September 30, 2013, 09:06:25 PM
I think that showing a full histogram in a top/bottom bar is also an interesting idea. But I don't think that they are mutually exclusive.

In general I resist features being designed only for the most sophisticated scenarios/users. I prefer an open architecture that invites developing features and UI for a broad range of users. That's why I'm interested in top/bottom bars as containers rather than content unto themselves. In fact, modules could be built merely to offer new simple or sophisticated status elements.

I support the kind of idea regarding Aettr that you propose. But it misses the point of histobar, which is meant to be simplistic by definition. The information in Histobar is what I usually want, and I don't propose it as a replacement for a full histogram. Make sense?

Can you list out the precise information you'd like to see for your Aettr scenario, and I'll try to design something. Talk to me like an Aettr beginner.
Title: Re: Bars facelift
Post by: Doyle4 on October 01, 2013, 01:47:15 AM
Make sense to me, and i like the work you have done so far.

What ill do tomorrow is take a screen grab of my screen and ill try and photoshop something together to try and give you an idea if thats ok? bed for me now as its late :)
Title: Re: Bars facelift
Post by: Audionut on October 01, 2013, 03:31:25 AM
Quote from: stevefal on September 30, 2013, 09:06:25 PM
Can you list out the precise information you'd like to see for your Aettr scenario, and I'll try to design something. Talk to me like an Aettr beginner.

The main information needed is exactly how far the exposure is from overexposure. 

To keep the histobar simplistic, I would propose half stops.  Where the bar is half full, exposure is within 0.5-1.0EV from the next stop.  Where the bar is full, exposure is within 0.0-0.5EV from the next stop. 

I would also extend the overexposure indicator to colored tiles, RGB to indicate overexposure in that specific channel, black to indicate overexposure in more then one channel.  Although this could be outside the bounds of "simplistic".

I would like the opacity of the shading reduced slightly.

A toggle just like Canon preview.  This could then be extend to provide toggle options that show further detail.  For instance, you could toggle to have the top bar extend to include a full blown histogram and other information.  Simplistic--->Extended--->Clear--->Simplistic
Title: Re: Bars facelift
Post by: stevefal on October 01, 2013, 09:01:32 AM
Thanks for the feedback.

QuoteI would propose half stops.

Also, twice the number of boxes would give you half stops. I'm sure this can be done graphically several ways.

QuoteRGB to indicate overexposure in that specific channel,

Although I find the RGB distinction interesting, I'm curious as to what you do with it. Would you accept clipping in one channel and not in another? If not, wouldn't it be sufficient in practical terms to indicate 'clipping' if any of either R, G or B are clipping?

Likewise I can seen the bin/box scheme as a logical OR of the three channels (rather than aggregated as Luma).

If those makes sense I would amend my description earlier as:

- A box lights if B% of pixels are in that Red, Green or Blue bin.
- Top/bottom boxes change red/blue if C-hi%.C-lo% pixels are at max/min for any of Red, Green or Blue.

Again I don't think this should rule out an alternate visualization with more detail, but I'm trying to get at the most essential information typically needed, and show it plainly.

QuoteI would like the opacity of the shading reduced slightly.

I would too. I'm under the impression that there are limited choices, but I haven't investigated.

QuoteSimplistic--->Extended--->Clear--->

Interesting idea. I'm not sure if cycling every indicator unilaterally to "extended" is what the user would want, but maybe. Another possibility is to rely on the Display presets feature, and assuming a configurable model like we've discussed earlier in the thread, ML could provide a few factory presets that implement simplistic versus extended information. That way the user could customize or create his own and cycle through exactly the choices and levels he wants.
Title: Re: Bars facelift
Post by: Audionut on October 01, 2013, 10:30:56 AM
Quote from: stevefal on October 01, 2013, 09:01:32 AM
Also, twice the number of boxes would give you half stops. I'm sure this can be done graphically several ways.

From a visual standpoint, I think half bars are still the better option.
Twice the boxes increases display area and requires counting to fully ascertain correct value.  Half boxes provide extended information in the same amount of area with easy visual clues.


Quote from: stevefal on October 01, 2013, 09:01:32 AM
Although I find the RGB distinction interesting, I'm curious as to what you do with it. Would you accept clipping in one channel and not in another? If not, wouldn't it be sufficient in practical terms to indicate 'clipping' if any of either R, G or B are clipping?

I think it's best to have the distinction of which channel is blown.
I don't mind blowing the green channel in the sky (blue), on white detail etc, but I don't want to blow the green channel in green detail (grass for instance).

With an extremely blue/red light source, a large percentage of information will be captured by the blue/red channel, so I do not want to blow any of that detail, but I don't mind blowing the green channel.
If I understand your suggestion correctly, I wouldn't have that distinction.  I would only know that 1 channel is blown.


Quote from: stevefal on October 01, 2013, 09:01:32 AM
Again I don't think this should rule out an alternate visualization with more detail, but I'm trying to get at the most essential information typically needed, and show it plainly.

If the future allows an extended amount of customization, then it's neither here nor there really.  The main display should remain as simplistic as possible as you have it currently.  As I'm sure you know, this makes it easier for those new to the platform while allowing power users the customization they require.


Quote from: stevefal on October 01, 2013, 09:01:32 AM
Interesting idea. I'm not sure if cycling every indicator unilaterally to "extended" is what the user would want, but maybe. Another possibility is to rely on the Display presets feature, and assuming a configurable model like we've discussed earlier in the thread, ML could provide a few factory presets that implement simplistic versus extended information. That way the user could customize or create his own and cycle through exactly the choices and levels he wants.

My main idea was increasing the height of the top/bottom bars.

If the bars as they are now are classed as having a height of 1, toggling to the extended display would increase these bar heights to 2.  I'm sure a histogram (like the one currently implemented) could be squeezed into this double height, and any other manner of information while still retaining the same basic design.

The only reason I don't use the Canon preview toggles is because the JPG histogram is (basically) useless, and if you're in the extended information display, zebras still get drawn over the entire screen.

Quote from: stevefal on October 01, 2013, 09:01:32 AM
Thanks for the feedback.

Thankyou for your work. 
Title: Re: Bars facelift
Post by: Doyle4 on October 01, 2013, 03:49:38 PM
tbh i just downloaded latest build n i would say all is great dude, i spotted the ettr number.. very nice ;)
Title: Re: Bars facelift
Post by: a1ex on October 01, 2013, 03:58:38 PM
Here's my take regarding the layout engine:

- Separate the content from the layout engine. Content should be coded where it makes sense (e.g. ISO in lens.c, HDR bracketing info in shoot.c, histobar in histogram.c, raw video info in raw_rec.c and so on), not in the library. I still don't understand why moving all the strings to flexinfo.c was considered an improvement over leaving them in the source files where the info was generated (no offence, just technical discussion).

- User code should only care about content => a handler routine should simply fill some string buffer. Overriding colors is allowed. Custom drawing is supported, but plain strings should be preferred.

- Exact placement should be handled by the layout engine. User code is allowed to specify some hints (e.g. I prefer this to be on the top bar on the left, if not, it's OK to be on the bottom bar too, or maybe not, and so on). The layout engine should be allowed to re-arrange items if some things get very big, or are no longer displayed, and so on.

- For LiveView bars I think a centered layout works best (each item is aligned at center, and free space is distributed uniformly between items). Rationale: when an item changes its size a little, the overall layout is not disrupted.

- I want the font to be choosen by the layout engine too (if there are too many things, the layout engine should be allowed to try a smaller font for large items, for example).

- The layout engine should be allowed to discard some items if you add too much stuff. User code may specify a priority, so the layout engine should know what to discard first.

- I want the API to be similar to the menu one (because I'm used to it).

With this in mind, I wrote a pretty basic layout engine (https://bitbucket.org/hudson/magic-lantern/commits/140717a49634), separate from flexinfo, that does pretty much what stevefal suggested: modular design (no hardcoded content), automatic layout and fairly simple API. Of course, with a much smaller degree of generality, and also lighter-weight.

API
See lvinfo.h (https://bitbucket.org/hudson/magic-lantern/src/tip/src/lvinfo.h).

Example of user code:

static LVINFO_UPDATE_FUNC(temp_update)
{
    LVINFO_BUFFER(8);
   
    int t = EFIC_CELSIUS;
    snprintf(buffer, sizeof(buffer), "%d"SYM_DEGREE"C", t);
    if (t >= 60)
    {
        item->color_bg = COLOR_RED;
    }
}


where the user function does these things:

- reserve space for the string buffer
- fill the string buffer with the content (temperature)
- override the background color if the temperature gets too high (and do nothing in normal situations).

That's it. Can it get any simpler? Maybe only with some macros like the ones used in menu code (like MENU_SET_VALUE).

How this item is described?


static struct lvinfo_item info_items[] = {
    ...
    {
        .name = "Temperature",
        .which_bar = LV_TOP_BAR_ONLY,
        .update = temp_update,
        .priority = 1,
    },
   ...
};


From this, it's pretty obvious where this item will be placed (in a fuzzy way, not the exact position) and what it does.

After describing the items, you register them with something like this, just like menu items:

    lvinfo_add_items(info_items, COUNT(info_items));


Special fields (all optional):

- .preferred_position: this works pretty much like Z-order. Within one bar, all fields will get sorted according to this field. For example, I want the clock to be on the far left, so I specify a large negative value:


    {
        .name = "Clock",
        .which_bar = LV_TOP_BAR_ONLY,
        .update = clock_update,
        .preferred_position = -128,
    },


- .priority: if the layout gets really tight, the backend is allowed to discard items with a lower priority. For example, I don't really care about displaying picture style name (which is quite long anyway).


    {
        .name = "Pic.Style",
        .which_bar = LV_TOP_BAR_ONLY,
        .update = picstyle_update,
        .priority = -1,
    },


Algorithm for squeezing space (what happens if you throw too much stuff at it):

1) discard some items with negative priority (items with lowest priority get discarded first)
2) try a smaller font for some items (bigger items get squeezed first)
3) discard some more items (again, items with lowest priority get discarded first)

Custom drawing

static LVINFO_UPDATE_FUNC(my_custom_drawing_item)
{
    item->width = <whatever you need>;
   
    /* request custom drawing */
    item->custom_drawing = 1;
   
    if (can_draw)
    {
        /* you got permission to draw */
        /* just don't forget that item->x is the center of the item */
        int x_left = item->x - item->width/2;

        /* now go ahead and draw it */
        /* tip: use item->fontspec or its metrics so you know how big your drawing should be */
    }
}


Menu: I didn't implement one, but it's straightforward. Saving user config is a little harder, and it's not a priority, because I prefer to have something that just works without too much tinkering, rather than having infinite customizability that may get very hard to use.

There are still some functionality not yet ported from the old implementation (e.g. precise ISO/shutter, FPS, free space), but I think it works well enough so you can already try it in the current nightly builds.

Please post screenshots. I'd like to see how the layout handles different configurations. In particular, I'd like you to try a fairly long lens (long focal length string), IS enabled, focal length reported, dual ISO 1600/12800, 10000 kelvins... you get the idea (just try hard to make the info strings as long as you can).

Histobar kinda works too.
Title: Re: Bars facelift
Post by: wolf on October 01, 2013, 04:45:11 PM
Wow. Great looking. Thanks.  :)

I like to mention, that the contrast of menu-bar inside the ML menu is very low, especially in bright sun light.

edit:
(http://i.imgur.com/iSqY5HL.png)
Title: Re: Bars facelift
Post by: Rewind on October 01, 2013, 04:54:54 PM
Quote from: wolf on October 01, 2013, 04:45:11 PM
Wow. Great looking. Thanks.  :)

I like to mention, that the contrast of menu-bar is very low, especially in bright sun light.

+1
I also mentioned that: http://www.magiclantern.fm/forum/index.php?topic=8482.msg78748#msg78748
Title: Re: Bars facelift
Post by: stevefal on October 01, 2013, 05:57:53 PM
Great work a1ex. I think there's a lot to exploit here.

@wolf, re-copy the fonts to your SD as you're missing a couple draft symbols.

Quotecontrast of menu-bar is very low

Thanks, this is a known issue - need to tune up the color scheme.
Title: Re: Bars facelift
Post by: stevefal on October 01, 2013, 06:02:07 PM
On my 5D3, Canon's aperture/EV/speed overlay UI displayed on half-shutter splatters the bottom bar (it always did). Maybe the bar(s) should (optionally?) hide on half-shutter?
Title: Re: Bars facelift
Post by: Doyle4 on October 01, 2013, 06:08:28 PM
Could the histobar be something like this? i actually miss the histogram..

(http://i44.tinypic.com/sni87s.jpg)
Title: Re: Bars facelift
Post by: a1ex on October 01, 2013, 06:18:48 PM
Quotei actually miss the histogram..

Just turn it on ;)
Title: Re: Bars facelift
Post by: xNiNELiVES on October 01, 2013, 07:47:14 PM
Where are the semi transparent bars like the first photos posted? On actual screenshots I see only a black bar.
Title: Re: Bars facelift
Post by: a1ex on October 01, 2013, 07:52:43 PM
The screenshot does not contain transparency, you need to add it manually in Paint.
Title: Re: Bars facelift
Post by: stevefal on October 01, 2013, 08:36:00 PM
(http://i.imgur.com/L5Zmz5Y.png)

This is slightly doctored:

- in-font 4-segment battery icon (an idea)
- normal size battery % text - current is small, too low and cropped one pixel on right
- bar text full white - text in screenshot is slightly darker. 100% white is best for contrast.
- updated ETTR and DR icons

Argand Normal 28 v.57: http://popspring.com/mldrop/argnor28.rbf

I'm not sure why histobar was showing nothing. With the lens cap on I would expect the dark clipping indicator.
Title: Re: Bars facelift
Post by: stevefal on October 01, 2013, 08:48:08 PM
Another idea is to grow the bars from the center in order to obscure as little as possible.

(http://i.imgur.com/bXIXQSV.png)
Title: Re: Bars facelift
Post by: Doyle4 on October 01, 2013, 08:48:28 PM
Quote from: a1ex on October 01, 2013, 06:18:48 PM
Just turn it on ;)

ohhhh i didnt see that :P


Battery % looks good :) what about removing the clock for even more free space? or option to turn on or off?
Title: Re: Bars facelift
Post by: Doyle4 on October 01, 2013, 08:52:22 PM
When using stevefal interface, when in LV my 600d beeps once every second.
Title: Re: Bars facelift
Post by: a1ex on October 01, 2013, 09:00:46 PM
Quote from: stevefal on October 01, 2013, 08:36:00 PM
I'm not sure why histobar was showing nothing. With the lens cap on I would expect the dark clipping indicator.

Histobar is not accurate in shadows with dual ISO. Maybe it's that?

Quote from: Doyle4 on October 01, 2013, 08:52:22 PM
When using stevefal interface, when in LV my 600d beeps once every second.

Where's your screenshot? I remember asking for these in bold font...
Title: Re: Bars facelift
Post by: stevefal on October 01, 2013, 09:15:47 PM
QuoteHistobar is not accurate in shadows with dual ISO. Maybe it's that?

I wasn't using dual ISO.

The histobar also occasionally grows and shrinks by one box, seeming randomly, without my changing settings. I enabled the DR indicator to see if that was changing as well, but it was not.
Title: Re: Bars facelift
Post by: a1ex on October 01, 2013, 09:19:02 PM
In movie mode, DR is computed on the fly, from noise. Maybe it's a rounding issue.
Title: Re: Bars facelift
Post by: stevefal on October 01, 2013, 09:34:50 PM
I'm currently in a state where, due to item widths, the focus distance item is right at the edge of dropping out. <Infinity> and two digit distances show, but as soon as the distance requires three digits, the item disappears. A possible solution is to let the module specify maxWidth for the item (by providing a prototype string), so space is allocated for all possible values, or the item is pre-emptively dropped due to lack of space for its widest value.
Title: Re: Bars facelift
Post by: stevefal on October 01, 2013, 09:37:32 PM
Regarding priorities, another thought is to place low priority items in order on the ends of the bars so that when there's no space, they drop off the ends, leaving the interior items contiguous. This would have the additional benefit of placing important things closer to the user's center of view.
Title: Re: Bars facelift
Post by: a1ex on October 01, 2013, 09:43:21 PM
I repeat. Screenshots please. I can't see these problems on my camera.
Title: Re: Bars facelift
Post by: stevefal on October 01, 2013, 09:53:50 PM
QuoteI repeat. Screenshots please. I can't see these problems on my camera.

Who are you talking about? My focus distance issue is not a rendering problem - it's by design.

To be clear, I'm staying that the designed behavior of dropping items when there's too little room could be finessed with the maxWidth idea. It would prevent an item from being dropped just because it's value changed.

Tell me if you still want a screenshot of something from me.
Title: Re: Bars facelift
Post by: a1ex on October 01, 2013, 09:59:48 PM
Try commenting out lines 222-233 from lvinfo.c => it will first try a smaller font and only after that drop low-priority items. If that's a better behavior, I'll commit it.
Title: Re: Bars facelift
Post by: stevefal on October 02, 2013, 12:07:17 AM
QuoteTry commenting out lines 222-233

I tried it. My least favorite behavior is having a combination of large and small fonts in the same bar. It looks bad and there's still a breaking point. I think that being tricky with lots of automatic morphing gets dangerous. It creates mysteries and it can't know what the user actually wants. Things will appear/disappear and the user won't know why or how to govern it.

Here's what I'd propose, shooting the moon (bear with me):

- LVinfo implements a dynamic menu for each bar. Each menu has all the same items by name, alphabetcally:

       Top bar                                         ON                Q>
                Minimum size                       Small
                Aperture                              ON
                Dynamic range                     Auto
                Focus mode                         ON
                Focus distance                     OFF
                ...etc

- Modules register their items with LVinfo, but display of items is ultimately governed by the user setting ON, OFF, or AUTO for each item.
- All items are AUTO by default. Display of AUTO items is per the priority scheme. (I consider this a nice-to-have feature, with deterministic control a must-have)
- Modules register a maxWidth string with each item, used to calculate possibility of display and item position.
- The 'Minimum size' menu item determines the smallest font size the user is willing to tolerate in the bar. All items within a bar use the same font.
- Items set to OFF will never display
- Items set to ON will always display, but...
- When an item is set to ON, LVinfo calculates the possibility of display, according to the sum of maxWidths in the smallest font, per the current 'Minimum size' setting.
- If an ON item is impossible to display, a msgbox pops saying they need to turn something else OFF or choose a smaller Minimum size, if available.
- Display of items is per the following:

     All OFF items don't display.
     All ON items display as top priority, from the horizontal center of the bar.
     A bar drops to whatever size is necessary to display all ON items, and as many AUTO items as possible; but not smaller than 'Minimum size'.
     AUTO items are displayed on the horizontal outskirts of the bar, with lowest priority outermost.
     AUTO items are dropped from the outskirts if space is unavailable.
     An AUTO item displays in only one bar, per the current scheme.

Benefits:
1) User will always see the items they care about.
2) Bars will always be filled with interesting stuff, as long as enough items are AUTO or ON.
3) Size degrades consistently and not smaller than what the user will tolerate (Minimum size)
4) Items will not shift around when values change, because placement is based on maxWidth instead of current width.
5) Items will never disappear/appear just because a value changed.
6) Potentially less redrawing, since no shifting.

[EDIT] I think a user-driven solution like this is necessary when disparate modules are competing for the same screen real-estate. Arbitrary priority numbers from 3rd-party module developers cannot possibly represent what the user wants. Module developers would have to expose the LVinfo priority value through private UIs in order to give the user some kind of control. At that point the solution might as well be centralized like this.

[EDIT2] As a fail-safe, if an item value exceeds the width of its maxWidth, the layout will need to shift, and items could drop off, potentially even ON items. Robust module development could alleviate some, but not all cases. For example, max ISO could be known for a given camera, so that the maxWidth is absolutely correct. But lens characteristics are unknowable, so the lens.c needs to make some guesses and be wrong sometimes.

[EDIT3] If this solution is untenable due to wasted space from excessive maxWidth, then I propose replacing ON with "ON, important" and AUTO with "ON". In this scheme, "ON, important" sets the high bit of the item priority, making it super high. "ON" leaves the priority as is, and OFF is OFF. This model is not deterministic and items still shift/fall off when values change. For clarity I'll restate it completely here:

Alternate Plan:

- LVinfo implements a dynamic menu for each bar. Each menu has all the same items by name, alphabetcally:

       Top bar                                         ON                      Q>
                Minimum size                       Small
                Aperture                              ON, important
                Dynamic range                     ON
                Focus mode                         ON, important
                Focus distance                     OFF
                ...etc

- Modules register their items with LVinfo, but display of items is governed by the user setting ON, ON Important, or OFF for each item.
- All items are ON by default. Display of ON and 'ON, important' items is per the priority scheme, with 'ON, important' at a higher priority tier.
- The 'Minimum size' menu item determines the smallest font size the user is willing to tolerate in the bar. All items within a bar use the same font.
- Items set to OFF will never display
- Display of items is per the following:

     All OFF items don't display.
     'ON, important' and ON items display in priority order from the horizontal center of the bar.
     A bar drops to whatever size is necessary to display as many 'ON, important' and ON items as possible; but not smaller than 'Minimum size'.
     ON items are dropped from the outskirts when space is unavailable.
     'ON, important' items are dropped next when space is unavailable.
     An ON item displays in only one bar.

Benefits:
1) User is more likely to see the items they care about.
2) Bars will always be filled with interesting stuff, as long as enough items are 'ON, important' or ON.
3) Size degrades consistently and not smaller than what the user will tolerate (Minimum size)

Drawbacks:
1) Still possible for important items to disappear unexpectedly due to width.
2) Layout will shift regularly as values change

[EDIT4] Rather than to add items from the center out, it's probably better to go left to right. This way priority and order are the same. In this model items always drop off on the right:





items L -> Rbatt%lengthapertureshutterISOWBISfocus mode
module priority  10097969594939998
user priorityImportant   Important   Important   Important   Important   Important   ON    ON   


Sorry for waffling. This is a tough one. I'll keep going until I think it's the best compromise. Please poke holes.
Title: Re: Bars facelift
Post by: Doyle4 on October 02, 2013, 12:51:22 AM
(http://i40.tinypic.com/v5cmyc.jpg)

Update: Beeping starts when the cm's reading appears in bottom right, it appears at 1/8th of shutter and below, when above 1/8th the cm's reading disappears and the beep stops.
Title: Re: Bars facelift
Post by: 1% on October 02, 2013, 06:31:02 AM
on 7D this screen shot is pretty accurate... including the CMcm (focus distance?)... also FPS display please?

Ok, CMCM is gone after a make clean...

(http://i.imgur.com/CIHD6OPl.png)
Title: Re: Bars facelift
Post by: Doyle4 on October 02, 2013, 12:15:19 PM
Heres a vid of whats happening on the 600..

Title: Re: Bars facelift
Post by: a1ex on October 02, 2013, 01:11:23 PM
Small updates:

- focusing back and forth should no longer disrupt the layout (it should settle quickly)

- more indicators ported: FPS, free space, MVI number

- audio meters integrated in the new layout (so if at some point you will have a menu and remove everything else from the top bar, the meters will expand to be full screen, otherwise they stay small).

- degradation algorithm: first shrink one item, then two, then all of them, and only after that start dropping items. Rationale: if I enable dual ISO and the ISO string gets long, I prefer to show only that one in small font, and keep the rest of the bar in large font (more readable). But at some point, items with mixed size start to look bad, and in this case it shrinks the entire bar.

- some more smaller changes (https://bitbucket.org/hudson/magic-lantern/commits/).

Nightly builds are being recompiled right now.
Title: Re: Bars facelift
Post by: Doyle4 on October 02, 2013, 01:17:06 PM
Could it possible when Dual iso is enabled the ISO font is say green to allow the user to know Dual iso is enabled just incase they forgot it was on n snap away without realising, when disabled its back to white?
Title: Re: Bars facelift
Post by: Doyle4 on October 02, 2013, 01:22:58 PM
Beep has stopped, and cm no longer disappears, nice  :)
Title: Re: Bars facelift
Post by: a1ex on October 02, 2013, 04:33:53 PM
For the histobar, I'd like a way to show the following things:

- midtone level (median)
- shadow level (5th percentile)

These things are used in ETTR, and you can see at a glance how much noise you are getting in the picture. When ETTR is enabled, and the SNR drops under limits (that is, these midtone and shadow levels are to the left of what you have selected in ETTR menu), I'd like a noise warning too (which will explain why ETTR choose to blow some highlights when it does).

A standard representation for these things is the box plot: http://en.wikipedia.org/wiki/Boxplot

I've tried half-filled bars and different colors, but couldn't get an intuitive indication. In particular, the midtone level (median) means half of the image is brighter than that, and the shadow level means that anything darker than it is likely insignifiant.

Right now I'm trying a yellow box for the median point and 1/3-filled boxes (to suggest insignifiant) for levels under the shadow one.

Ideas?
Title: Re: Bars facelift
Post by: stevefal on October 02, 2013, 04:43:02 PM
I'll work on some ideas..
Title: Re: Bars facelift
Post by: platu on October 02, 2013, 06:14:39 PM
Great work on the updated bars. 

A few things I noted...

-The shutter speed on the bottom bar doesn't match the one in the menu (shows as 1/51.3 in menu... and 1/63 on bottom bar).  This issue occurs in movie mode only... photo mode is fine.

-The temperature indicator on the top bar shows a caution condition relatively quickly so most of the time shooting, you will end up with a bright colored indicator always on.  Maybe the threshold for the caution indicator should be relaxed a bit.  My settings... movie mode, raw zebras, focus peaking, histobar all turned on.

The time indicator disappears quite often I assume to dynamically make space on the bar.   I have both Histobar and Ettr hint active.  It happens whenever the ETTR hint displays a negative value such as -0.1 but when the value is positive, the time indicator reappears.  So you end up with the time dissapearing and the histobar and everything else shifting to the left whenever the ETTR hint shows a negative value.  Again, this occurs only in movie mode.... photo mode is fine.

Title: Re: Bars facelift
Post by: stevefal on October 02, 2013, 06:17:38 PM
@a1ex, I don't understand shadow level. With your current draft, half boxes can appear anywhere in the range. Are you saying that in the context of ETTR, the bottom 5th percentile of the image is considered "shadow"? I don't understand why you see it as insignificant. In a low DR image it could be clean and very significant.

Likewise, how does the user consume knowledge of the midpoint?

Between the advanced abstractions in your head and the concrete ignorance of an average user - that's the gap I want to bridge. Can you explain each concept you want visualize, and

- what it is mathematically
- how the user should interpret it concretely
- how the user should act on it
- scenarios/caveats that undermine anything

If we break this down precisely, I bet we can make something intuitive.
Title: Re: Bars facelift
Post by: 1% on October 02, 2013, 07:00:38 PM
Looks hot right now.

(http://i.imgur.com/8FF412il.png)
7D idle
Title: Re: Bars facelift
Post by: a1ex on October 02, 2013, 07:19:54 PM
@stevefal:

Midtone level:
- mathematically: median (which is a statistically robust indicator for overall exposure)
- interpretation: if it's too much on the left side (SNR too low), your image is likely too noisy
- how you should act: if it's too much on the left, and you still have clipped highlights, you should consider clipping more highlights or using HDR / dual ISO / change lighting / using a Nikon camera...
- note that you can find it pretty much anywhere in the highlighted range (not in the middle)
- caveats: I believe only images half-bright and half-dark, with a clear straight line between the two regions, can trick it (just look at timelapses deflickered with post deflicker to see how robust this indicator really is in practice).

Shadow level:
- mathematically: the value below which you have 5% of pixels (see http://en.wikipedia.org/wiki/Percentile )
- interpretation: underexposure warning on these boxes can be ignored (e.g. if you have clipped highlights and don't know of what to get rid first)
- what you should do: if you see both half-underexposure and overexpoure warnings, you should probably just move the exposure to the left and ignore the shadows; but if you see full underexposure and overexposure warnings, you should think whether you are OK with crushing some blacks / clipping some highlights / trying dual ISO / etc.
- caveats: maybe a tiny black cat in snow could be indicated as insignifiant? I think it's hard to find tricky scenes in practice, since this one is also a statistically robust indicator (not as robust as median, but still very good).

- note that half boxes appear only on the leftmost side (so the only sequence possible is empty, half, full, empty). If not, post a screenshot.
- in a low DR image, the levels under the 5th percentile will be very close to the minimum point => nothing printed
- in a high DR image, trying to bring these levels to a relatively low SNR (even just 2-3 EV) is very likely to require severe highlight clippng => better accept underexposure in these levels

If ETTR is enabled:
- midtone SNR set to 6 EV and midtone level is on box 4 => you have 2 stops more noise than you have asked for in ETTR menu => boxes 4 and 5 may show a noise warning (not implemented)
- same for shadow level, just with different numbers
- with this, it should be straightforward to understand the meaning of the SNR limits from the ETTR menu (because you see them in real-time)

Here's an example of what exactly is 2 EV of SNR (12 dB = 2 EV):
http://photography-on-the.net/forum/showthread.php?t=1326078&page=2&highlight=snr
Title: Re: Bars facelift
Post by: stevefal on October 02, 2013, 07:49:21 PM
Thanks, that's helpful. Please clarify re: Midtone: "note that you can find it pretty much anywhere in the highlighted range (not in the middle)"

Given that the number of involved pixels is intrinsic in these indications, I think it goes against the extreme dumbification that histobar represents. That's ok though! I will try to re-imagine a simple histogram that doesn't hide so much about distribution, and therefore makes such area-bound concepts visible. Then I think we can treat the areas visually to convey their qualities. Is this the right list of qualities?

- clipped low, aka black
- noisy
- well exposed
- clipped high, aka white
Title: Re: Bars facelift
Post by: a1ex on October 02, 2013, 08:15:38 PM
Clarification: I simply pointed the camera all around the room, and the median point changed from both extremes:

- In a HDR scene with the camera pointed to the window (and most of the image being dark walls), the median was on the far left, but the overexposure warning was enabled.

- In a low DR scene (say a blank wall), the median was towards the right, and there were some "shadow" levels which I guess they come from vignetting. In this case, the apparent dynamic range indicated by the simplified histobar was misleading (since it was showing 4-5 stops, but most of the stuff was concentrated within 1 stop; but the other stops were below the "shadow" level, so in my version you could see the real distribution at a glance).

- In regular scenes, the median will probably stay close to the arithmetic mean, and be somewhere in the middle.

Qualities:
- Noisy blacks (hard to say "clipped" here, since it's just too much noise). Can be hidden by crushing blacks (curves).
- Noisy midtones. Can't be hidden easily, so these are very important to avoid IMO.
- Well exposed (as in "not noisy" and "not clipped")
- Properly exposed to the right (see the posts from audionut); one-stop resolution may not be good enough to show this, but half-stop is just perfect IMO.
- Small specular highlights clipped (a good threshold for them is 0.1% IMO; current boxes are displayed at 0.01%). Can be ignored most of the time, except for skintones.
- Clipped highlights.
- Optional: show what channels have clipped highlights (since with some subjects and good highlight recovery algorithms you can safely clip one of the channels, especially the green one).

Note: "noisy" is only well-defined if you look at SNR limits from ETTR (these indicate the noise threshold you are OK with).
Title: Re: Bars facelift
Post by: swinxx on October 02, 2013, 10:39:05 PM
just for information:

when i use raw 1920x1288 the bars are white:
(http://i.imgur.com/rhQOi9R.png)

keep on doing great things. sw
Title: Re: Bars facelift
Post by: 1% on October 02, 2013, 11:30:04 PM
Here is the CMCM with lens not reporting FD.. FL is in its place... from 6D

(http://i.imgur.com/qhxX0zk.png)
Title: Re: Bars facelift
Post by: Greg on October 03, 2013, 01:54:59 AM
Looks good ;)

500D (live view, screen layout 16:10) :
(http://imageshack.us/a/img822/2586/2vrm.png)
Title: Re: Bars facelift
Post by: Marsu42 on October 03, 2013, 02:10:33 AM
Quote from: g3gg0 on September 28, 2013, 10:20:00 PM
i will extend flexinfo to be usable for both photo and LV mode. additionally i will add dynamic content support. ;)

Does this mean we'll be able to reduce the two bars down to one?

The current layout looks excellent, no doubt about it, but duplicates a lot that I can already see on the top lcd or don't care about at all - but having a bar on top/bottom or two bars on bottom is bad for photo lv composition, while turning them off completely is no option either b/c I want a few items there.
Title: Re: Bars facelift
Post by: stevefal on October 03, 2013, 02:40:56 AM
Here's a pass at a higher fidelity histobar per discussion with @a1ex:

(http://i.imgur.com/14JwUjX.gif)

Features:

- half-height "dark tail'
- midpoint indicator
- 1/2 stop resolution (11 stops shown)
- compressed quantitative "clip" indicators

This is more complicated to draw, but the benefit is dense information that still shows up within the color scheme. I have not formalized the math and I rely on a1ex et. al. to infer meaning and choose thresholds etc.

Unlike the previous histobar, the clip indicator are outside the DR, and are meant to grow as clipping pixel count increases. However they are compressed, in that they should grow at a decreasing rate in order to minimize width - probably logarithmic.

Note that the example may not be mathematically self-consistent. I'm mainly trying to establish a workable visual language.
Title: Re: Bars facelift
Post by: RenatoPhoto on October 03, 2013, 02:45:39 AM
Quote from: stevefal on October 02, 2013, 06:17:38 PM
If we break this down precisely, I bet we can make something intuitive.
Maybe you can get some hints from ETTR module > Advance > Show metered areas
This will show where the shadows, mids, and highlights are located.
Now if you could take the pixels of this display and shrink it to a tiny image, sharpen it, brighten it,  you could use it as a quick display of the areas affected.  By changing the brightness of the pixels (of the three zones) you could represent the effects of different SNR combinations.
Title: Re: Bars facelift
Post by: stevefal on October 03, 2013, 02:53:31 AM
If only dark-tail pixels are clipping, the clip indicator could be half-height as well, in order to help excuse sacrificing those first:

(http://i.imgur.com/BeJri8O.gif)

Then once those are gone, the clip indicator would go full-height to show you're clipping over the 5th percentile (or whatever).
Title: Re: Bars facelift
Post by: Audionut on October 03, 2013, 03:31:18 AM
Quote from: stevefal on October 03, 2013, 02:40:56 AM
- half-height "dark tail'
- midpoint indicator
- 1/2 stop resolution (11 stops shown)
- compressed quantitative "clip" indicators

IMO, you've made it to complicated stevefal.  With the DR indicator showing 11 stops with 11 bars, it's easy to see the what each bar represents.  Also, I think 1 bar = 1EV seems the most appropriate, anything else seems counter-intuitive.

If the highlights are 3.5EV below saturation, with this implementation I would have to count 7 empty bars to be sure how far I am underexposed.
Using half (full) bars I can see very quickly that the top 3 stops are empty and the forth stop is half full.  There is less information to process.  Also, If I don't care about being very accurate, I know (very quickly) I can raise exposure 3 stops and be there or there abouts.
I have suggested (https://bitbucket.org/hudson/magic-lantern/commits/dfc00f9c0129d91fd1f5dbbe0799b55ae9f81a7f) to a!ex to use shading in the shadow areas also (rather then 1/3 bars).
Title: Re: Bars facelift
Post by: stevefal on October 03, 2013, 03:53:02 AM
Of course the same design could be drawn in 1 stop resolution - 11 lights. I personally like the idea of 1/2 stop increments when my Av/TV hardware is set to 1/2 stop per click. One click = one light.

I think you are saying you'd prefer 11 boxes, and each box fills in two steps - horizontally - right? It's essentially what I've drawn with every other dividing line removed.

I wouldn't exactly say that's less complicated than what I've drawn, because it introduces two different step types - half steps and whole steps, versus "steps" (or clicks, for me). But it would map better to the way exposure is discussed numerically. I personally do things visually/graphically, so I don't think in terms of "3.5EV below saturation." That's what I figure the numeric ETTR indicator is for.

I'm interested in other feedback on this too. Thanks audionut.
Title: Re: Bars facelift
Post by: Audionut on October 03, 2013, 04:24:20 AM
What if the user is in 1/3rd stops?
With 1 bar = 1EV, you (should) know based on your exposure level increments how many clicks are needed.  2 clicks for half stops, 3 clicks for third stops.

With twice the number of boxes representing the same information, I don't see how it is anything but more complicated. 

Boxes filled in 2 steps vertically would be a better option imo.

Quote from: stevefal on October 03, 2013, 03:53:02 AM
I wouldn't exactly say that's less complicated than what I've drawn, because it introduces two different step types - half steps and whole steps, versus "steps" (or clicks, for me).

Because you have the option to ignore the half steps.  You can simply count the empty boxes.  Where the exposure is 3 stops under, there are only 3 boxes to count, not 6.   With 1 bar = 1EV, there is always half the number of boxes to count vs 1 bar = 0.5EV.  Half filled boxes provide the extra resolution only where needed.
Title: Re: Bars facelift
Post by: stevefal on October 03, 2013, 07:21:39 AM
I could personally go along with any variety of ways regarding number of boxes and how to draw them. But the idea of filling them alternately vertically and horizontally makes no graphical sense. If the horizontal axis connotes light in stops/substops, then subdivisions of light should absolutely be oriented horizontally. There's no way that a user could intuitively infer that the vertical axis *also* represents stops.

Think about histobar like this: A traditional exposure histogram represents distribution of light with maximum horizontal resolution (value) and vertical resolution (quantity). As such it provides a detailed picture of the distribution. But it has drawbacks: 1) distributions often have skinny tails and peaks that, although important, are had to see; 2) the relationship between light distribution and camera stops is not always apparent; and 3) scene content that the photographer considers outside the dynamic range of the camera are nonetheless squeezed into the visualization of what's "in" the picture.

Histobar essentially quantizes both dimensions of the histogram so that 1) skinny tails has as much visual weight as fat bellies, 2) level distributions are binned in stops, 1/2 stops etc. and 3) out of range values are accounted for outside the normal values (in the latest concept).

The extreme vertical quantization is like saying to the user, "There are enough pixels at this level that you are going to try to expose them properly." With a1ex's request for demoting the lower 5th percentile, it says, "There are less worthy pixels here (due to likely noise), so try to expose them, but sacrifice these first"

So in the the latest concept, the vertical axis represents the worthiness of the pixels. There are two worthiness values - high and low.

I agree that horizontal steps should be designed so the user can intuitively and quickly dial in exposure. Whereas the latest concept has 22 steps, I can try to draw an 11x2 and/or 11x3 approach too. But I'd like to hear from more people first.

Title: Re: Bars facelift
Post by: Audionut on October 03, 2013, 08:04:23 AM
a1ex currently has them 1/3rd filled for shadow areas that are under some 5th percentile thingy.  No user could ever possible see that as intuitive.  My first response when seeing that, "why are the bottom stops only 1/3rd full".
Hence why I believe a lighter shading of the clipped shadow indicator would be preferred.  In this way, I have a direct visual clue that those (lighter shaded) areas must have some representation of the shadow areas.  I can use different shades of blue to determine that.  I'm smart enough for that!


The vertical distribution in a histobar has no meaning other then the one we apply.

I imply to use the vertical axis, as the graphical representation will be easier to see at a glance then a horizontal axis distribution.

I would go further to say that the vertical distribution in the bar (bucket) could be directly related to the EV difference from the next stop.  ie:  Where the exposure is 0.7EV from the next stop, the bar could be filled 30%.  However, half stop resolution is probably sufficient.

My dumb brain finds it much easier to match the distribution of the vertical axis with exposure, rather then some weighting of priority based on some percentile.
Bar is full, I am at that exposure stop.  Bar is half full (regardless of axis), exposure is half of that stop.

One should always assume that the user will not rtfm.  That's not to say that my ideas are best.
Title: Re: Bars facelift
Post by: stevefal on October 03, 2013, 03:48:27 PM
QuoteThe vertical distribution in a histobar has no meaning other then the one we apply.

Hah, are you trolling me? I don't like to be pedantic (ok I do), but that's wrong. In UI design, everything has the meaning that the user applies. When the meaning that the user applies is the meaning we implemented, then it is intuitive. That isn't to say that any of these are are necessarily intuitive, but we should be able to agree what the word means. I'm game to discuss the science behind this, but we probably shouldn't here.

I'll try another concept that minimizes horizontal quantization, and uses a texture, rather than short lights, for the 'noisy tail'. This will address both of your issues in another way.
Title: Re: Bars facelift
Post by: tonybeccar on October 03, 2013, 03:49:35 PM
I agree with Doyl4, it'll be very functional to have indicators for which mode are you in, if you're in RAW maybe RAW is displayed with some background color, if dual iso, D.ISO for example, if the bitrate is changes maybe it could say the CBR factor, HDR for cameras that do not currently support dual iso, and so on! Indicators would we great!!! This interface is looking VERY professional!
Title: Re: Bars facelift
Post by: stevefal on October 03, 2013, 09:26:17 PM
Here's an approach that can re-quantize horizontally without looking too busy.

(http://i.imgur.com/RomPX8y.gif)

Features:

- arbitrary sub-stop scale - can be 1, 1/2, 1/3 without too much disruption
- noisy tail uses texture instead of height to convey quality
- data can plot horizontally on 1-pixel boundaries if desired  (I prefer quantizing to the tick marks)

Since this design is uniform height, it can also shortened and stacked as an advanced RGBL histobar:

(http://i.imgur.com/n4Xngmg.png)

Please note that I have not worked out exact metrics for convenient implementation of these. So tell me if you are interested and I can tweak so layout math is easier.
Title: Re: Bars facelift
Post by: Jakobmen on October 03, 2013, 09:34:04 PM
Quote from: stevefal on October 03, 2013, 09:26:17 PM
Here's an approach that can re-quantize horizontally without looking too busy.

(http://i.imgur.com/RomPX8y.gif)

Features:

- arbitrary sub-stop scale - can be 1, 1/2, 1/3 without too much disruption
- noisy tail uses texture instead of height to convey quality
- data can plot horizontally on 1-pixel boundaries if desired  (I prefer quantizing to the tick marks)

Since this design is uniform height, it can also shortened and stacked as an advanced RGBL histobar:

(http://i.imgur.com/n4Xngmg.png)

Please note that I have not worked out exact metrics for convenient implementation of these. So tell me if you are interested and I can tweak so layout math is easier.

I LIKE..
Title: Re: Bars facelift
Post by: Stedda on October 03, 2013, 09:53:34 PM
I like the advanced RGB a lot. Super quick way of getting the needed info!
Title: Re: Bars facelift
Post by: pravdomil on October 03, 2013, 11:01:50 PM
Good thoughts and what about this?
(https://bitbucket.org/pravdomil/ml/downloads/histobar%20advice.gif)

There will be a histobar with 8 + 2 blocks for MOV recording and 14 + 2 blocks for RAW recording.
It helps you to choose what color depth and exposure you should use.
Title: Re: Bars facelift
Post by: stevefal on October 03, 2013, 11:21:02 PM
Yep, 8<>14 was proposed initially: http://www.magiclantern.fm/forum/index.php?topic=8539.msg79396#msg79396

However I'm sure I'll never ever shoot H.264 again!
Title: Re: Bars facelift
Post by: pravdomil on October 03, 2013, 11:36:28 PM
I'm sometimes confused if the histogram/bar is 14Bit or 8Bit or whatever. There can be some graphical hint, that will tell you what color depth you are using.

btw: one stop of dynamic range is one bit?

thanks for your work
Title: Re: Bars facelift
Post by: SDX on October 03, 2013, 11:58:42 PM
QuoteI'm sure I'll never ever shoot H.264 again!
That's great to hear. I, amongst many others, however, will.
Title: Re: Bars facelift
Post by: a1ex on October 04, 2013, 12:15:14 AM
When the lower bins contain nothing but noise, why show them? The histobar shows how much useful range you have with the current settings, and how much you need.

Raw histogram for H.264 is pretty much ill-defined mathematically, because:
- clipping warnings don't match
- the curve is baked in
- I don't understand why it should have 8 stops (especially if the raw one has 5, for example)

Also, the delimitation of stops in the YUV histogram no longer makes sense, because it's totally dependent on the curves (the histogram no longer moves linearly with exposure). This is why I don't print any vertical bars on the YUV histogram.

Besides, I prefer to disable the raw mode when it's not in use (changes to Canon functionality should be minimally invasive IMO - that is, only applied when needed, so if you turn off everything it should behave like standard Canon firmware).
Title: Re: Bars facelift
Post by: pravdomil on October 04, 2013, 12:39:28 AM
Quote from: a1ex on October 04, 2013, 12:15:14 AM
- I don't understand why it should have 8 stops (especially if the raw one has 5, for example)
So I would rather show 8 bits instead of 8 stops.
0 block - the first on the left side - shows under exposure - if count of pixels with brightness value 0 > threshold fill this block
1 block - second -  if count of pixels with brightness value 1-31 > threshold fill this block
..
..
8 block - last but one -  if count of pixels with brightness value 223 - 254 > threshold fill this block
9 block - last one - shows overexposure -  if count of pixels with brightness value 255 > threshold fill this block

if RAW is enabled extend this range to 14 + 2 and do the same
Title: Re: Bars facelift
Post by: a1ex on October 04, 2013, 12:48:09 AM
Quote from: pravdomil on October 04, 2013, 12:39:28 AM
if RAW is enabled extend this range to 14 + 2 and do the same

Why 14 if at least 3 of them are just noise?
Title: Re: Bars facelift
Post by: pravdomil on October 04, 2013, 12:50:30 AM
So only 11 + 2
Title: Re: Bars facelift
Post by: stevefal on October 04, 2013, 01:01:06 AM
@A1ex, any feedback on my last two concepts which were meant to address wants/issues you raised??

I'm still not completely clear about how much we know about the 5th percentile. Here's one with a shaded tail, rather than a noisy tail:

(http://i.imgur.com/egqtkcb.gif)

Is the RGBL version interesting? Are you saying that it should not have ruler marks?
Title: Re: Bars facelift
Post by: stevefal on October 04, 2013, 01:22:51 AM
This is my favorite so far. 22-light concept with full-height shaded dark tail:

(http://i.imgur.com/c3pLu3D.gif)
Title: Re: Bars facelift
Post by: wolf on October 04, 2013, 01:29:22 AM
Looks very good, but what confuses me, is why the blue and red tile runs out of the border.
Title: Re: Bars facelift
Post by: stevefal on October 04, 2013, 02:20:01 AM
Those are intended to represent clipped pixels. In the original concept. I changed the color of the top and bottom tiles, but that gives no indication how much clipping is going on.

In these later concepts, the clip indicators (red and blue) grow outside the bar, at a decreasing rate, to show how much clipping is going on. In a traditional histogram this fact is shown only by the height of a one-pixel vertical line at the edge of the graph - it is very hard, if not impossible to see.
Title: Re: Bars facelift
Post by: Audionut on October 04, 2013, 04:45:02 AM
Quote from: stevefal on October 03, 2013, 03:48:27 PM
Hah, are you trolling me?

Of course not!  Just because I have ideas that do not fit in with the "science of GUI design" does not make my opinions nefarious.


I personally think that the EV indicators should remain visible (as in the last screen shot).
The shaded tail looks great.
The RGBL histo is excellent.
The growing over/under exposure indicators are excellent.
I still think 11 is better then 22, regardless of how the indicators should be filled.
Title: Re: Bars facelift
Post by: stevefal on October 04, 2013, 04:54:34 AM
...and 33 would be pretty extreme. I'll try half-filling the lights horizontally to see how that looks.
Title: Re: Bars facelift
Post by: Audionut on October 04, 2013, 05:27:56 AM
Indeed.  I don't think you need to worry about any ticks (ruler marks) to indicate the half stops.  It should be clear when the bar is full or not and what that represents.

Quote from: stevefal on October 04, 2013, 01:01:06 AM
I'm still not completely clear about how much we know about the 5th percentile. Here's one with a shaded tail, rather than a noisy tail:

By having the tail shaded, there should only be a lack of understanding of its meaning.  There shouldn't be a misinterpretation.  As long as people aren't misinterpretation its meaning, those that are unsure of it's meaning always have the option of reading the manual.  Blue probably wasn't the right idea as noted by a1ex on the commit.
Title: Re: Bars facelift
Post by: a1ex on October 04, 2013, 06:49:55 AM
Also +1 for full stops. Only the last one is important to know whether it's full or half, actually.

There was even a feature request to show that last stop magnified, on the regular histogram.
Title: Re: Bars facelift
Post by: stevefal on October 04, 2013, 05:20:49 PM
This has a full-stop ruler. The data is illustrated as binned in 1/2 stops. It actually could be 1-pixels bins, but I don't think that resolution is helpful. I'm interested in the idea of binning according to the current resolution of the dial (or just user-configured). Or it could be halves and thirds, but that seem weird. Thoughts?

(http://i.imgur.com/v1xKZKy.gif)
Title: Re: Bars facelift
Post by: stevefal on October 04, 2013, 05:25:43 PM
@A1ex, does it really make sense for the dark tail to appear when in the high range? That is, shouldn't we only highlight the portion of the lower 5th percentile that falls below a certain exposure level?
Title: Re: Bars facelift
Post by: a1ex on October 04, 2013, 05:44:45 PM
For highlights, I'd go with 0.1% instead of 5%.
Title: Re: Bars facelift
Post by: stevefal on October 04, 2013, 05:54:40 PM
QuoteFor highlights, I'd go with 0.1% instead of 5%.

What are you saying?
Title: Re: Bars facelift
Post by: Audionut on October 04, 2013, 06:11:56 PM
That 5th percentile is that part of that exposure.  Where you want to consider that part (the bottom 5th percentile) of the exposure in your exposure decision, it's helpful to see where that lies in the histogram.

edit:  Even if it's towards the right hand side of the histobar imo.

If you can link the resolution to the dial, that would be useful.  Both together are unnecessary imo, and I don't see the point of adding another option (to the menu) that is only really useful depending on the current dial resolution anyway.
Title: Re: Bars facelift
Post by: CFP on October 04, 2013, 08:37:29 PM
Quote from: stevefal on October 04, 2013, 05:20:49 PM
(http://i.imgur.com/v1xKZKy.gif)
This looks really good. Much better than these versions with more than 11 Boxes. I love it.
Title: Re: Bars facelift
Post by: stevefal on October 05, 2013, 12:46:25 AM
On external monitors, the old bars displayed right at the upper and lower edges. The new bars are displaying farther in and interfere with cropmarks. This is on SmallHD DP6.

(http://i.imgur.com/mISliVI.png)
Title: Re: Bars facelift
Post by: RenatoPhoto on October 05, 2013, 02:54:17 AM
With so many options for frame size and aspect ratio I would add this info to the proposed facelift.  1920x1080 16:9
Title: Re: Bars facelift
Post by: stevefal on October 05, 2013, 04:18:24 PM
I'm trying to add a rawrec record indicator to the top bar. In this example, can you explain why space is reserved for the string buffer outside 'if (lens_info.IS)'?

static LVINFO_UPDATE_FUNC(is_update)
{
    LVINFO_BUFFER(4);

    if (lens_info.IS)
    {
        int is_color =
            lens_info.IS == 0 ? COLOR_WHITE    :  // IS off
            lens_info.IS == 4 ? COLOR_GRAY(50) :  // IS active, but not engaged
            lens_info.IS == 8 ? COLOR_BLACK    :  // IS disabled on sigma lenses?
            lens_info.IS == 0xC ? COLOR_CYAN   :  // IS starting?
            lens_info.IS == 0xE ? COLOR_WHITE  :  // IS active and kicking
            COLOR_RED;                            // unknown
        snprintf(buffer, sizeof(buffer), "IS");
        item->color_fg = is_color;
    }
}
Title: Re: Bars facelift
Post by: a1ex on October 05, 2013, 04:24:42 PM
The string buffer is declared at the beginning of the function by design.

If the "if" is not executed, you will end up with an empty buffer (so in this case, the item gets disabled if there's nothing to show).
Title: Re: Bars facelift
Post by: stevefal on October 05, 2013, 05:13:51 PM
I see, that has the effect of clearing it from the bar. Thanks.
Title: Re: Bars facelift
Post by: stevefal on October 05, 2013, 05:45:03 PM
Just a nit but not sure why this xx:xx text isn't centering perfectly:

(http://i.imgur.com/H37tcFW.png)

static LVINFO_UPDATE_FUNC(raw_rec_update)
{
    LVINFO_BUFFER(6);
   
    if (RAW_IS_RECORDING)
    {
        int fps = fps_get_current_x1000();
        int t = (frame_count * 1000 + fps/2) / fps;
       
        snprintf(buffer, sizeof(buffer),
                 "%02d:%02d",
                 t/60, t%60
                 );
        item->color_bg = COLOR_RED;
    }
}
Title: Re: Bars facelift
Post by: a1ex on October 05, 2013, 05:58:01 PM
The red bar starts from the midpoint between the current item and neighbouring ones (Voronoi cell), so it may not be symmetrical at the ends. I could expand it till the border, but then it looks a bit odd in photo mode on the gray layout with transparent ends (as in the first mockup).

It's like this: <BORDER><glue halfwidth><glue halfwidth><ITEM><glue><glue><ITEM><glue><glue><ITEM><glue halfwidth><glue halfwidth><BORDER>

So, the two glue boxes near each item will borrow the item color. Border color is transparent in photo mode and black in movie. This gives the transparent area from the ends of the bar.

This trick has 3 roles:
- extend the highlight background a little beyond the tight text border
- if two nearby items have the same highlight color, the entire bar between them will get the same color (example: the highlighting for exposure override)
- if two nearby items have different highlight colors, do not leave a gray gap between them (needed?)

The glue boxes from the ends are half-width, because otherwise it looks odd to me. This is causing the asymmetrical highlighting.
Title: Re: Bars facelift
Post by: stevefal on October 05, 2013, 06:26:37 PM
QuoteThe red bar starts from the midpoint between the current item and neighbouring ones

This causes highlighted item footprints to change depending on the presence of other items. Worst case a very wide highlight if items are sparse.

Another approach would use a standard pad on each item, that borrows the item color. The glue is clear:

<BORDER><pad><item><pad><glue><pad><item><pad><glue><pad><item><pad><BORDER>

True that this could occasionally show space between adjacent highlighted items, but I see that as a plus, since they are separate items. The main advantage is that the item silhouette does not change unless it's own content changes. Also solves the artifact on the ends.
Title: Re: Bars facelift
Post by: stevefal on October 05, 2013, 06:37:04 PM
This idea would affect how the sparse case would look too: http://www.magiclantern.fm/forum/index.php?topic=8539.msg79826#msg79826.

Also, in the <glue><ITEM><glue><glue><ITEM><glue> case where both have the same highlight color, the items will appear to have more space between them than at the ends. That's an artifact of letting the colors run together.

In <pad><item><pad><glue><pad><item><pad> solution, I think glue should have a minimum width of a few pixels, to prevent that from happening. They are two items.
Title: Re: Bars facelift
Post by: a1ex on October 05, 2013, 06:41:40 PM
Quote from: stevefal on October 05, 2013, 06:37:04 PM
That's an artifact of letting the colors run together.

Enable exposure override and look at aperture, shutter and ISO; in this case I think it would be an artifact if I'd leave a gap between them.
Title: Re: Bars facelift
Post by: stevefal on October 05, 2013, 06:48:20 PM
Maybe they should be one item.
Title: Re: Bars facelift
Post by: a1ex on October 05, 2013, 06:53:03 PM
In this case I can no longer let the layout engine adjust the spacing between them.
Title: Re: Bars facelift
Post by: stevefal on October 05, 2013, 10:27:47 PM
I'm not arguing one way or the other, but it's ours to say whether we regard it as one thing or three things. For example, would you want other indicators to appear between those three items?

And as it is, if they were the only things on the bar, would you want the whole bar highlighted? I wouldn't.

I'm a stickler for model purity, because it's the only thing that holds up in the long run. Currently, highlighting adjacent items with the same color makes them look visually joined. One might like that in this instance, but it wouldn't be desirable in a case where the indicators are totally unrelated. So, for better or worse, I think we should design the model to be pure, even if that means separation, which, afterall, isn't so bad. I'm passionate visual polish, but clear communication comes first.

Since the API does not provide a mechanism to group items, an indicator is either a singular item (and should look that way, I argue), or multiple indicators can be implemented in a single item, and will appear that way. So maybe all three are an "exposure" item that moves, highlights and shrinks as a unit. Or maybe they are three items that always look like three items. Letting three items look like one leads to artifacts, of which we've identified some so far: inadvertently 'joining' unrelated items and the end-spacing issue.
Title: Re: Bars facelift
Post by: SMPse on October 06, 2013, 08:52:32 PM
Nice and clean, but I would still want to quickly be able to see if there's any WBShift applied, since I've got lenses that need all sorts of correction. So let's not make the bars too clean.. ;)
Title: Re: Bars facelift
Post by: a1ex on October 06, 2013, 09:15:00 PM
Yep, a mockup for WBshift would be nice. My old approach was to show magenta WBShift in magenta color, green WBShift in green color and so on.
Title: Re: Bars facelift
Post by: SMPse on October 06, 2013, 09:28:35 PM
Thanks a1ex, I really like that approach. I have e.g. a lens that needs Mangenta 8, and that wouldn't look good on many other lenses, if I should forget to change.
Title: Re: Bars facelift
Post by: stevefal on October 06, 2013, 10:16:20 PM
How about a little patch in front of the text:

  WBShift

I included a rounded rectangle patch in argnor28.rbf.

It would be neat if ML printing supported inline color escape codes for stuff like this.
Title: Re: Bars facelift
Post by: a1ex on October 06, 2013, 10:48:49 PM
I like the idea of escape codes.

This sounds good to me, but looks a bit complex at first sight: http://en.wikipedia.org/wiki/ANSI_escape_code#Colors

If I could use the same escape sequences in the Linux console to try out stuff, it would be pretty nice.
Title: Re: Bars facelift
Post by: stevefal on October 07, 2013, 05:49:34 PM
How about something like:

("This is \c#ff0000[red]")
("This is \c"COLOR_RED"[red]")
Title: Re: Bars facelift
Post by: tonybeccar on October 10, 2013, 09:02:50 PM
I find this awesome!! But I have a doubt.. is this customizable? I think I read somewhere that it was.. but cannot find the setting anywhere on the menu.. am I doing something wrong? Is there a module I don't have?
Title: Re: Bars facelift
Post by: SpcCb on October 30, 2013, 06:06:45 AM
Is it normal to see text in the bottom bar go smaller after ~2s when LV is activated?
Ah OK, I understood; after took a look in the code I see text size is dynamically change to fit on screen.
Title: Re: Bars facelift
Post by: 1% on November 05, 2013, 04:44:46 PM
FYI, everyone who records GD off can't really use the red top bar indicator for raw :)
Title: Re: Bars facelift
Post by: eikerir on November 12, 2013, 11:13:50 PM
Hi, i'm using the latest Nightly Build for the 600D and i'm loving the current facelift.

One question, is the time indicator not working? i can't see it anywhere on the screen, so i have no idea how long my shot has been or much time i have left before it cuts off.

Thanks for any help, cheers!