8000 RFC extmod/modframebuf.c Support for blitting from 1-bit to n-bit colour maps · Issue #2973 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content
8000

RFC extmod/modframebuf.c Support for blitting from 1-bit to n-bit colour maps #2973

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
peterhinch opened this issue Mar 21, 2017 · 5 comments
Closed

RFC extmod/modframebuf.c Support for blitting from 1-bit to n-bit colour maps #2973

peterhinch opened this issue Mar 21, 2017 · 5 comments

Comments

@peterhinch
Copy link
Contributor

We now have 1-bit horizontal maps. One use for these is for rendering bitmaps such as font glyphs by blitting from a framebuf containing the glyph to the destination framebuf. This works - in a geometry agnostic manner - on monochrome displays where the destination uses 1-bit colour mapping.

Where the destination uses n-bit colour maps the resultant colour is unexpected. The general solution is to introduce the concept of palettes defining a mapping between differing colour spaces. This is not 'micro'.

A 'micro' solution might be to add an optional colour arg to the blit method which, when the source framebuf has a 1-bit mapping, causes the blit to be rendered in the supplied colour. This would enable fast font rendering in arbitrary colours and would be easily implemented.

Or is there a better approach?
@dpgeorge
Copy link
Member

I was thinking the same thing, to add a "palette" argument to blit. Blitting lower bit-depth images to larger bit-depth buffers seems to be the most common thing to do, so the palette can actually be quite micro: for 1-bit source it's just 2 entries, and for 4-bit source (GS4_HMSB format) it's just 16 entries. The latter is only a 32 byte palette when blitting to a 16-bit RGB framebuf.

@deshipu
Copy link
Contributor
deshipu commented Mar 23, 2017 •
edited
Loading

I'd love to have a stab at implementing this.
Another thing that I noticed is that even with rather big palettes, they are going to be very regular -- usually the values are just scaled up/down to cover the larger/smaller color space. So maybe it would make sense to do it with a callback function, that would compute the new color on the fly without having to waste memory for all the color entries? We can have some common functions (scale, threshold, palette, invert, etc.) provided for convenience, but also let the user provide their own. This would also be useful for transforming images with the same color depth.
But I'm afraid that I'm over-generalizing here and that calling a python callback for every pixel would make it as slow as just looping over the pixels in Python, defeating the purpose of the blit function (even if we memoized it).

@deshipu
Copy link
Contributor
deshipu commented Jul 24, 2017

I'm sorry for the long delay, but I finally made the first draft of the code, here: #3238

As you can see, it's extremely simple right now. You just pass an array of ints defining the mapping.

@peterhinch
Copy link
Contributor Author

Given that this seems to have died can I propose a "micro" solution?

This caters for the common case where the source has a 1-bit mapping and the destination has a greater depth: for example where glyphs are to be rendered to colour displays.

In this solution, two additional optional args to blit provide foreground (FG) and background (BG) colours in a format compatible with the destination framebuf. If FG is provided and the source pixel is nonzero the pixel is rendered in FG. If BG is provided and the source pixel is zero the pixel is rendered in BG.

This should require minimal code, have little impact on performance and radically improve the speed of a common use-case. Rendering glyphs to colour displays using Python is excruciatingly slow compared to mono (where blit can be used).

I'd be happy to submit a PR if there's any interest in this.

@jimmo jimmo mentioned this issue Jun 18, 2019
Closed
@peterhinch peterhinch mentioned this issue Jun 30, 2019
Open
17 tasks
@peterhinch peterhinch mentioned this issue Aug 1, 2019
Open
@peterhinch peterhinch mentioned this issue Aug 24, 2020
Open
@jimmo jimmo mentioned this issue May 11, 2021
Open
@peterhinch
Copy link
Contributor Author

Closing this as now fixed by #7682.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@deshipu @dpgeorge @peterhinch
0