Author Topic: Bars facelift (Read 123012 times)

a1ex · « **Reply #100 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.

stevefal · « **Reply #101 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?

stevefal · « **Reply #102 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?

a1ex · « **Reply #103 on:** October 04, 2013, 05:44:45 PM »

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

stevefal · « **Reply #104 on:** October 04, 2013, 05:54:40 PM »

Quote

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

What are you saying?

Audionut · « **Reply #105 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.

CFP · « **Reply #106 on:** October 04, 2013, 08:37:29 PM »

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 · « **Reply #107 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.

RenatoPhoto · « **Reply #108 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

stevefal · « **Reply #109 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)'?

Code: [Select]

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

a1ex · « **Reply #110 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).

stevefal · « **Reply #111 on:** October 05, 2013, 05:13:51 PM »

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

stevefal · « **Reply #112 on:** October 05, 2013, 05:45:03 PM »

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

Code: [Select]

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

a1ex · « **Reply #113 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.

stevefal · « **Reply #114 on:** October 05, 2013, 06:26:37 PM »

Quote

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

stevefal · « **Reply #115 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.

a1ex · « **Reply #116 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.

stevefal · « **Reply #117 on:** October 05, 2013, 06:48:20 PM »

Maybe they should be one item.

a1ex · « **Reply #118 on:** October 05, 2013, 06:53:03 PM »

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

stevefal · « **Reply #119 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.

SMPse · « **Reply #120 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..

a1ex · « **Reply #121 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.

SMPse · « **Reply #122 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.

stevefal · « **Reply #123 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.

a1ex · « **Reply #124 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.

News:

Author Topic: Bars facelift (Read 123012 times)