A More Open Raspberry Pi Camera Stack With Libcamera

As open as the Raspberry Pi Foundation has been about their beloved products, they would be the first to admit there’s always more work to be done: Getting a Pi up and running still requires many closed proprietary components. But the foundation works to chip away at it bit by bit, and one of the latest steps is the release of a camera stack built on libcamera.

Most Linux applications interact with the camera via V4L2 or a similar API. These established interfaces were designed back when camera control was limited and consisted of a few simple hardware settings. Today we have far more sophisticated computational techniques for digital photography and video. Algorithms have outgrown dedicated hardware, transforming into software modules that take advantage of CPU and/or GPU processing. In practice, this trend meant bigger and bigger opaque monolithic pieces of proprietary code. Every one a mix of “secret sauce” algorithms commingling with common overhead code wastefully duplicated for each new blob.

We expect camera makers will continue to devise proprietary specialties as they seek a competitive advantage. Fortunately, some of them see benefit in an open-source framework to help break up those monoliths into more manageable pieces, letting them focus on just their own specialized parts. Leveraging something like libcamera for the remainder can reduce their software development workload, leading to faster time to market, lower support cost, and associated benefits to the bottom line that motivates adoption by corporations.

But like every new interface design borne of a grandiose vision, there’s a chicken-and-egg problem. Application developers won’t consume it if there’s no hardware, and hardware manufacturers won’t implement it if no applications use it. For the consumer side, libcamera has modules to interop with V4L2 and other popular interfaces. For the hardware side, it would be useful to have a company with wide reach who believes it is useful to open what they can and isolate the pieces they can’t. This is where the Raspberry Pi foundation found a fit.

The initial release doesn’t support their new High-Quality Camera Module though that is promised soon. In the short term, there is still a lot of work to be done, but we are excited about the long term possibilities. If libcamera can indeed lower the barrier to entry, it would encourage innovation and expanding the set of cameras beyond the officially supported list. We certainly have no shortage of offbeat camera sensor ideas around here, from a 1-kilopixel camera sensor to a decapped DRAM chip.

[via Hackster.io]

Samsung NX300 Gets Rooted


[Ge0rg] got himself a fancy new Samsung NX300 mirrorless camera. Many of us would just take some pretty pictures, but not [Ge0rg], he wanted to see what made his camera tick. Instead of busting out the screwdrivers, he started by testing his camera’s security features.

The NX300 is sold as a “smart camera” with NFC and WiFi connectivity. The NFC connectivity turns out to be just an NXP NTAG203 tag embedded somewhere in the camera. This is similar to the NFC tags we gave away at The Gathering in LA. The tag is designed to launch an android app on a well equipped smartphone. The tag can be write-locked, but Samsung didn’t set the lock bit. This means you can reprogram and permanently lock the tag as a link to your favorite website.

[Ge0rg] moved on to the main event, the NX300’s WiFi interface. A port scan revealed the camera is running an unprotected X server and Enlightenment. Let that sink in for a second. The open X server means that an attacker can spoof keystrokes, push images, and point applications to the camera’s screen.

In a second blog post, [Ge0rg] tackled attaining root access on the camera. Based on the information he had already uncovered, [Ge0rg] knew the camera was running Linux. Visiting Samsung’s open source software center to download the open source portions of the NX300 confirmed that. After quite a bit of digging and several red herrings, [Ge0rg] found what he was looking for. The camera would always attempt to run an autoexec.sh from the SD Card’s root folder at boot. [Ge0rg] gave the camera the script it was looking for, and populated it with commands to run BusyBox’s telnet daemon.  That’s all it took – root shell access was his.


[Image via Wikimedia Commons/Danrok]

Cat5 Camera Flash Extension


Network engineer [Mario Giambanco] recently purchased a cable to move his flash off camera. Unfortunately, it ended up way too short for his purposes. Instead of purchasing a slightly longer proprietary cable, he decided to employ what he had around him: a lot of cat5e cable and ethernet jacks. He cut the cable close to the center in case things didn’t work out and he’d need to repair it. His post on building the custom ethernet flash extension cable goes into heavy detail to make sure you get it right the first time. He’s tested it using both five and 50 foot pieces of cable with no apparent lag.

This isn’t the first time we’ve seen cat5 repurposed: composite video through cat5, vga cat5 extension, and cat5 speaker cables.

[via Lifehacker]