Captura de pantalla de 2013-02-28 22:09:29

Kinoraw Workflow (2012)

Captura de pantalla de 2013-02-28 22:09:29

The workflow that we propose consist of four parts:

Recording and RAW dumping


At the moment we use the camera’s own interface (php) to make the setting changes, while Biel is already Working on a python script useful for managing several configurations. …In development…


Recording is done at the JP4 format using a series of scripts based on the ones published by Flavio.

We have to copy them inside the camera (in /usr/local/scripts). they are four scripts residing inside the camera that we will use in order to record.

The first step is to launch a terminal, launch Telnet to the Camera and send this command:

sh /usr/local/scripts/

This script ensure that the internal disc in the camera gets mounted at /var/hdd

sh /usr/local/scripts/

When this script gets called some internal PHP process in the camera as well as the auto-exposure PHP process, get killed and so the camogm program becomes then ready to record, the window that handles Telnet where we are calling those scripts can remain open in order to receive the feedback on the recording in order to see if it is going well, or if otherwise there are some dropped frames.

Following next, from another new instance of the terminal (ctrl+alt+t) we call another instance of Telnet to the camera and send this other script.

sh /usr/local/scripts/ folder

In that last script the first argument (“folder”) is the name of the folder where we want to keep the recorded footage, as well as the prefix name that those videos will have in the filename.

Back in the first instance of the terminal that still remains open we can check the result of the calling of the last script, And when we want to stop the recording process, we will call in the second instance of the terminal that last script:

sh /usr/local/scripts/

Because the fact of displaying the stream depends on the capacity of the computer that we’re using, we have in our disposal several scripts to help us check the stream of the camera properly. At the moment when we record at RGB we use mplayer but at JP4 we use a gstreamer script that automatically detects the camera’s resolution.

We have a small Kivyi interface in development, that will integrate all those scripts in a single easy interface.

Raw dump

We currently are using filezilla to dump the content from the camera, but there is also a new dumping script, that creates a list of files and verifies the whole process with a MD5 checksum.

Proxy creation with Gstreamer

Once dumped the raw footage, we call a nautilus script for the generation of proxies. The script calls a Gstreamer’s command, in nautilus or the terminal, in roder to convert the video in JP4 format to RGB video m-jpeg encoded and resolution reduced to 25% (there’s also the possibility to generate proxies at 100%) Then, the proxy it’s kept within a MKV container (matroska video)

This is the nautilus script:


for file in $fpaths
  if [ -f "$file" ]; then
    gst-launch-0.10 filesrc location=$file ! decodebin ! ffmpegcolorspace ! queue ! jp462bayer ! "video/x-raw-bayer, width=(int)1920, height=(int)1088, format=(string)grbg" ! queue ! bayer2rgb2 method=1 ! queue ! ffmpegcolorspace ! videoscale ! video/x-raw-yuv, width=480, height = 272 ! jpegenc ! matroskamux ! filesink location=$base-25.mkv 

TO DO: automatize the script so it can detect the resolution of the video files for conversion and that it gets executed recursively in a folder.

Blender VSE – Editing and exporting to JPG

After the proxies have been generated, we can start the editing with Blender. To accomplish this task, we can get hold of those next scripts:

Within the second script, there is a panel called recursive loader that let us import to the VSE all the raw video files hosted in a directory (even with sub-directories included) and configure in an automatized way the proxies generated in the last step.

Since the JP4 is encoded in a JPEG fashion, if, at the final rendering stage, we configure Blender’s exit format to JPEG at 100% quality, we will obtain a selection of the JP4s that will be necessary to develop.

EXR conversion – Colour grading in Blender

In order to convert JP4 files to EXR, we can use the Python script. But for the script to work, we will need to have installed dcraw, exiftool and qtpfsgui, as well as the JP4 to DNG converter elphel_dng (you can find in here, in JP4tools). It’s also necessary to install Parallel enabling us to call the conversion in a multi-threaded fashion.At the moment I’m using qtpfsgui for simplicity, but I have the intention to try to create the EXRs directly with pfstools.

The thing that this script do is pretty simple: First it converts every image to DNG using elphel_dng. then, it assigns the EXIF meta-data that the image lacks and that are essential for the conversion that later qtpfsgui performs.

-ISO=100 -FocalLength=4.5 -ExposureTime=0.04 -ApertureValue=2.0

those meta-data values are not known by the camera, so I assign to them a random value.

If we want to start Blender’s colour grading work-flow form the standpoint of a sequence of DNGs, we can do it by using this modification of the script (basically, erasing, from it, the lines in which elphel_dng gets executed and the recovering of the meta-data with exiftool):

In order to call this script, copy the script inside the directory containing the DNGs and also inside there type the following command:

ls *.dng | parallel -j 8 python {}

Where you can substitute the “8” for the actual number of cores that your CPU features

You have to bear in mind this anotation that resides inside the code:

    # dcraw -T -4 -q 1 -a -m 2 
    # |
    # `-> you have to configure this inside qtpfsgui preferences

If we want to manipulate the way in which our DNG it’s developed, we can see several instructions within the preferences of qtpfsgui, in the RAW Importation Options tab.

Once the frames remain converted to EXR, we can come back to Blender,conform our project with the EXR (which won’t show any image in the VSE) and start colour grading at the node compositor with the help of this script that it’s still WIP:

Caution! the script composite from that forum is a collective work in progress, and perform tasks still somewhat unstable, handle with care.

At the end of this post you’ll find the links to the scripts required to tests the method. (rename the files from *.py.txt to *.py in order to use them)

Also, If you’re interested in try this with raw footage from the red one, or a Blackmagic, export them to DNGs and start reading here.

Here is a video showing up the work-flow:

tuto-edit-compositor from Telenoika on Vimeo.

here there is a timelapse of the whole process:

tl-etalonaje-paseo from Telenoika on Vimeo.

And finally, a couple of tests EXT / DAY and INT / NIGHT, of the capabilities of what Elphel can see when recording at this particular raw format JP4:

kinoraw: interior / noche demo video from Telenoika on Vimeo.

kinoraw: exterior / dia demo video from Telenoika on Vimeo.

source code contributors for Blender:

Turi Scandurra, peddie, TMW, Björn Sonnenschein, in Blenderartists.

source code contributors for the Elphel camera:

Biel, Sebastian, and Flavio from the Apertus community Andrey and Oleg from

Esta entrada también está disponible en: Spanish, Catalan

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>