Bars facelift

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

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

a1ex

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.

stevefal

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?

Steve Falcon

stevefal

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

a1ex

For highlights, I'd go with 0.1% instead of 5%.

stevefal

QuoteFor highlights, I'd go with 0.1% instead of 5%.

What are you saying?
Steve Falcon

Audionut

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.

CFP

Quote from: stevefal on October 04, 2013, 05:20:49 PM
This looks really good. Much better than these versions with more than 11 Boxes. I love it.

stevefal

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.

Steve Falcon

RenatoPhoto

With so many options for frame size and aspect ratio I would add this info to the proposed facelift.  1920x1080 16:9
http://www.pululahuahostal.com  |  EF 300 f/4, EF 100-400 L, EF 180 L, EF-S 10-22, Samyang 14mm, Sigma 28mm EX DG, Sigma 8mm 1:3.5 EX DG, EF 50mm 1:1.8 II, EF 1.4X II, Kenko C-AF 2X

stevefal

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;
    }
}
Steve Falcon

a1ex

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

stevefal

I see, that has the effect of clearing it from the bar. Thanks.
Steve Falcon

stevefal

Just a nit but not sure why this xx:xx text isn't centering perfectly:


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;
    }
}
Steve Falcon

a1ex

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.

stevefal

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

stevefal

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

a1ex

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.

stevefal

Maybe they should be one item.
Steve Falcon

a1ex

In this case I can no longer let the layout engine adjust the spacing between them.

stevefal

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

SMPse

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

a1ex

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.

SMPse

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.

stevefal

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

a1ex

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.