Hacker News new | past | comments | ask | show | jobs | submit login

Fun little project! I worked on a 7 color eInk Arduino-based picture frame two years ago for a gift. My biggest issue was that I had to manually crop, dither, and color index the images to get them to look _okay_ on the display. If FrameOS could handle all of that for me then it would have saved hours of manual editing and testing.

I ended up getting that same person an Aura frame this year because remotely adding photos ended up miserable




Imagemagick can batch process images with restricted palettes. No reason you had to do it all manually.


I definitely do not want anyone to manually crop, dither and color index images. This should be done by the FrameOS software. It's already working if you use e.g. Inky Impression 7 color frames, but mostly because I just defer to their software/drivers, which already handle this...


Our crude (actually Pillow’s IIRC) dither has a certain nostalgic appeal to it, but can definitely be bested by other algorithms. I’m still not totally convinced we have a great perceptual match for the colours either. The approach to get them - take a photo of the screen, use a colour dropper and a bit of eye balling - was crude.

(Hi, I wrote most of the Inky driver and your project is the kind of awesome I wish the Pico/RP2040-based Inky Frame devices could pull off.)


Ha, nice to meet you.

I always say "if it's stupid and it works, it's not stupid". Your approach to get the dithering right sounds brilliant to me :D.

The current inky driver works great, and that fact that it's in Python is what made me develop the original FrameOS software in Python. However now that I rewrote it in Nim, the Python driver is a bit of a crutch. While I could use the C drivers for the Waveshare displays, I'm forced to install a python wrapper on the Pi as a workaround to get the Inky drivers working.

Do you have any idea if there are any C, or even Nim drivers available for the Inky Impression boards? The Python workaround works, but isn't really elegant. If not, I'm considering porting them myself at some point...

I'm also lurking on the Pimoroni discord, and was meaning to ask there about it as well.


I have written drivers for Pimoroni's Inky Frames (based on Raspberry Pi Pico W) in Nim, but I don't own an Inky Impression. The code should be pretty similar once it hits the SPI bus.

https://github.com/daniel-j/nim-pimoroni-pico/blob/master/sr...

I have planned to write GPIO/SPI/I2C "drivers" in Nim that interfaces with the Linux drivers. So far I have made a wrapper for libgpiod. https://github.com/daniel-j/nim-gpiod


Well this rang the ol’ memory bells and brought me to Daniel’s Nim drivers for our Pico based products (1). He’s probably the guy to talk to.

Not needing a Python wrapper would definitely help slim down FrameOS into something you could stuff into a fast-loading initrd I guess?

I did something similar with Keybow, static binaries and a custom build system (2) to make a sort-of Pi (Zero) based appliance.

1. https://github.com/daniel-j/nim-pimoroni-pico/tree/master

2. https://github.com/ali1234/rpi-ramdisk




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: