Display (bitmap overlay) - page 3 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 [3] 4 5 6 7 8 ... 41   Go Down

Display (bitmap overlay)

  • 402 Replies
  • 102194 Views
*

Offline Ant

  • *****
  • 509
Re: Display (bitmap overlay)
« Reply #20 on: 04 / February / 2017, 14:55:31 »
Advertisements
On EOS M3 I use modified argnor32.rbf  from Magic Lantern.
But it doesn't contain non latin glyphs.



Why CHDK doesn't use Canon fonts?
« Last Edit: 04 / February / 2017, 14:57:03 by Ant »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #21 on: 05 / February / 2017, 09:28:50 »
Quote from: Ant on 04 / February / 2017, 14:55:31
On EOS M3 I use modified argnor32.rbf  from Magic Lantern.
But it doesn't contain non latin glyphs.
You could convert just about any font you'd like (there are 2 rbf converter utilities). Why are you using a partial font that even has ML-specific chars in place of accented chars?
Quote
Why CHDK doesn't use Canon fonts?
1) Because "we" don't know how.
2) They are too large and may lack some characters we're using.
I only see one potential use - if someone made a non-ASCII version of CHDK (Chinese, Japanese, Arabic, etc.).
Logged
*

Offline Ant

  • *****
  • 509
Re: Display (bitmap overlay)
« Reply #22 on: 05 / February / 2017, 11:46:20 »
Quote from: srsa_4c on 05 / February / 2017, 09:28:50
Why are you using a partial font that even has ML-specific chars in place of accented chars?
Because it was "found" on my SD card in ML directory.  :)

Quote
Because "we" don't know how.
https://chdk.setepontos.com/index.php?topic=6204.0
https://bitbucket.org/hudson/magic-lantern/src/8e0d34d81dc1ebfb08176de6bb3ee3715c4f5c10/src/bmp.c?at=unified&fileviewer=file-view-default#bmp.c-942
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #23 on: 05 / February / 2017, 13:04:24 »
Quote from: Ant on 05 / February / 2017, 11:46:20
https://chdk.setepontos.com/index.php?topic=6204.0
https://bitbucket.org/hudson/magic-lantern/src/8e0d34d81dc1ebfb08176de6bb3ee3715c4f5c10/src/bmp.c?at=unified&fileviewer=file-view-default#bmp.c-942
Okay, it now only needs CHDK integration then (plus implementing font detection in finsig's, ...).

Meanwhile, I'm now wasting the second day in a row trying to improve draw_pixel_std(). Should I ever finish, next item to look at will be the draw_pixel_proc() and draw_pixel_proc_norm() replaceable functions, and their impact on my plans to introduce optimized multi-pixel drawing routines...

In case someone knows a faster method to draw on uyvy framebuffers, don't hesitate to tell.

edit:
What I currently have is this (only tested it on my sx280 with 14x32 font size), gets me ~5900 chars/sec (was ~5560 chars/sec prior to optimization).
Code: [Select]
static void draw_pixel_std(unsigned int offset, color cl)
{
#ifndef THUMB_FW
    // drawing on 8bpp paletted overlay
#ifdef DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY
bitmap_buffer[active_bitmap_buffer][offset] = cl;
#else
frame_buffer[0][offset] = frame_buffer[1][offset] = cl;
#endif
#else
    // DIGIC 6, drawing on 16bpp YUV overlay

#ifndef DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY
#error DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY is required for DIGIC 6 ports
#endif

    register int cli = cl ^ 0xffffffff;
    extern volatile char *opacity_buffer[];
    int active_buffer_index =  active_bitmap_buffer & 1;
    unsigned char *obu = (unsigned char *)(&opacity_buffer[active_buffer_index][0]);
    unsigned char *bbu = (unsigned char *)(&bitmap_buffer[active_buffer_index][0]);
    if (cl)
    {
        // this gets one transparent gray
        obu[offset] = ((cl)&0xf0)==0xb0?0xc0:0xff;
        register unsigned int offs2 = (offset>>1)<<2;
        if (offset&1) // x is odd
        {
            bbu[offs2+3] = (cli&0xc0);    // Y
        }
        else // x is even
        {

            bbu[offs2+2] = 0x80-((((int)cli)<<5)&0xe0);    // V?
            bbu[offs2+0] = 0x80-((((int)cli)<<2)&0xe0);    // U?
            bbu[offs2+1] = (cli&0xc0);    // Y

        }
    }
    else // color==0, black, fully transparent
    {
        // fully transparent
        obu[offset] = 0;
        register unsigned int offs2 = (offset>>1)<<2;
        if (offset&1) // x is odd
        {
            bbu[offs2+3] = 0;    // Y
        }
        else // x is even
        {
            bbu[offs2+1] = 0;    // Y
        }
        {
            bbu[offs2+2] = 0x80;    // U?
            bbu[offs2+0] = 0x80;    // V?
        }
    }
#endif
}
Odd pixels only get intensity and opacity. Reading from uncached RAM, manipulating it then writing it back would be a significant performance hit (I tried that too).
« Last Edit: 05 / February / 2017, 14:21:42 by srsa_4c »
Logged
*

Offline 62ndidiot

  • *****
  • 596
Re: Display (bitmap overlay)
« Reply #24 on: 08 / February / 2017, 14:00:02 »
What would be the effect if you treated all pixels equally, writing one byte Y , one byte chroma, one byte opacity?  Surely this is no worse than writing two bytes chroma for even pixels and no bytes chroma for odd? Would it cause flickering?

The act of writing a single pixel of a certain color just isnt well defined, it will affect the color of its sibling pixel.
Really you are always affecting pairs of pixels.
« Last Edit: 08 / February / 2017, 19:10:18 by 62ndidiot »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #25 on: 09 / February / 2017, 13:15:51 »
Quote from: 62ndidiot on 08 / February / 2017, 14:00:02
What would be the effect if you treated all pixels equally, writing one byte Y , one byte chroma, one byte opacity?  Surely this is no worse than writing two bytes chroma for even pixels and no bytes chroma for odd?
I tried, could not make it work faster (per benchmark) than the version that writes unequal amount of bytes. Also, anything using lookup tables turned out to be slower - the reason behind this could be that the lookup table was placed far from the function and the compiler used indirect references to it (would have been more efficient with ADR instructions and nearby table).
If you're bored, you can experiment with it - it's always possible that I'm overseeing something.
Quote
The act of writing a single pixel of a certain color just isnt well defined, it will affect the color of its sibling pixel. Really you are always affecting pairs of pixels.
True, but only seems to matter when drawing thin vertical lines.

Latest version - finally a usable palette and 5976 chars/sec @ 14x32 font on the sx280. The version decoded by chdkptp (attached) just doesn't look like it does on the LCD.
Code: [Select]
static void draw_pixel_std(unsigned int offset, color cl)
{
#ifndef THUMB_FW
    // drawing on 8bpp paletted overlay
#ifdef DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY
bitmap_buffer[active_bitmap_buffer][offset] = cl;
#else
frame_buffer[0][offset] = frame_buffer[1][offset] = cl;
#endif
#else
    // DIGIC 6, drawing on 16bpp YUV overlay

#ifndef DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY
#error DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY is required for DIGIC 6 ports
#endif

    extern volatile char *opacity_buffer[];
    int active_buffer_index =  active_bitmap_buffer & 1;
    unsigned char *obu = (unsigned char *)(&opacity_buffer[active_buffer_index][0]);
    unsigned char *bbu = (unsigned char *)(&bitmap_buffer[active_buffer_index][0]);
    unsigned int cli = (cl+1);
    unsigned int clm = (cl-1)^0xffffffff;
    unsigned int clu = (clm)&0xf0;
    obu[offset] = (cl&0xf)?255:cl;
    register unsigned int offs2 = (offset>>1)<<2;
    if (offset&1) // x is odd
    {
        bbu[offs2+3] = clu; // Y
    }
    else // x is even
    {
        if (!(cli&2))
        {
            cli = 128;
            clm = 128;
        }
        else
        {
            cli *= 5;
            clm <<= 2;
        }
        bbu[offs2+1] = clu; // Y
        bbu[offs2+0] = cli; // U?
        bbu[offs2+2] = clm; // V?

    }
#endif
}
Here's the matching palette (platform/sx280/platform_palette.c). May need adjustment on other models.
Code: [Select]
// Playback mode colors
unsigned char ply_colors[] =
{
        COLOR_TRANSPARENT,         // Placeholder for script colors
        COLOR_BLACK,               // Placeholder for script colors
        0x0f,                       // White
        0xce,                       // Red
        0xd1,                       // Dark Red
        0x81,                       // Light Red
        0x71,                       // Green
        0xae,                       // Dark Green
        0x3e,                       // Light Green
        0xfe,                       // Blue
        0xf1,                       // Dark Blue
        0x2e,                       // Light Blue / Cyan
        0x74,                       // Grey
        0xb4,                       // Dark Grey
        0x34,                       // Light Grey
        0x01,                       // Yellow
        0x41,                       // Dark Yellow
        0x0e,                       // Light Yellow
        0xb0,                       // Transparent Dark Grey
        0x8e,                       // Magenta
};

// Record mode colors
unsigned char rec_colors[] =
{
        COLOR_TRANSPARENT,         // Placeholder for script colors
        COLOR_BLACK,               // Placeholder for script colors
        0x0f,                       // White
        0xce,                       // Red
        0xd1,                       // Dark Red
        0x81,                       // Light Red
        0x71,                       // Green
        0xae,                       // Dark Green
        0x3e,                       // Light Green
        0xfe,                       // Blue
        0xf1,                       // Dark Blue
        0x2e,                       // Light Blue / Cyan
        0x74,                       // Grey
        0xb4,                       // Dark Grey
        0x34,                       // Light Grey
        0x01,                       // Yellow
        0x41,                       // Dark Yellow
        0x0e,                       // Light Yellow
        0xb0,                       // Transparent Dark Grey
        0x8e,                       // Magenta
};
I saw the zebra+everything patch, I'll get to that later - still working on pixel + font drawing stuff.
Logged
*

Offline 62ndidiot

  • *****
  • 596
Re: Display (bitmap overlay)
« Reply #26 on: 12 / February / 2017, 23:13:28 »
As far as "blinking" the bitmap buffer goes, is it necessary to write 0x80 0x00 0x80 0x00 (uYvY)  everywhere as well as to zero the opacity buffer, or would zeroing the opacity buffer be sufficient?
This might help with the problem of thin vertical lines if you can disappear a pixel by using opacity.
« Last Edit: 14 / February / 2017, 15:17:47 by 62ndidiot »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #27 on: 16 / February / 2017, 20:48:59 »
Quote from: 62ndidiot on 12 / February / 2017, 23:13:28
As far as "blinking" the bitmap buffer goes, is it necessary to write 0x80 0x00 0x80 0x00 (uYvY)  everywhere as well as to zero the opacity buffer, or would zeroing the opacity buffer be sufficient?
You could find out by modifying one of the drawing functions. IIRC, when I was first attempting to display something on the sx280, I was able to see a faint overlay without even modifying the opacity buffer. Visibility may depend on the content of the viewport and/or the overlay's luminance.
Quote
This might help with the problem of thin vertical lines if you can disappear a pixel by using opacity.
I'm not too concerned about thin standalone vertical lines - I don't think they're very common on the CHDK UI.
Logged
*

Offline 62ndidiot

  • *****
  • 596
Re: Display (bitmap overlay)
« Reply #28 on: 18 / February / 2017, 20:59:33 »
I tried modifying the blink function in zebra to only zero the opacity buffer (and not write a transparent color to the bitmap). It doesn't work. Can't say I understand why though.  So we still rely on the nice functionality of bzero4  :)
« Last Edit: 18 / February / 2017, 21:37:03 by 62ndidiot »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #29 on: 25 / February / 2017, 14:59:30 »
Attached is an experimental patch that - for simplicity - treats the DIGIC 6 overlay as if it were quarter resolution (half horizontally and half vertically). Only used my sx280 to test. As a said repeatedly, I find the resulting look rather unpleasant. Not only does this make the CHDK overlay visibly pixelated, but fonts are also wider than they were on pre-DIGIC 6 cams.
On cameras with 640x480 overlay, 40 characters fit in a row. Again, that's barely sufficient - file browser columns don't fit, various extensions display clipped lines, menu entries get cut short.
On the plus side, it can be done simply and most drawing routines can be left unchanged. It's also quick, ~11850 chars/sec on the sx280, according to the benchmark, without any optimization.

The other way (keeping full resolution) is still not done completely - many drawing operations need to be optimized to keep drawing speed acceptable. It also changes drawing infrastructure considerably - optimized drawing requires separate drawing functions instead of a single draw_pixel_std().
Logged
Pages: 1 2 [3] 4 5 6 7 8 ... 41   Go Up
« previous next »
 

Related Topics