| 24 Jun 2024 |
|  @dbrgn:matrix.coredump.ch left the room. | 20:17:28 |
| 27 Jun 2024 |
|  kkrolczyk changed their display name from kkrolczyk.jucr to kkrolczyk. | 19:53:07 |
|  el.cat joined the room. | 21:51:30 |
| 1 Jul 2024 |
 dngrs | Redacted or Malformed Event | 18:11:56 |
| dngrs | In reply to @dominaezzz:matrix.org
Anyone know of a no_std crate that can decode JPEG into a plain RGB framebuffer? have you seen/tried https://crates.io/crates/img-parts ? No experience with it myself but it sounds like it could be a fit, with a bit of work | 18:13:23 |
 Dominic Fischer | Looks like it only handles metadata/structure rather than the actual decoding | 20:27:13 |
| 2 Jul 2024 |
| dngrs | In reply to @dominaezzz:matrix.org
Looks like it only handles metadata/structure rather than the actual decoding Yeah that was maybe my optimism in the bit of work department... I did some very basic jpeg decoding a looong time ago and it was not hard, but when you want to support the full standard it seems to go up in complexity fast. But if you don't need that you can probably downsize https://github.com/image-rs/jpeg-decoder/blob/master/src/decoder.rs (eg remove CMYK support etc) | 05:41:19 |
| dngrs | Essentially jpeg encoding is a block wise zig zag DCT followed by Huffman coding so if you can control the source images and get rid of features like progressive and all the color transforms I think it should not be a lot of work, mostly delete code and substitute alloc for heapless | 05:57:02 |
| dngrs | * | 05:57:22 |
| dngrs | * | 06:01:42 |
| Dominic Fischer | In reply to @dngrs:matrix.org
Essentially jpeg encoding is a block wise zig zag DCT followed by Huffman coding (and decoding is just that in reverse) so if you can control the source images and get rid of features like progressive and all the color transforms I think it should not be a lot of work, mostly delete code and substitute alloc with heapless The source images are coming from an ov2640, so I can't control it sadly | 06:25:42 |
| dngrs | Ok but that still means you'll have a known and limited feature set | 06:26:31 |
| Dominic Fischer | True but I'm really looking for an easy/"it just works" solution to this. My "let's try and make it work" energy has been allocated to something else already | 06:30:51 |
| dngrs | Fair | 06:56:40 |
| 3 Jul 2024 |
 rfuest | The zune-jpeg crate might be an option: https://github.com/etemesi254/zune-image/tree/dev/crates/zune-jpeg It does support no_std, but requires alloc. | 15:19:52 |
| Dominic Fischer | Oh fantastic, thanks! | 15:27:40 |
| 4 Jul 2024 |
| dngrs |
esoteric color schemes like CYMK
chuckle
| 13:51:24 |
| dngrs | *
esoteric color schemes like CYMK
chuckle
| 13:51:27 |
| 5 Jul 2024 |
|  @jessebraham:matrix.org left the room. | 14:19:56 |
 Pedro Ferreira | Howdy, possibly silly question: how can I resize text? Do I need a bigger font or is there some way for instance to do some interpolation? | 17:27:21 |
| 6 Jul 2024 |
| dngrs | In reply to @ubik:matrix.org
Howdy, possibly silly question: how can I resize text? Do I need a bigger font or is there some way for instance to do some interpolation? bigger font is indeed the most straightforward, at least when we're talking bitmap fonts (and I'm unaware of vector font rendering on no_std, though it's not impossible). You could scale those too but that'd look ugly in almost every case | 10:58:59 |
| dngrs | In reply to @ubik:matrix.org
Howdy, possibly silly question: how can I resize text? Do I need a bigger font or is there some way for instance to do some interpolation? * bigger font is indeed the most straightforward, at least when we're talking bitmap fonts (and I'm unaware of vector font rendering on no_std, though it's not impossible). You could scale bitmap fonts but that'd look ugly in almost every case | 10:59:07 |
| Pedro Ferreira | I would be OK with ugly, it's supposed to look chunky anyway | 18:50:00 |
| Pedro Ferreira | if I were to scale the fonts, what would I need to do? Because otherwise it's a bit of a waste of space to have a large font in memory which is just an upscaled version of another one | 18:50:49 |
 sirhcel | In reply to @ubik:matrix.org
if I were to scale the fonts, what would I need to do? Because otherwise it's a bit of a waste of space to have a large font in memory which is just an upscaled version of another one Upscaling is what embedded-graphics did for its 24x32 font in the first place (and embedded-vintage-fonts continues to do). Depending on your targeted resolution, the space wasted by the larger 1bpp bitmap might be feasible. | 21:21:39 |
| sirhcel | On the other hand, you could write an adapter for naive upscaling by an integer factor which just samples an underlying bitmap font. | 21:23:41 |
| 13 Jul 2024 |
|  Gnome! joined the room. | 19:51:50 |
| 24 Jul 2024 |
 Phil Markgraf | What tools are used for encoding an image into Rust code for use in the embedded graphics context? | 18:15:09 |
| 25 Jul 2024 |
 almindor | I believe we have bmp and gif support somewhere | 13:18:13 |
| almindor | So you could just include_bytes! image data and use it that way | 13:18:56 |
