There is ongoing interest on Elphel’s JP4 mode. JP4 color mode enables client demosaicing and near RAW quality with lower file size. There are a few JP4 modes available, but only a couple could be used directly using standard software, most modes needs specialized software. Currently, elphel_dng works for still images on JP4 and JP46 modes.
(more…)
With the first Eyesis content available I started to prototype the panoramic workflow. We would like to have a reference design to be available in such way that a camera can be used without custom development. For practical reasons I have started with the relative low-quality JPEG output. Like for all current Elphel camera’s JPEG, JP4 and JP46 modes exist. For framerate and quality the JP4 mode will be the optimal sweetspot, it gives a theoretical maximum of 5.31 fps (panorama), with host side debayer.
(more…)
Elphel-Eyesis 1
On July 8, we have the first panoramic camera completely assembled and ready for the test ride. The total height is 1300 mm [4′ 3″]; it weighs 10 kg or about 22 lbs . The power consumption is 36W when camera is in operation, measured at the AC (110/220VAC) input. Camera head has eight 5 Mpix Color sensors around and one pointing up, with the full resolution of ~38 MPix (45 MPix before stitching). The data storage box (also waterproof) – at the bottom of the leg contains 3 swappable 2.5″ hard drives 500 GB each, which is enough to record up to 12 hours of images taken at 5 fps (max frame rate) at full resolution. Each image is geotagged via external GPS unit attached through the sealed USB connector.
The 8 high-resolution lenses are arranged very compact (distance between entrance pupils is 29.5mm), which allows for very small parallax. The high-res Fish-eye lens is pointed to the sky.
Camera head is 210mm [8.3″] in diameter , is waterproof, contains 3 Elphel 10353 processor boards and 3 Elphel 10369 extension boards, which provide IDE, SATA, USB, RS232, and other interfaces (only SATA, USB and sync I/Os are used in Eyesis configuration). Nine sensor boards (10338D) are connected through the three 10359A multiplexer boards that provide temporary storage for the images – all 3 sensors attached to the same 10359A board are triggered simultaneously, but data is transferred to the system boards one at a time. (more…)
texture_tiles
When we started working on Eyesis project our first goal was to make the panoramic head as compact as possible to reduce parallax between sensors. That not only reduces the stitching artifacts but also decreases the minimal distance to object without dead zones between the individual camera.
The first practical step was to reduce the PCB area around the sensors, especially in one direction, so multiple camera boards can be placed closer to each other, For that purpose we preserved the basic design of the proven 10338 sensor board, just changed the layout to make it more compact. The board 10338D is just 15mm wide – more than twice less than the older design.
Next step was to run mechanical CAD program and try to place the boards and lenses. Most of the Elphel cameras were designed for the C/CS-mount lenses, but when I tried to place them I immediately found out that when using 10 or 8 cameras around even the C-mount thread (CS is the same size but even closer) will be the limiting factor, not the sensor PCB that we already made smaller.
(more…)
RMLL 2010 (Libre Software Meeting) is a free (as a beer and as a speech) and non commercial conferences, workshops and round table about Free Software and its applications. The LSM goal is to provide a platform for exchange among Free Software developers, users and stakeholders.
Eyesis camera shade, before anodising
3 x 10353 processing boards with 3 connected sensors each
The first 3 Elphel-Eyesis prototypes are nearing completion. Even though there were delays from our suppliers we finally received the last remaining parts and can now finish the camera and data storage assembly.
There were concerns that the pole and its attachments could have aerodynamic problems and that the system could be a whistle at higher speeds.
Today we tested the assembled camera shade for acoustical noise while moving at speed 30-55 mph, luckily the tests proved that there was nothing to worry about.
(more…)
Spring is here and all kinds of colourful plants and flowers start to grow. This gave me a perfect opportunity to take my Elphel 353 to a garden and do some macro shots and explore the JP4 RAW to Adobe DNG workflow.
The following photo was shot in JP46 colour mode at 100% JPEG compression and then converted to Adobe DNG using this converter.
More images are available in the Image Gallery and for this particular shot I uploaded the DNG file as well: insects.dng
Andrey spent months of planning and designing these parts and yesterday we finally had the joy of assembling the first panoramic camera head prototype utilising 9 sensor boards. This new panoramic camera head is called Elphel Eyesis. A few metal parts are still missing but the heart of the system – the optical part – is now completed. The extremely small size drastically reduces parallax (wikipedia explanation) see ruler for size comparison. The system allows to gather 360° panoramas at ~38 Mpix (45Mpix before stitching) at min. 5 fps (lower resolutions allow higher fps while covering the same field of view). The images below also show the pretty complex internal mechanical systems that allow each sensor to be mechanically fine tuned (2 axis tilt, focus plane distance).
This article is to detail the typical workflow I use when I am adding a new application recipe to OpenEmbedded from scratch. In this case it will be the open source cloud computing application called eyeos.
During this article reference to the OE wiki especially the styleguide for new recipes is highly recommended.
This article is to detail the workflow I personally use when I am doing kernel development for devices supported by OE. I find OE very useful for this as I can use it to build the toolchain and ultimately to control my patch tree until I am ready to send the patches upstream.
So I select a kernel which I wish to develop with, in my case this is in recipes/elphel/linux-elphel_git.bb
I first make sure I am starting from clean:
bitbake linux-elphel -c clean
Then take the kernel as far as the configuration stage, this makes sure all patches in the metadata are applied and that the defconfig has been copied to .config and make oldconfig has been run.
bitbake linux-elphel -c configure
Now I switch to another window where I shall be actually editing the code. I change to the temporary working directory of the kernel I am working with. This path below will change depending on kernel version or name. Kernels are always found in the machine workdir so tmp/<machinename>-angstrom-linux-gnueabi/
cd tmp/work/elphel-10373-angstrom-linux-gnueabi/linux-elphel-2.6.31+2.6.32-
rc8+r4+gitr2a97b06f43c616abb203f4c0eb40518c44c8d7fe-r28/
At this point I normally elect to use quilt to temporarily manage my patches so.
quilt new new-feature.patch
And to add files to this patch, I make sure to do this before I make any edits as the diff ends up being the diff from when this is first called to the current state.
quilt add driver/camera/random.c
