HN user

omtinez

70 karma
Posts1
Comments27
View on HN

Really cool work, congrats!

I built my own frontend framework for similar reasons: https://github.com/fresho-dev/mancha. It was meant to adress the lack of lightweight solutions that worked both on the frontend and the backend. The main goal was to start with client side rendering and, only if you reach the point where you need it, switch to server side rendering. It also includes a drop in replacement for TailwindCSS except it won't yell at you for doing everything client side.

What I really wanted was a better maintained version of PetiteVue. But that highlights another problem: I simply can't trust anyone in the frontend JavaScript ecosystem, I've been burned too many times. It took a while to get to the point of it being usable, but now I know no one can pull the rug from under me. I use only the most basic APIs possible, only 1-2 third party dependencies, and as little hacks as possible.

It still has a few warts here and there but I hope to be able to call it a 1.0 stable version soon enough.

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.

Maybe someone can take a second look at the paper. I couldn't find the published version, just a manuscript[1] (kudos to the authors for making it available under CC license). But... The only reference I could find about the sample size says:

"To prepare a single RNA injection, the pleural-pedal and abdominal ganglia were removed from 4-5 sensitization-trained animals—or from 4-5 untrained controls—immediately after the 48-h posttest"

4-5??? I really hope that I'm missing something here, otherwise I find truly depressing how low the bar is for scientific journals.

[1] http://www.eneuro.org/content/eneuro/early/2018/05/14/ENEURO...

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”).

I fail to understand the need to re-use terms from other fields in a completely twisted way. For those like me wondering what an "idempotent API" is: making multiple identical requests has the same effect as making a single request[1].

Then you have other people using the exact same term to refer to a (seemingly) totally different concept: An idempotent operation completes no more than one time[2].

Maybe I'm thicker than the average web developer, but I think that there must be a simpler way to explain this concept. Specially without reusing a term that, formally, means something completely different[3] than any of the possible interpretations that I have come up with so far.

[1] http://www.restapitutorial.com/lessons/idempotency.html [2] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_In... [3] https://en.wikipedia.org/wiki/Idempotence

Also wrong. The telemetry in Windows 8 was just in critical components that had been instrumented long ago, such as Windows Update, crash management, etc. None of those were using the current universal telemetry system. In fact, I don't know if all of them moved to the new telemetry infrastructure shared with the rest of the OS or if they kept what they had and just added the new telemetry on top.

All that said, I agree with your last point about upgrading being a fair compromise compared to staying in Windows 7 or gasp Windows 8.

I don't see the point of this with newer generation cameras. Almost all drivers nowadays support the "photo burst" mode where you take a single photo and the driver gives you back X frames before and after the fact (at full resolution). I think Nokia calls it Perfect Shot