|
|
| (41 intermediate revisions by 8 users not shown) |
| Line 1: |
Line 1: |
| [[File:BetaGettingStarted.jpg | thumb | 400px]]
| |
|
| |
|
| |
| Note: Some of the instructions we have prepared are written in a way they can also be followed by people without advanced technical knowledge. If you are more of a "techie", please keep this in mind and skip or ignore the steps or passages which deal with information you already know.
| |
|
| |
| ==Getting Started==
| |
|
| |
| ===Prep your AXIOM Beta camera for use===
| |
| # Use a micro-USB cable to connect the camera's MicroZed development board (USB UART) to a computer. The MicroZed board is the backmost, red PCB. (There is another micro-USB socket on the Power Board, but that is the JTAG Interface.)
| |
| # Connect the ethernet port on the MicroZed to an ethernet port on your computer. You might have to use an ethernet adapter on newer, smaller machines which come without a native ethernet port.
| |
| # Connect the AC adapter to the camera's Power Board. (The power cord plugs into an adapter that connects to the Power Board; to power the camera off at a later point, you need not disconnect the adapter from the board but can just unplug the cord from the adapter.)
| |
|
| |
|
| |
| [[File:BetaGuide.jpg | 500px]]
| |
|
| |
|
| |
| ===Prep your computer for use with your camera===
| |
| To communicate with your AXIOM Beta camera, you will send it instructions via your computer's command line.
| |
|
| |
| In case you have not worked with a shell (console, terminal) much or ever before, we have prepared detailed instructions to help you get you set up. The steps which need to be taken to prepare your machine sometimes differ between operating systems, so pick the ones that are applicable to you(r system).
| |
|
| |
| Note that dollar signs <code>$</code> placed in front of commands are not meant to be typed in but denote the command line prompt (a signal indicating the computer is ready for user input). It is used in documentation to differentiate between commands and output resulting from commands. The prompt might look different on your machine (e.g. an angled bracket <code>></code>) and be preceded by your user name, computer name or the name of the directory which you are currently inside.
| |
|
| |
| ====USB to UART drivers====
| |
| For the USB connection to work, you will need drivers for bridging USB to UART (USB to serial). (Under Linux this works out of the box in most distributions) for other operating systems they [https://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx can be downloaded] from e.g. Silicon Labs' website – pick the software provided for your OS and install it.
| |
|
| |
| ====Serial console====
| |
| The tool we recommend for connecting to the AXIOM Beta camera via serial port with Mac OS X or Linux is [http://linux.die.net/man/1/minicom minicom]; for connections from Windows machines, we have used [http://www.putty.org Putty].
| |
|
| |
| [[/Mac OS X setup/]]<br>
| |
| [[/Linux setup/]]
| |
|
| |
| [[/minicom configuration/]] instructions (Mac and Linux)
| |
|
| |
| ===Serial connection (via USB)===
| |
| While the AXIOM Beta can be connected to via USB UART (USB to serial), a serial connection is not the preferred way to communicate with the camera but rather in place for monitoring purposes.
| |
|
| |
| However, a serial connection is needed to set up communication via ethernet/LAN (the better suited way to talk to the camera): as the Beta only allows for secure ethernet connections, you will have to connect to the camera via serial port first and copy over your SSH key.
| |
|
| |
| Below are two different methods for connecting to the AXIOM Beta camera, using a program called minicom and an alternative program called screen. We suggest you try them in the order below, so if you can connect with minicom great, if not try screen.
| |
|
| |
| ==== Connect using minicom ====
| |
| Note that you will not be able to use the terminal window you initiate the serial connection in for anything else (it needs to remain open while you access the camera), so it might make sense to open a separate window just for this purpose.
| |
|
| |
| With minicom installed and properly [[/minicom_configuration/|configured]], all you need to do is run the following command to start it with the correct settings:
| |
|
| |
| <pre>$ minicom -8 USB0</pre>
| |
|
| |
| On successful connection, you will be prompted to enter user credentials (which are needed to log into the camera).
| |
|
| |
| If your terminal remains blank except for the minicom welcome screen/information about your connection settings, try pressing enter. If this still does not result in the prompt for user credentials – while testing, we discovered the ''initial'' connection with minicom does not always work – disconnect the camera from the power adapter, then reconnect it: in your minicom window you should now see the camera's operating system booting up, followed by the login prompt. (From then on, connecting with minicom should work smoothly and at most require you to press enter to make the login prompt appear.)
| |
|
| |
|
| |
| The default credentials are:
| |
| <pre>user: root
| |
| password: beta</pre>
| |
|
| |
| ==== Alternative tools for serial connection ====
| |
|
| |
| Before you can use any tool to initiate a serial connection with your Beta camera, you need to know through which special device file it can be accessed.
| |
|
| |
| Once the Beta is connected and powered on (and you installed the necessary drivers), it gets listed as a USB device in the <code>/dev</code> directory of your file system, e.g.<br>
| |
| <code>/dev/ttyUSB0</code> (on Linux)<br>or<br>
| |
| <code>/dev/cu.SLAB_USBtoUART</code><br>
| |
| <code>/dev/tty.SLAB_USBtoUART</code> (on Mac).
| |
|
| |
| You can use a command such as:
| |
| <pre>$ ls -al /dev | grep -i usb</pre>
| |
| to list all USB devices currently connected to your machine.
| |
|
| |
| ===== screen =====
| |
| To connect to the camera, use the command:
| |
| <pre>$ screen file_path 115200</pre>
| |
|
| |
| where <code>file_path</code> is the full path to the special device file (e.g. <code>/dev/ttyUSB0</code> or <code>/dev/cu.SLAB_USBtoUART</code>).
| |
|
| |
| You might have to run the command with superuser rights, i.e.:
| |
| <pre>$ sudo screen file_path 115200</pre>
| |
|
| |
| On successful connection, you will be prompted to enter user credentials needed for logging into the camera.<br>
| |
| If your terminal remains blank, try pressing enter.
| |
|
| |
| The default credentials are:
| |
| <pre>user: root
| |
| password: beta</pre>
| |
|
| |
| ====Disconnect====
| |
| To exit the camera's operating system, use:
| |
| <pre>$ exit</pre>
| |
|
| |
| The result will be a logout message followed by a new login prompt.
| |
|
| |
| To suspend or quit your <code>screen</code> session (and return to your regular terminal window) use one of the following commands:
| |
| <pre>CTRL+a CTRL+z</pre>
| |
| <pre>CTRL+a CTRL+\</pre>
| |
|
| |
| ===Ethernet connection (using SSH)===
| |
|
| |
| To access the AXIOM Beta via Ethernet – which is the preferred way to communicate with it and will also work remotely, from a machine which is not directly connected to the camera – authentication via SSH is required.
| |
|
| |
| If you have never created SSH keys before or need a refresher in order to create a new pair, see the How-to below.
| |
|
| |
| [[/SSH_keys/|SSH keys How-to Mac/Linux]]
| |
|
| |
| ====Get/set IP address====
| |
|
| |
| If your network has a DHCP server running somewhere (eg. router) the AXIOM Beta will receive an IP address automatically as soon as it is connected the network.
| |
|
| |
| Otherwise, you will have to set the Beta's IP address manually with the <code>ifconfig</code> command over the serial console (USB).
| |
|
| |
| =====IP address check=====
| |
|
| |
| While connected to the AXIOM Beta via USB, you can use the command:
| |
| <pre>$ ip a l</pre>
| |
| on the Beta to check whether it is currently assigned an IP address. Find the entry which begins with <code>eth0</code> and check if it contains a line starting with <code>inet</code> followed by an IP address. If it does, this is the IP address the Beta can be reached at.
| |
|
| |
| Example output with no IP address assigned:
| |
| <pre>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
| |
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| |
| inet 127.0.0.1/8 scope host lo
| |
| valid_lft forever preferred_lft forever
| |
| inet6 ::1/128 scope host
| |
| valid_lft forever preferred_lft forever
| |
| 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
| |
| link/ether 00:0a:35:00:01:26 brd ff:ff:ff:ff:ff:ff
| |
| inet6 fe80::20a:35ff:fe00:126/64 scope link
| |
| valid_lft forever preferred_lft forever</pre>
| |
|
| |
| =====Set IP address=====
| |
|
| |
| If the IP address check is not successful – in that it does not produce an IP address you can connect to – you will have to set your Beta's IP address manually with the <code>ifconfig</code> command.
| |
|
| |
| While connected to the Beta, you can do that like so:
| |
| <pre>$ ifconfig eth0 192.168.0.9/24 up</pre>
| |
|
| |
| It does not really matter which IP address you choose as long as it is one allowed for private use (e.g. addresses in the <code>192.168.x.x</code> range) and you make sure to use the <code>/24</code> prefix.
| |
| Note that this will set the IP only until you reboot the camera - then the IP has to be set this same way. A more permanenty solution is using a router and connecting your camera and computer. Then the router assigns IPs using DHCP automatically.
| |
|
| |
| If you now use <code>$ ip a l</code> (again) to check for the camera's IP address, you should see the address you assigned listed after <code>inet</code>, e.g.:
| |
|
| |
| <pre>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
| |
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| |
| inet 127.0.0.1/8 scope host lo
| |
| valid_lft forever preferred_lft forever
| |
| inet6 ::1/128 scope host
| |
| valid_lft forever preferred_lft forever
| |
| 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
| |
| link/ether 00:0a:35:00:01:26 brd ff:ff:ff:ff:ff:ff
| |
| inet 192.168.0.9/24 brd 192.168.0.255 scope global dynamic eth0
| |
| valid_lft 172739sec preferred_lft 172739sec
| |
| inet6 fe80::20a:35ff:fe00:126/64 scope link
| |
| valid_lft forever preferred_lft forever
| |
| </pre>
| |
|
| |
| ====Establish a connection via Key====
| |
|
| |
| Now we have the network configured we need to copy over our SSH key to the Beta.
| |
|
| |
| While connected to the AXIOM Beta via USB, you can use the command:
| |
|
| |
| <code>cd ~/.ssh/
| |
| cp authorized_keys authorized_keys.orig</code>
| |
|
| |
| Strictly speaking the cp (copy) command isn't needed, but it's best practice to always make a copy of a file before editing it - just in case.
| |
|
| |
| The next command will be to add your SSH key to the SSH file which contains the information on who can log into it via SSH without a password.
| |
|
| |
| You will need to first copy (control/command c) - IMPORTANT, make sure that you copy the whole key but do not include the next/new line.
| |
|
| |
| Next, with the command below, you will add your key to the authorized_keys file. The structure of the command below is:
| |
|
| |
| * echo - writes the text after it
| |
| * [your key] - pastes (control/command v) your key, so do not type in [your key]!
| |
| * > - overwrites the existing file and adds just this text
| |
| * authorized_keys - make sure to spell this correctly.
| |
|
| |
| As a heads-up when you paste in your SSH key the terminal window may wrap the text in a way that it looks like a bit of a mess - this is normal and you can then carry on typing in the rest of the command.
| |
|
| |
| <code>echo [yourkey] >> authorized_keys</code>
| |
|
| |
| Alternatively, you can use ssh-copy-id to do it. Don't forget to adapt the IP adress.
| |
|
| |
| <code>ssh-copy-id root@192.168.0.9</code>
| |
|
| |
| Now you have added you key you can then try and ssh into the Beta.
| |
|
| |
| On your computer use the following command - note the IP address will be the one you set earlier, the one used below is just the example IP.
| |
|
| |
| <code>ssh root@192.168.0.9</code>
| |
|
| |
| You should now see the following prompt if you have logged on successfully to the Beta.
| |
|
| |
| <code>Last login: Fri Jun 10 15:12:17 2016
| |
| sourcing .bashrc ...
| |
| [root@beta ~]# </code>
| |
|
| |
| Congratulations, you have now set up the Beta's networking and SSH configuration.
| |
|
| |
| The minicom or screen method you used to connect is no longer needed.
| |
|
| |
| =====Password Based Authentication=====
| |
| If you do not want to use the public/private keypair authentication you can edit /etc/ssh/sshd_config and set
| |
| PasswordAuthentication yes
| |
| PermitRootLogin yes
| |
|
| |
| Please note though that this can be a security vulnerability (especially if you do not change the default credentials) and connect your Beta directly to the Internet.
| |
|
| |
| ==Start the camera==
| |
|
| |
| As development of the Beta continues the camera will initialize all systems and train the sensor communication automatically when powered on, but for now you will have to manually start this yourself.
| |
|
| |
| Run the following command:
| |
|
| |
| ./kick_manual.sh
| |
|
| |
| You will see a lot of output, the tail of it is below.
| |
|
| |
| ..
| |
| mapped 0x8030C000+0x00004000 to 0x8030C000.
| |
| mapped 0x80000000+0x00400000 to 0xA6961000.
| |
| mapped 0x18000000+0x08000000 to 0x18000000.
| |
| read buffer = 0x18390200
| |
| selecting RFW [bus A] ...
| |
| found MXO2-1200HC [00000001001010111010000001000011]
| |
| [root@beta ~]#
| |
|
| |
| If you look at the back of the camera you will now see a blue LED near the top flashing very fast - this indicates everything is now running.
| |
|
| |
| If you turn the camera off when you turn it back on you will need to re-run this command.
| |
|
| |
| ==Capture an image==
| |
|
| |
| For writing uncompressed full resolution full bitdepth raw image the AXIOM Beta uses a software called '''''cmv_snap3'''''.
| |
|
| |
| It is located in the /root/ directory and writes the images data directly to STDOUT.
| |
|
| |
| cmv_snap3 writes images in the [[RAW12]] format. Writing one image takes a few seconds depending on where the image is written to so this method is not viable for recording video footage other than timelapse.
| |
|
| |
| ===Documentation===
| |
|
| |
| The following parameters are available:
| |
|
| |
| <nowiki>./cmv_snap3 -h
| |
| This is ./cmv_snap3 V1.10
| |
| options are:
| |
| -h print this help message
| |
| -8 output 8 bit per pixel
| |
| -2 output 12 bit per pixel
| |
| -d dump buffer memory
| |
| -b enable black columns
| |
| -p prime buffer memory
| |
| -r dump sensor registers
| |
| -t enable cmv test pattern
| |
| -z produce no data output
| |
| -e <exp> exposure times
| |
| -v <exp> exposure voltages
| |
| -s <num> shift values by <num>
| |
| -S <val> writer byte strobe
| |
| -R <fil> load sensor registers</nowiki>
| |
|
| |
| ===Examples===
| |
|
| |
| Images can be written directly to the cameras internal micro SD card like this (10 milliseconds exposure time, 16bit):
| |
| ./cmv_snap3 -e 10ms > image.raw16
| |
|
| |
| Write image plus metadata (sensor configuration) to cameras internal micro SD card (20 milliseconds exposure time, 12bit):
| |
| ./cmv_snap3 -2 -r -e 20ms > image.raw12
| |
|
| |
| You can also use cmv_snap3 to change to exposure time (to 5 milliseconds in this example) without actually capturing an image, for the that -z parameter is used to not produce any data output:
| |
| ./cmv_snap3 -z -e 5ms
| |
|
| |
|
| |
| That cmv_snap3 writes data to STDOUT makes it very versatile, we can for example capture images from and to a remote Linux machine connected to the Beta via Ethernet easily (lets assume the AXIOM Betas camera IP is set up as: 192.168.0.9 - SSH access has to be set up for this to work with a keypair)
| |
| ssh root@192.168.0.9 "./cmv_snap3 -2 -r -e 10ms" > snap.raw12
| |
|
| |
| To pipe the data into a file and display it at the same time with imagemagick on a remote machine:
| |
| ssh root@192.168.0.9 "./cmv_snap3 -2 -r -e 10ms" | tee snap.raw12 | display -size 4096x3072 -depth 12 gray:-
| |
|
| |
| Use imagemagick to convert raw12 file into a color preview image:
| |
| cat test.raw12 | convert \( -size 4096x3072 -depth 12 gray:- \) \( -clone 0 -crop -1-1 \) \( -clone 0 -crop -1+0 \) \( -clone 0 -crop +0-1 \) -sample 2048x1536 \( -clone 2,3 -average \) -delete 2,3 -swap 0,1 +swap -combine test_color.png
| |
|
| |
| With raw2dng compiled inside the camera you can capture images directly to DNG, without saving the raw12:
| |
|
| |
| ./cmv_snap3 -2 -b -r -e 10ms | raw2dng snap.DNG
| |
|
| |
| Note: Supplying exposure time as parameter is required otherwise cmv_snap3 will not capture an image.
| |
| The exposure time can be supplied in "s" (seconds), "ms" (milliseconds), "us" (microseconds) and "ns" (nanoseconds). Decimal values also work (eg. "15.5ms").
| |
|
| |
| ==Overlay Images==
| |
|
| |
| This section covers the mimg version 1.8 (see https://github.com/apertus-open-source-cinema/beta-software/tree/master/mimg), not the previous 1.6.
| |
|
| |
| AXIOM Beta features a full HD framebuffer that can be altered from the Linux userspace and is automatically "mixed" with the real time video from the image sensor on HDMI outputs.
| |
|
| |
| The overlay could also be used to draw live histograms/scopes/HUD or menus.
| |
|
| |
| The overlay in more recent firmware revisions supports alpha channel transparency.
| |
|
| |
| ===Internals===
| |
| The raw memory image is saved the following way: <ch0/12bit><ch1/12bit><ch2/12bit><ch3/12bit><overlay/16bit>
| |
|
| |
| That means for every 4 sensels there is only one overlay pixel. Meaning while the CMV12000 image sensor is 4Kx3K the overlay is Full HD (1080p).
| |
|
| |
| ===Prepare Overlay Images===
| |
|
| |
| Convert 24bit PNG (1920x1080 pixels) with transparency to AXIOM Beta raw format:
| |
| convert input.png rgba:output.rgb
| |
|
| |
| Note that this image format is different as [[RAW12]]
| |
|
| |
| ===mimg===
| |
|
| |
| ''mimg'' is the software running on the camera used to load/alter anything related to overlays or test images.
| |
|
| |
| Source Code:
| |
|
| |
| https://github.com/apertus-open-source-cinema/beta-software/tree/master/mimg
| |
|
| |
| <nowiki>This is ./mimg V1.8
| |
| options are:
| |
| -h print this help message
| |
| -a load all buffers
| |
| -o load as overlay
| |
| -O load as color overlay
| |
| -r load raw data
| |
| -w use word sized data
| |
| -D <val> image color depth
| |
| -W <val> image width
| |
| -H <val> image height
| |
| -P <val> uniform pixel color
| |
| -T <val> load test pattern
| |
| -B <val> memory mapping base
| |
| -S <val> memory mapping size
| |
| -A <val> memory mapping address</nowiki>
| |
|
| |
| ===Examples===
| |
|
| |
| clear overlay:
| |
| ./mimg -a -o -P 0
| |
|
| |
|
| |
| load monochrome overlay:
| |
| ./mimg -o -a file.raw
| |
|
| |
|
| |
| load color overlay:
| |
| ./mimg -O -a file.raw
| |
|
| |
|
| |
| enable overlay:
| |
| gen_reg 11 0x0104F000
| |
|
| |
|
| |
| disable overlay:
| |
| gen_reg 11 0x0004F000
| |
|
| |
| ===Old overlays===
| |
|
| |
| Overlays for mimg 1.6 are not compatible anymore. You can use
| |
|
| |
| convert -size 1920x1080 -depth 6 rgba:overlay_04.rgb overlay_04.png
| |
|
| |
| To convert them to PNG before continuing with the preparation above.
| |
|
| |
| ==Misc Scripts== | | ==Misc Scripts== |
|
| |
|
| Line 368: |
Line 4: |
| ./pac1720_info.sh | | ./pac1720_info.sh |
| Output: | | Output: |
| <nowiki>ZED_5V 5.0781 V [2080] +29.0625 mV [2e8] +968.75 mA | | ZED_5V 5.0781 V [2080] +29.0625 mV [2e8] +968.75 mA<br /> |
| BETA_5V 5.1172 V [20c0] +26.6016 mV [2a9] +886.72 mA | | BETA_5V 5.1172 V [20c0] +26.6016 mV [2a9] +886.72 mA<br /> |
| HDN 3.2422 V [14c0] -0.0391 mV [fff] -1.30 mA | | HDN 3.2422 V [14c0] -0.0391 mV [fff] -1.30 mA<br /> |
| PCIE_N_V 3.2422 V [14c0] -0.0391 mV [fff] -1.30 mA | | PCIE_N_V 3.2422 V [14c0] -0.0391 mV [fff] -1.30 mA<br /> |
| HDS 3.2422 V [14c0] +0.0000 mV [000] +0.00 mA | | HDS 3.2422 V [14c0] +0.0000 mV [000] +0.00 mA<br /> |
| PCIE_S_V 3.2422 V [14c0] -0.0391 mV [fff] -1.30 mA | | PCIE_S_V 3.2422 V [14c0] -0.0391 mV [fff] -1.30 mA<br /> |
| RFW_V 3.2812 V [1500] +0.2734 mV [007] +9.11 mA | | RFW_V 3.2812 V [1500] +0.2734 mV [007] +9.11 mA<br /> |
| IOW_V 3.2422 V [14c0] +0.0000 mV [000] +0.00 mA | | IOW_V 3.2422 V [14c0] +0.0000 mV [000] +0.00 mA<br /> |
| RFE_V 3.2812 V [1500] +0.2344 mV [006] +7.81 mA | | RFE_V 3.2812 V [1500] +0.2344 mV [006] +7.81 mA<br /> |
| IOE_V 3.2812 V [1500] +0.0781 mV [002] +2.60 mA | | IOE_V 3.2812 V [1500] +0.0781 mV [002] +2.60 mA<br /> |
| VCCO_35 2.5000 V [1000] +0.6641 mV [011] +22.14 mA | | VCCO_35 2.5000 V [1000] +0.6641 mV [011] +22.14 mA<br /> |
| VCCO_13 2.4609 V [ fc0] +1.2500 mV [020] +41.67 mA | | VCCO_13 2.4609 V [ fc0] +1.2500 mV [020] +41.67 mA<br /> |
| PCIE_IO 2.4609 V [ fc0] -0.0391 mV [fff] -1.30 mA | | PCIE_IO 2.4609 V [ fc0] -0.0391 mV [fff] -1.30 mA<br /> |
| VCCO_34 2.4609 V [ fc0] +0.8203 mV [015] +27.34 mA | | VCCO_34 2.4609 V [ fc0] +0.8203 mV [015] +27.34 mA<br /> |
| W_VW 1.9922 V [ cc0] -0.0781 mV [ffe] -2.60 mA | | W_VW 1.9922 V [ cc0] -0.0781 mV [ffe] -2.60 mA<br /> |
| N_VW 3.1641 V [1440] +0.0000 mV [000] +0.00 mA | | N_VW 3.1641 V [1440] +0.0000 mV [000] +0.00 mA<br /> |
| N_VN 1.8750 V [ c00] +15.4297 mV [18b] +514.32 mA | | N_VN 1.8750 V [ c00] +15.4297 mV [18b] +514.32 mA<br /> |
| N_VE 3.1641 V [1440] +0.0000 mV [000] +0.00 mA | | N_VE 3.1641 V [1440] +0.0000 mV [000] +0.00 mA<br /> |
| E_VE 1.9922 V [ cc0] -0.0391 mV [fff] -1.30 mA | | E_VE 1.9922 V [ cc0] -0.0391 mV [fff] -1.30 mA<br /> |
| S_VE 1.9531 V [ c80] +0.0000 mV [000] +0.00 mA | | S_VE 1.9531 V [ c80] +0.0000 mV [000] +0.00 mA<br /> |
| S_VS 2.9297 V [12c0] +0.3906 mV [00a] +13.02 mA | | S_VS 2.9297 V [12c0] +0.3906 mV [00a] +13.02 mA<br /> |
| S_VW 1.9922 V [ cc0] -0.1562 mV [ffc] -5.21 mA | | S_VW 1.9922 V [ cc0] -0.1562 mV [ffc] -5.21 mA |
| </nowiki>
| |
|
| |
|
| Read Temperature on Zynq: | | Read Temperature on Zynq: |
| Line 397: |
Line 32: |
| ZYNQ Temp 49.9545 °C | | ZYNQ Temp 49.9545 °C |
|
| |
|
| ==HDMI Output== | | ==Image Processing Nodes== |
| | |
| [[AXIOM_Beta/device_compatibility | List of tested AXIOM Beta compatible devices]]
| |
| | |
| HDMI is a two-way communication protocol and supports a ton of different formats/frequencies/specs.
| |
| Many monitors/recorders only support a subset of these formats and expect signals to conform to certain values. These values are not documented publicly so we are currently in the process of debugging device compatibility one by one. The good thing is that its a pure software thing and we can add support and test compatibility with additional devices as we go.
| |
| | |
| In general we discovered that monitors are more flexible when it comes to HDMI (TMDS) freqencies as they just "tune" into (sync to) the provided clock/data rate. Recorders expect signals to be in a much more stricter/narrow range and will not work (show "no signal") if there is a minor deviation.
| |
| | |
| Watch this 33C3 talk by Tim Ansell about "Discecting HDMI": https://media.ccc.de/v/33c3-8057-dissecting_hdmi to get insight into how HDMI works.
| |
| | |
| Settings for VSync, HSync, etc. inside the AXIOM Beta can be found in:
| |
| /root/gen_init.sh
| |
| | |
| For example the Atomos SHOGUN was found to work with these HDMI parameters:
| |
| | |
| <nowiki>
| |
| scn_reg 0 2200 # total_w
| |
| scn_reg 1 1125 # total_h
| |
| scn_reg 2 60 # total_f
| |
| | |
| scn_reg 4 262 # hdisp_s
| |
| scn_reg 5 2182 # hdisp_e
| |
| scn_reg 6 45 # vdisp_s
| |
| scn_reg 7 1125 # vdisp_e
| |
| | |
| scn_reg 8 0 # hsync_s
| |
| scn_reg 9 2100 # hsync_e
| |
| scn_reg 10 4 # vsync_s
| |
| scn_reg 11 9 # vsync_e
| |
| | |
| scn_reg 32 252 # pream_s
| |
| scn_reg 33 260 # guard_s
| |
| scn_reg 34 294 # terc4_e
| |
| scn_reg 35 296 # guard_e</nowiki>
| |
| | |
| Currently it is not possible to alter TMDS and Clock frequencies from the userspace (requires new FPGA bitstream).
| |
| | |
| For the firmware there are two modes available, the 30Hz and 60Hz variant. You can switch between them quite easily.
| |
| | |
| cmv_hdmi3.bit is the FPGA bitstream loaded for the HDMI interface. We use symlinks to switch this file easily.
| |
| | |
| Before doing this, don't forget to check if the files (cmv_hdmi3_60.bit or cmv_hdmi3_30.bit) really exist in the /root folder.
| |
| | |
| The output is always in 8bpc RGB color space without subsampling (4:4:4). Not all capture devices can manage this.
| |
| | |
| Other modes like YCrCb, etc. are currently not supported.
| |
| | |
| ===Enable 1080p60 Mode===
| |
| rm -f cmv_hdmi3.bit
| |
| ln -s cmv_hdmi3_60.bit cmv_hdmi3.bit
| |
| sync
| |
| reboot now
| |
| | |
| ===Enable 1080p30 Mode===
| |
| rm -f cmv_hdmi3.bit
| |
| ln -s cmv_hdmi3_30.bit cmv_hdmi3.bit
| |
| sync
| |
| reboot now
| |
|
| |
|
| ===Generator and HDMI Output===
| |
| Independet of the firmware you can switch the rate of the generator. In setup.sh you can change the generator resolution and framerate.
| |
|
| |
| After changing the generator mode, make sure to restart it:
| |
|
| |
| ./halt_manual.sh && ./kick_manual.sh
| |
|
| |
| ./gen_init.sh 1080p60
| |
| ./gen_init.sh 1080p50
| |
| ./gen_init.sh 1080p25
| |
|
| |
| To enable the shogun mode, which is only possibly by current hardware:
| |
| ./gen_init.sh SHOGUN
| |
|
| |
| 1080p25 mode is known to work on the Shogun if using the SHOGUN profile and then setting
| |
| scn_reg 0 2640
| |
|
| |
| In Shogun mode, the exposure (shutter) is synced to the output frame rate, but can be a multiple, i.e. with 60FPS output, it can be 60, 30, 20, 15, 12, ... The exposure time (shutter angle if divided by FPS) is entirely controlled by the sensor at the moment.
| |
|
| |
| Note that the firmware controls the shutter, not the generator.
| |
|
| |
| In the future, this will be combined and processed by only one piece of software.
| |
|
| |
| =Image Processing Pipeline=
| |
|
| |
| Draft pipeline taken from AXIOM Alpha for now.
| |
|
| |
|
| |
| Image Acquisition Pipeline:
| |
|
| |
| [[File:Image04.png]]
| |
|
| |
|
| |
| HDMI Image Processing Pipeline:
| |
|
| |
| [[File:Image01.png]]
| |
|
| |
| ==Image Processing Nodes==
| |
| ===Debayering=== | | ===Debayering=== |
|
| |
|
| A planned feature is to generate this FPGA code block with "dynamic reconfiguration" meaning that the actual debayering algorithm can be replaced at any time by loading a new FPGA binary block at run-time. | | A planned feature is to generate this FPGA code block with "dynamic reconfiguration" meaning that the actual debayering algorithm can be replaced at any time by loading a new FPGA binary block at run-time. |
| | |
| This tries to simplify creating custom debayering algorithms with a script like programming language that can be translated to FPGA code and loaded into the FPGA dynamically for testing. | | This tries to simplify creating custom debayering algorithms with a script like programming language that can be translated to FPGA code and loaded into the FPGA dynamically for testing. |
|
| |
|
| Line 510: |
Line 50: |
|
| |
|
| '''Potential Problems:''' | | '''Potential Problems:''' |
| | |
| * there are sharper and softer lenses so the threshold depends on the glass currently used. For a sharp lens the peaking could show areas as "in-focus" if they actually aren't and for softer lenses the peaking might never show up at all because the threshold is never reached | | * there are sharper and softer lenses so the threshold depends on the glass currently used. For a sharp lens the peaking could show areas as "in-focus" if they actually aren't and for softer lenses the peaking might never show up at all because the threshold is never reached |
|
| |
|
| ===Image Blow Up / Zoom Proposal=== | | ===Image Blow Up / Zoom Proposal=== |
| | |
| Digital zoom into the center area of the image to check focus. | | Digital zoom into the center area of the image to check focus. |
|
| |
|
| Line 518: |
Line 60: |
|
| |
|
| [[File:20140909152450-look-around.jpg | 300px]] | | [[File:20140909152450-look-around.jpg | 300px]] |
|
| |
|
| |
|
| This feature is also related to the "Look Around" where the viewfinder sees a larger image area than is being output to the clean-feed. | | This feature is also related to the "Look Around" where the viewfinder sees a larger image area than is being output to the clean-feed. |
|
| |
|
| This re-sampling method to scale up/down an image in real-time can be of rather low quality (nearest neighbor/bilinear/etc.) as it is only for preview purposes. | | This re-sampling method to scale up/down an image in real-time can be of rather low quality (nearest neighbor/bilinear/etc.) as it is only for preview purposes. |
|
| |
|
| |
| =Tools=
| |
| ==cmv_reg==
| |
| Get and Set CMV12000 image sensor registers (CMV12000 sports 128x16 Bit registers).
| |
|
| |
| Details are in the sensor datasheet: https://github.com/apertus-open-source-cinema/beta-hardware/tree/master/Datasheets
| |
|
| |
|
| |
| '''Examples:'''
| |
|
| |
| Read register 115 (which contains the analog gain settings):
| |
| cmv_reg 115
| |
|
| |
| Return value:
| |
| 0x00
| |
| Means we are currently operating at analog gain x1 = unity gain
| |
|
| |
|
| |
|
| |
| Set register 115 to gain x2:
| |
| cmv_reg 115 1
| |
|
| |
| ==set_gain.sh==
| |
|
| |
| Set gain and related settings (ADC range and offsets).
| |
|
| |
| ./set_gain.sh 1
| |
| ./set_gain.sh 2
| |
| ./set_gain.sh 3/3 # almost the same as gain 1
| |
| ./set_gain.sh 3
| |
| ./set_gain.sh 4
| |
|
| |
|
| |
| ==gamma_conf.sh==
| |
|
| |
| Set the gamma value:
| |
|
| |
| ./gamma_conf 0.4
| |
| ./gamma_conf 0.9
| |
| ./gamma_conf 1
| |
| ./gamma_conf 2
| |
|
| |
| ==Setting Exposure Time==
| |
|
| |
| To set the exposure time use the cmv_snap3 tool with -z parameter (this will tell the software to not save the image):
| |
|
| |
| ./cmv_snap3 -e 9.2ms -z
| |
|
| |
| Note: The exposure time can be supplied in "s" (seconds), "ms" (milliseconds), "us" (microseconds) and "ns" (nanoseconds). Decimal values also work (eg. "15.5ms").
| |
|
| |
|
| |
| ==mat4_conf.sh==
| |
|
| |
| Read the details about the [[Matrix Color Conversion]] math/implementation.
| |
|
| |
| To set the 4x4 color conversion matrix, you can use the mat4_conf.sh script:
| |
|
| |
| The default configuration:
| |
| ./mat4_conf.sh 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0
| |
| '''
| |
| Please note that in current AXIOM Beta firmware the mat4 order is changed and the default matrix is:
| |
| ./mat4_conf.sh 0.3 0.3 0.3 0.3 0 0 0 1 0 0.42 0.42 0 1 0 0 0
| |
| This will be changed to reflect the documentation again soon.'''
| |
|
| |
| This 4x4 conversion matrix is a very powerful tool and allows to do things like mixing color channels, reassigning channels, applying effects or doing white balancing.
| |
|
| |
| TODO: order is blue, green, red!
| |
|
| |
| [[File:Mat4-conf-illustration-01.jpg | 700px]]
| |
|
| |
| ===4x4 Matrix Examples:===
| |
| ./mat4_conf.sh 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 # unity matrix but not optimal as both green channels are processed separately
| |
| ./mat4_conf.sh 1 0 0 0 0 0.5 0.5 0 0 0.5 0.5 0 0 0 0 1 0 0 0 0 # the two green channels inside each 2x2 pixel block are averaged and output on both green pixels
| |
| ./mat4_conf.sh 0 0 0 1 0 1 0 0 0 0 1 0 1 0 0 0 0 0 0 0 # red and blue are swapped
| |
| ./mat4_conf.sh 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0.5 0 0 0 # red 50% brigther
| |
| ./mat4_conf.sh 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1.5 0 0 0 0 # blue multiplied with factor 1.5
| |
| ./mat4_conf.sh .25 .25 .25 .25 .25 .25 .25 .25 .25 .25 .25 .25 .25 .25 .25 .25 0 0 0 0 # black/white
| |
| ./mat4_conf.sh -1 0 0 0 0 -0.5 -0.5 0 0 -0.5 -0.5 0 0 0 0 -1 1 1 1 1 # negative
| |
|
| |
|
| == Clipping == | | == Clipping == |
|
| |
|
| scn_reg 28 0x00 # deactivate clipping | | scn_reg 28 0x00 # deactivate clipping<br /> |
| scn_reg 28 0x10 # activate low clipping | | scn_reg 28 0x10 # activate low clipping<br /> |
| scn_reg 28 0x20 # activate high clipping | | scn_reg 28 0x20 # activate high clipping<br /> |
| scn_reg 28 0x30 # activate high+low clipping | | scn_reg 28 0x30 # activate high+low clipping |
|
| |
| =General Info=
| |
| Stop HDMI live stream:
| |
| fil_reg 15 0
| |
| Start HDMI live stream:
| |
| fil_reg 15 0x01000100
| |
|
| |
|
| ==Operating System== | | ==Operating System== |
| Line 623: |
Line 79: |
| I would suggest running Arch Linux on the AXIOM Beta for development purposes. If we need to shrink it down that will be quite trivial. Obviously we can take the embedded approach from there, as long as we don't fall in the trap of libc implementations with broken threading. | | I would suggest running Arch Linux on the AXIOM Beta for development purposes. If we need to shrink it down that will be quite trivial. Obviously we can take the embedded approach from there, as long as we don't fall in the trap of libc implementations with broken threading. |
|
| |
|
| ===Packet Manager Pacman=== | | ==Pattern noise correction== |
| | |
| Update all package definitions and the database from the Internet:
| |
| pacman -Sy
| |
| | |
| '''Careful with upgrading existing packages. For example the Kernel used in the AXIOM Beta is custom developed - if you upgrade Arch Linux to the latest off the shelf Kernel you will BRICK your camera.
| |
| '''
| |
| | |
| | |
| Install lighttp webserver on the Beta:
| |
| pacman -S lighttpd
| |
| | |
| Install PHP on the Beta:
| |
| pacman -S php php-cgi
| |
| | |
| Follow these instructions: https://wiki.archlinux.org/index.php/lighttpd#PHP
| |
| | |
| Start the webserver:
| |
| systemctl start lighttpd
| |
| | |
| ==Moving Image Raw Recording/Processing==
| |
| | |
| ===Enable Raw recording mode===
| |
| | |
| Note: This experimental raw mode works only in 1080p60 (A+B Frames) and is only tested with the Atomos Shogun currently.
| |
| | |
| To measure the required compensations with a different recorder follow this guide: [[raw processing recorder benchmarking | this guide]]
| |
| | |
| This mode requires darkframes which are created in the course of a camera [[Factory Calibration]]. Early Betas are not calibrated yet - this step needs to be completed by the user.
| |
| | |
| Enable raw recording mode:
| |
| | |
| ./hdmi_rectest.sh
| |
| | |
| Inside that script the following command is worth noting:
| |
| | |
| Enable experimental raw mode:
| |
| scn_reg 31 0x0A01
| |
|
| |
|
| Disable experimental raw mode:
| | --rnfilter=1 : FIR filter for row noise correction from black columns<br /> |
| scn_reg 31 0x0001 | | --rnfilter=2 : FIR filter for row noise correction from black columns and per-row median differences in green channels<br /> |
| | | --fixrn : Fix row noise by image filtering (slow, guesswork)<br /> |
| | | --fixpn : Fix row and column noise (SLOW, guesswork)<br /> |
| if you get an error report like this:
| | --fixrnt : Temporal row noise fix (use with static backgrounds; recommended)<br /> |
| <nowiki>Traceback (most recent call last): | | --fixpnt : Temporal row/column noise fix (use with static backgrounds)<br /> |
| File "rcn_darkframe.py", line 17, in <module>
| | --no-blackcol-rn : Disable row noise correction from black columns (they are still used to correct static offsets)<br /> |
| import png
| | --no-blackcol-ff : Disable fixed frequency correction in black columns |
| ImportError: No module named 'png'</nowiki>
| |
| | |
| Make sure the Beta is connected to the Internet via Ethernet and run:
| |
| pip install pypng | |
| | |
| ===Processing===
| |
| | |
| Postprocessing software to recover the raw information (DNG sequences) is on github: https://github.com/apertus-open-source-cinema/misc-tools-utilities/tree/master/raw-via-hdmi
| |
| | |
| required packages: ffmpeg build-essentials
| |
| | |
| Mac requirements for compiling: gcc4.9(via homebrew):
| |
| brew install homebrew/versions/gcc49
| |
| | |
| also install ffmpeg
| |
| | |
| To do all the raw processing in one single command (after ffmpeg codec copy processing):
| |
| ./hdmi4k INPUT.MOV - | ./raw2dng --fixrnt --pgm --black=120 frame%05d.dng | |
| | |
| ===hdmi4k===
| |
| Converts a video file recorded in AXIOM raw to a PGM image sequence and applies the darkframe (needs to be created beforehand).
| |
| | |
| Currently clips must go through ffmpeg before hdmi4k can read them:
| |
| ffmpeg -i CLIP.MOV -c:v copy OUTPUT.MOV | |
| | |
| To cut out a video between IN and OUT with ffmpeg but maintaing the original encoding data:
| |
| ffmpeg -i CLIP.MOV -ss IN_SECONDS -t DURATION_SECONDS -c:v copy OUTPUT.MOV
| |
| | |
| <nowiki>
| |
| hdmi4k
| |
| HDMI RAW converter for Axiom BETA
| |
| | |
| Usage:
| |
| ./hdmi4k clip.mov
| |
| raw2dng frame*.pgm [options]
| |
| | |
| Calibration files:
| |
| hdmi-darkframe-A.ppm, hdmi-darkframe-B.ppm:
| |
| averaged dark frames from the HDMI recorder (even/odd frames)
| |
| | |
| Options:
| |
| - : Output PGM to stdout (can be piped to raw2dng)
| |
| --3x3 : Use 3x3 filters to recover detail (default 5x5)
| |
| --skip : Toggle skipping one frame (try if A/B autodetection fails)
| |
| --swap : Swap A and B frames inside a frame pair (encoding bug?) | |
| --onlyA : Use data from A frames only (for bad takes) | |
| --onlyB : Use data from B frames only (for bad takes)</nowiki>
| |
| | |
| | |
| ===raw2dng===
| |
| Converts AXIOM Beta raw image to DNG.
| |
| | |
| <nowiki>DNG converter for Apertus .raw12 files | |
| | |
| Usage:
| |
| ./raw2dng input.raw12 [input2.raw12] [options]
| |
| cat input.raw12 | ./raw2dng output.dng [options]
| |
|
| |
|
| Flat field correction: | | Flat field correction: |
| - for each gain (N=1,2,3,4), you may use the following reference images:
| |
| - darkframe-xN.pgm will be subtracted (data is x8 + 1024)
| |
| - dcnuframe-xN.pgm will be multiplied by exposure and subtracted (x8192 + 8192)
| |
| - gainframe-xN.pgm will be multiplied (1.0 = 16384)
| |
| - clipframe-xN.pgm will be subtracted from highlights (x8)
| |
| - reference images are 16-bit PGM, in the current directory
| |
| - they are optional, but gain/clip frames require a dark frame
| |
| - black ref columns will also be subtracted if you use a dark frame.
| |
|
| |
| Creating reference images:
| |
| - dark frames: average as many as practical, for each gain setting,
| |
| with exposures ranging from around 1ms to 50ms:
| |
| raw2dng --calc-darkframe *-gainx1-*.raw12
| |
| - DCNU (dark current nonuniformity) frames: similar to dark frames,
| |
| just take a lot more images to get a good fit (use 256 as a starting point):
| |
| raw2dng --calc-dcnuframe *-gainx1-*.raw12
| |
| (note: the above will compute BOTH a dark frame and a dark current frame)
| |
| - gain frames: average as many as practical, for each gain setting,
| |
| with a normally exposed blank OOF wall as target, or without lens
| |
| (currently used for pattern noise reduction only):
| |
| raw2dng --calc-gainframe *-gainx1-*.raw12
| |
| - clip frames: average as many as practical, for each gain setting,
| |
| with a REALLY overexposed blank out-of-focus wall as target:
| |
| raw2dng --calc-clipframe *-gainx1-*.raw12
| |
| - Always compute these frames in the order listed here
| |
| (dark/dcnu frames, then gain frames (optional), then clip frames (optional).
| |
|
| |
| General options:
| |
| --black=%d : Set black level (default: 128)
| |
| - negative values allowed
| |
| --white=%d : Set white level (default: 4095)
| |
| - if too high, you may get pink highlights
| |
| - if too low, useful highlights may clip to white
| |
| --width=%d : Set image width (default: 4096)
| |
| --height=%d : Set image height
| |
| - default: autodetect from file size
| |
| - if input is stdin, default is 3072
| |
| --swap-lines : Swap lines in the raw data
| |
| - workaround for an old Beta bug
| |
| --hdmi : Assume the input is a memory dump
| |
| used for HDMI recording experiments
| |
| --pgm : Expect 16-bit PGM input from stdin
| |
|
| |
| --lut : Use a 1D LUT (lut-xN.spi1d, N=gain, OCIO-like)
| |
|
| |
| --totally-raw : Copy the raw data without any manipulation
| |
| - metadata and pixel reordering are allowed.
| |
|
| |
|
| Pattern noise correction:
| | --dchp : Measure hot pixels to scale dark current frame<br /> |
| --rnfilter=1 : FIR filter for row noise correction from black columns
| | --no-darkframe : Disable dark frame (if darkframe-xN.pgm is present)<br /> |
| --rnfilter=2 : FIR filter for row noise correction from black columns
| | --no-dcnuframe : Disable dark current frame (if dcnuframe-xN.pgm is present)<br /> |
| and per-row median differences in green channels
| | --no-gainframe : Disable gain frame (if gainframe-xN.pgm is present)<br /> |
| --fixrn : Fix row noise by image filtering (slow, guesswork)
| | --no-clipframe : Disable clip frame (if clipframe-xN.pgm is present)<br /> |
| --fixpn : Fix row and column noise (SLOW, guesswork)
| | --no-blackcol : Disable black reference column subtraction: - enabled by default if a dark frame is used. - reduces row noise and black level variations<br /> |
| --fixrnt : Temporal row noise fix (use with static backgrounds; recommended)
| | --calc-darkframe : Average a dark frame from all input files<br /> |
| --fixpnt : Temporal row/column noise fix (use with static backgrounds)
| | --calc-dcnuframe : Fit a dark frame (constant offset) and a dark current frame (exposure-dependent offset) from files with different exposures (starting point: 256 frames with exposures from 1 to 50 ms)<br /> |
| --no-blackcol-rn : Disable row noise correction from black columns
| | --calc-gainframe : Average a gain frame (aka flat field frame)<br /> |
| (they are still used to correct static offsets)
| | --calc-clipframe : Average a clip (overexposed) frame<br /> |
| --no-blackcol-ff : Disable fixed frequency correction in black columns
| | --check-darkframe : Check image quality indicators on a dark frame |
| | |
| Flat field correction:
| |
| --dchp : Measure hot pixels to scale dark current frame | |
| --no-darkframe : Disable dark frame (if darkframe-xN.pgm is present) | |
| --no-dcnuframe : Disable dark current frame (if dcnuframe-xN.pgm is present) | |
| --no-gainframe : Disable gain frame (if gainframe-xN.pgm is present) | |
| --no-clipframe : Disable clip frame (if clipframe-xN.pgm is present) | |
| --no-blackcol : Disable black reference column subtraction | |
| - enabled by default if a dark frame is used
| |
| - reduces row noise and black level variations
| |
| --calc-darkframe : Average a dark frame from all input files | |
| --calc-dcnuframe : Fit a dark frame (constant offset) and a dark current frame | |
| (exposure-dependent offset) from files with different exposures
| |
| (starting point: 256 frames with exposures from 1 to 50 ms)
| |
| --calc-gainframe : Average a gain frame (aka flat field frame) | |
| --calc-clipframe : Average a clip (overexposed) frame | |
| --check-darkframe : Check image quality indicators on a dark frame | |
|
| |
|
| Debug options: | | Debug options: |
| --dump-regs : Dump sensor registers from metadata block (no output DNG)
| |
| --fixpn-dbg-denoised: Pattern noise: show denoised image
| |
| --fixpn-dbg-noise : Pattern noise: show noise image (original - denoised)
| |
| --fixpn-dbg-mask : Pattern noise: show masked areas (edges and highlights)
| |
| --fixpn-dbg-col : Pattern noise: debug columns (default: rows)
| |
| --export-rownoise : Export row noise data to octave (rownoise_data.m)
| |
| --get-pixel:%d,%d : Extract one pixel from all input files, at given coordinates,
| |
| and save it to pixel.csv, including metadata. Skips DNG output.
| |
|
| |
|
| </nowiki> | | --dump-regs : Dump sensor registers from metadata block (no output DNG)<br /> |
| | --fixpn-dbg-denoised: Pattern noise: show denoised image<br /> |
| | --fixpn-dbg-noise : Pattern noise: show noise image (original - denoised)<br /> |
| | --fixpn-dbg-mask : Pattern noise: show masked areas (edges and highlights)<br /> |
| | --fixpn-dbg-col : Pattern noise: debug columns (default: rows)<br /> |
| | --export-rownoise : Export row noise data to octave (rownoise_data.m)<br /> |
| | --get-pixel:%d,%d : Extract one pixel from all input files, at given coordinates, and save it to pixel.csv, including metadata. Skips DNG output. |
|
| |
|
| Example: | | Example: |
| | |
| ./raw2dng --fixrnt --pgm --black=120 frame%05d.dng | | ./raw2dng --fixrnt --pgm --black=120 frame%05d.dng |
|
| |
| ====Compiling raw2dng====
| |
| Compiling raw2dng on a 64bit system requires the gcc-multilib package
| |
|
| |
| Ubuntu:
| |
| sudo apt-get install gcc-multilib
| |
|
| |
| openSUSE:
| |
| sudo zypper install gcc-32bit libgomp1-32bit
| |
|
| |
| AXIOM Beta:
| |
| #acquire the source from https://github.com/apertus-open-source-cinema/misc-tools-utilities/tree/master/raw2dng
| |
| #copy files to AXIOM Beta
| |
| #remove "-m32" from Makefile
| |
| #run "make" inside camera
| |
|
| |
| ===EDL Parser===
| |
| This script can take EDLs to reduce the raw conversion/processing to the essential frames that are actually used in an edit.
| |
| This way a finished video edit can be converted to raw DNG sequences easily.
| |
|
| |
| Requirements: ruby
| |
|
| |
| <nowiki>puts "BEFORE EXECUTION, PLS FILL IN YOUR WORK DIRECTORY IN THE SCRIPT (path_to_workdir)"
| |
|
| |
|
| |
| puts "#!/bin/bash"
| |
| i=0
| |
| ffmpeg_cmd1 = "ffmpeg -i "
| |
|
| |
| tc_in = Array.new
| |
| tc_out = Array.new
| |
| clip = Array.new
| |
|
| |
| file = ARGV.first
| |
| ff = File.open(file, "r")
| |
|
| |
| ff.each_line do |line|
| |
| clip << line.scan(/NAME:\s(.+)/)
| |
| tc_in << line.scan(/(\d\d:\d\d:\d\d:\d\d).\d\d:\d\d:\d\d:\d\d.\d\d:\d\d:\d\d:\d\d.\d\d:\d\d:\d\d:\d\d/)
| |
| tc_out << line.scan(/\s\s\s\d\d:\d\d:\d\d:\d\d\s(\d\d:\d\d:\d\d:\d\d)/)
| |
|
| |
| end
| |
| c=0
| |
| clip.delete_at(0)
| |
| clip.each do |fuck|
| |
| if clip[c].empty?
| |
| tc_in[c] = []
| |
| tc_out[c] = []
| |
| end
| |
| c=c+1
| |
| end
| |
|
| |
| total_frames = 0
| |
| tc_in = tc_in.reject(&:empty?)
| |
| tc_out = tc_out.reject(&:empty?)
| |
| clip = clip.reject(&:empty?)
| |
| tc_in.each do |f|
| |
| tt_in = String.new
| |
| tt_out = String.new
| |
| tt_in = tc_in[i].to_s.scan(/(\d\d)\D(\d\d)\D(\d\d)\D(\d\d)/)
| |
| tt_out = tc_out[i].to_s.scan(/(\d\d)\D(\d\d)\D(\d\d)\D(\d\d)/)
| |
| framecount = ((tt_out[0][0].to_i-tt_in[0][0].to_i)*60*60*60+(tt_out[0][1].to_i-tt_in[0][1].to_i)*60*60+(tt_out[0][2].to_i-tt_in[0][2].to_i)*60+(tt_out[0][3].to_i-tt_in[0][3].to_i))
| |
| framecount = framecount + 20
| |
| tt_in_ff = (tt_in[0][3].to_i*1000/60)
| |
| frames_in = tt_in[0][0].to_i*60*60*60+tt_in[0][1].to_i*60*60+tt_in[0][2].to_i*60+tt_in[0][3].to_i
| |
| frames_in = frames_in - 10
| |
| new_tt_in = Array.new
| |
| new_tt_in[0] = frames_in/60/60/60
| |
| frames_in = frames_in - new_tt_in[0]*60*60*60
| |
| new_tt_in[1] = frames_in/60/60
| |
| frames_in = frames_in - new_tt_in[1]*60*60
| |
| new_tt_in[2] = frames_in/60
| |
| frames_in = frames_in - new_tt_in[2]*60
| |
| new_tt_in[3] = frames_in
| |
| frames_left = (tt_in[0][0].to_i*60*60*60+(tt_in[0][1].to_i)*60*60+(tt_in[0][2].to_i)*60+(tt_in[0][3].to_i))-10
| |
| new_frames = Array.new
| |
| new_frames[0] = frames_left/60/60/60
| |
| frames_left = frames_left - new_frames[0]*60*60*60
| |
| new_frames[1] = frames_left/60/60
| |
| frames_left = frames_left - new_frames[1]*60*60
| |
| new_frames[2] = frames_left/60
| |
| frames_left = frames_left - new_frames[2]*60
| |
| new_frames[3] = frames_left
| |
| tt_in_ff_new = (new_frames[3]*1000/60)
| |
|
| |
| clip[i][0][0] = clip[i][0][0].chomp("\r")
| |
| path_to_workdir = "'/Volumes/getztron2/April Fool 2016/V'"
| |
| mkdir = "mkdir #{i}\n"
| |
| puts mkdir
| |
| ff_cmd_new = "ffmpeg -ss #{sprintf '%02d', new_frames[0]}:#{sprintf '%02d', new_frames[1]}:#{sprintf '%02d', new_frames[2]}.#{sprintf '%02d', tt_in_ff_new} -i #{path_to_workdir}/#{clip[i][0][0].to_s} -frames:v #{framecount} -c:v copy p.MOV -y"
| |
| puts ff_cmd_new
| |
| puts "./render.sh p.MOV&&\n"
| |
| puts "mv frame*.DNG #{i}/"
| |
| hdmi4k_cmd = "hdmi4k #{path_to_workdir}/frame*[0-9].ppm --ufraw-gamma --soft-film=1.5 --fixrnt --offset=500&&\n"
| |
|
| |
| ff_cmd2 = "ffmpeg -i #{path_to_workdir}/frame%04d-out.ppm -vcodec prores -profile:v 3 #{clip[i][0][0]}_#{i}_new.mov -y&&\n"
| |
| puts "\n\n\n"
| |
| i=i+1
| |
| total_frames = total_frames + framecount
| |
| end
| |
|
| |
| puts "#Total frame: count: #{total_frames}"</nowiki>
| |
|
| |
| Pipe it to a Bash file to have a shell script.
| |
|
| |
| Note from the programmer: This is really unsophisticated and messy. Feel free to alter and share improvements.
| |
|
| |
| ==Userspace==
| |
| Arch Linux comes with systemd, which has one advantage that the boot process is incredible fast. Standard tools such as sshd and dhcpcd have been preinstalled.
| |
|
| |
| One idea to store camera relevant parameters inside the camera and provide access from most programming languages is to use a database like http://en.wikipedia.org/wiki/Berkeley_DB
| |
|
| |
| =Tutorials / Guides / Research / Topics=
| |
|
| |
| [[AXIOM_Beta/AXIOM_Beta_Software/Firmware | AXIOM Beta Firmware]]
| |
|
| |
| [[Installing a webserver on AXIOM Beta]]
| |
|
| |
| [[AXIOM_Beta/Wifi_AP_Setup | Wifi Access Point Setup]]
| |
|
| |
| [[AXIOM Beta as photography camera]]
| |
|
| |
| [[Factory Calibration]]
| |
|
| |
| [[Black Calibration]]
| |
|
| |
| [[Pattern Noise]]
| |
|
| |
| [[PLR]]
| |
|
| |
| [[Sensor Cleaning]]
| |
|
| |
| [[Firmware Image Creation]]
| |
