Bars facelift

Started by stevefal, September 28, 2013, 08:50:23 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Doyle4

Quote from: stevefal on September 29, 2013, 12:12:24 AM
"Histobar":


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.

stevefal

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.
Steve Falcon

Doyle4

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

Audionut

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

stevefal

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.
Steve Falcon

Audionut

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. 

Doyle4

tbh i just downloaded latest build n i would say all is great dude, i spotted the ettr number.. very nice ;)

a1ex

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

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.

wolf

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:

Rewind

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

stevefal

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.
Steve Falcon

stevefal

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?
Steve Falcon

Doyle4

Could the histobar be something like this? i actually miss the histogram..


a1ex

Quotei actually miss the histogram..

Just turn it on ;)

xNiNELiVES

Where are the semi transparent bars like the first photos posted? On actual screenshots I see only a black bar.

a1ex

The screenshot does not contain transparency, you need to add it manually in Paint.

stevefal


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.
Steve Falcon

stevefal

Another idea is to grow the bars from the center in order to obscure as little as possible.

Steve Falcon

Doyle4

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?

Doyle4

When using stevefal interface, when in LV my 600d beeps once every second.

a1ex

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

stevefal

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.
Steve Falcon

a1ex

In movie mode, DR is computed on the fly, from noise. Maybe it's a rounding issue.

stevefal

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.
Steve Falcon

stevefal

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.
Steve Falcon