omtinez

What hardware are you using? I recently finished a project myself and I'd like to do more with e-ink but the hardware "driver" that plugs into the pi costs as much as the e-ink display.

You can use Wikidata and its Sparql query language for this. Although it's not straight forward for all countries, e.g. some have especial properties for regional breakdowns that are not defined as ISO standard subregions.

> Does it work with Raspberry Pis and the CSI cameras? What about my Logitech USB camera?

I don't know details about the Raspberry Pi cameras, but if it's a UVC camera (quite likely) then it should be supported by this library according to the documentation. A USB Logitech camera should also be supported. The gotcha is that unless those cameras expose advanced functionality (3A, multiple stream support, etc) then you don't get any benefit over using the standard V4L drivers.

> Would it support receiving a picture from eg a flatbed scanner over a parallel port?

I don't think scanners identify themselves as camera devices, but someone can correct me if I'm wrong.

I'm surprised to see such big emphasis on support for Android. Most camera modules come with their own drivers that already provide Android support. One benefit could be the licensing, but after a quick inspection it is unclear to me what license this library is under -- there is a licenses folder with 4 different licenses in addition to a developer agreement.

The design seems to be heavily inspired by the Android camera API: per-frame configuration, 3A, multiple stream support, device enumeration, etc.

> The HAL will implement internally features required by Android and missing from libcamera, such as JPEG encoding support.

That is interesting, since most camera modules will have a hardware accelerated path to encode frames directly to JPEG. If it's done internally, it will be much slower than all other implementations I'm aware of.

I haven't read the paper in full detail, but reading between the lines I'm guessing that there's a significant portion of manual processing and hand waving involved. From the abstract, emphasis mine:

> the second stage uses a pixel-wise nearest neighbor method to map the smoothed output to multiple high-quality, high-frequency outputs in a controllable manner.

My interpretation is that they select training data by hand and generate a bunch of outputs. Repeating the process until they like the final result. From the paper:

> we allow a user to have an arbitrarily-fine level of control through on-the-fly editing of the exemplar set (E.g., “resynthesize an image using the eye from this image and the nose from that one”).

By your definition, how can a REST API be idempotent? Say that GET(user) = john so, what I'm interpreting is that: GET( GET(user) ) = GET(john) = john. That doesn't seem valid to me.

That is exactly how the Spectacles work. Bluetooth is only used for transfer as a fallback mechanism.