raspiraw difficulties

[CanPi]

I am using a Pi 3A+ with latest firmware, trying to run raspiraw with HQ camera. I was able to clone raspiraw and make it (buildme did not work, reminder for docs). Then appended the appropriate path as the last line in bashrc.

Code: Select all

pi@raspberrypi:~/raspiraw $ ls -l
total 448
-rw-r--r-- 1 pi pi  12842 Jun  3 12:22 adv7282m_modes.h
-rwxr-xr-x 1 pi pi    146 Jun  3 12:22 buildme
-rwxr-xr-x 1 pi pi   3166 Jun  3 12:22 camera_i2c
-rw-r--r-- 1 pi pi  19474 Jun  3 12:22 imx219_modes.h
-rw-r--r-- 1 pi pi  21853 Jun  3 12:22 imx477_modes.h
-rw-r--r-- 1 pi pi   1534 Jun  3 12:22 LICENCE
-rw-r--r-- 1 pi pi    367 Jun  3 12:22 Makefile
-rw-r--r-- 1 pi pi  27943 Jun  3 12:22 ov5647_modes.h
-rw-r--r-- 1 pi pi   4339 Jun  3 12:22 RaspiCLI.c
-rw-r--r-- 1 pi pi   2213 Jun  3 12:22 RaspiCLI.h
-rw-r--r-- 1 pi pi   8212 Jun  3 13:54 RaspiCLI.o
-rwxr-xr-x 1 pi pi 109024 Jun  3 13:54 raspiraw
-rw-r--r-- 1 pi pi  63824 Jun  3 12:22 raspiraw.c
-rw-r--r-- 1 pi pi 108696 Jun  3 13:54 raspiraw.o
-rw-r--r-- 1 pi pi   2429 Jun  3 12:22 raw_header.h
-rw-r--r-- 1 pi pi  13662 Jun  3 12:22 README.md
drwxr-xr-x 2 pi pi   4096 Jun  3 12:22 res
-rwxr-xr-x 1 pi pi   8856 Jun  3 12:22 rpi3-gpiovirtbuf
drwxr-xr-x 2 pi pi   4096 Jun  3 12:22 tools

Next (note spelling error in line 2):

Code: Select all

pi@raspberrypi:~/raspiraw $ ./camera_i2c
setting GPIO for board revsion: 9020e0
Raspberry Pi3B / Pi3B+ / 3A / 4B(1G/2G/4G)
Set state of 133 to 1
Error: Could not open file `/dev/i2c-0' or `/dev/i2c/0': No such file or directory

And in fact there is no such file or directory there. Also

Code: Select all

pi@raspberrypi:~/raspiraw $ sudo raspiraw -t 10 -md 3 -g 256 -eus 100000 -o /home/pi/Pictures/test/img.raw
sudo: raspiraw: command not found

Reading through the forum did not provide a solution. Any ideas?

[6by9]

You haven't added "i2c_vc=on" to /boot/config.txt to enable i2c-0.

What didn't work about ./buildme?
If you've updated .bashrc you need to log out and in, or reboot, to make it active.

You do NOT need sudo to run raspiraw. Do not get into the habit of just adding sudo to everything.

[CanPi]

Thanks for the pointer, I must have missed that line in the readme. However, I am still getting the same error.

Question: do we have to have I2C and SPI enabled before build/make? I turned them on only after that and rebooted.

buildme just returned the command line, without comments. I assumed it did not work so I ran make, with this result

pi@raspberrypi:~/raspiraw $ ./buildme
pi@raspberrypi:~/raspiraw $ make
gcc -I/opt/vc/include -pipe -W -Wall -Wextra -g -O0 -c -o raspiraw.o raspiraw.c
raspiraw.c: In function ‘main’:
raspiraw.c:2231:1: warning: label ‘port_disable’ defined but not used [-Wunused-label]
port_disable:
^~~~~~~~~~~~
gcc -I/opt/vc/include -pipe -W -Wall -Wextra -g -O0 -c -o RaspiCLI.o RaspiCLI.c
gcc -o raspiraw raspiraw.o RaspiCLI.o -L/opt/vc/lib -lrt -lbcm_host -lvcos -lmmal_core -lmmal_util -lmmal_vc_client -lvcsm

On second thought, perhaps it did work and just said nothing, I should have checked.

[CanPi]

Building your dcraw results in this warning:

Code: Select all

pi@raspberrypi:~ $ git clone https://github.com/6by9/dcraw.git
Cloning into 'dcraw'...
remote: Enumerating objects: 17, done.
remote: Total 17 (delta 0), reused 0 (delta 0), pack-reused 17
Unpacking objects: 100% (17/17), done.
pi@raspberrypi:~ $ cd dcraw
pi@raspberrypi:~/dcraw $ ./buildme
/usr/bin/ld: warning: libjpeg.so.62, needed by /usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/libjasper.so, may conflict with libjpeg.so.8

Anything to be concerned about?

[CanPi]

Ok, I think I was able to set up i2c correctly, following this very ]helpful post by nsimon1 https://github.com/6by9/raspiraw/issues/7

My objective for now is to get a single full resolution 12-bit HQ raw image out of raspiraw. The following command results in a failure to allocate memory.

Code: Select all

pi@raspberrypi:~/raspiraw $ ./raspiraw -hd -g 1023 -eus 1000000 -o /home/pi/Pictures/out.%03d.raw[B
Using i2C device /dev/i2c-0
RaspiRaw: Probing sensor ov5647 on addr 36
RaspiRaw: Probing sensor imx219 on addr 10
RaspiRaw: Probing sensor adv7282 on addr 21
RaspiRaw: Probing sensor imx477 on addr 1A
RaspiRaw: Found sensor imx477 at address 1A
RaspiRaw: Setting exposure to 41666 from time 1000000us
RaspiRaw: Set exposure 0202 to A2
RaspiRaw: Set exposure 0203 to C2
RaspiRaw: Set vts 0340 to A2
RaspiRaw: Set vts 0341 to C2
RaspiRaw: Set gain 0204 to 03
RaspiRaw: Set gain 0205 to FF
RaspiRaw: Encoding 32315270
No AWB
mmal: Set pack to 0, unpack to 0
mmal: Timing 6/2, 2/6/0, 0/0
mmal: Create pool of 6 buffers of size 18580480
usrvcsm: [vcsm_malloc_cache]: [1283] [mmal_vc_port buffer]: ioctl mem-alloc FAILED [-1] (hdl: 0)
usrvcsm: [vcsm_vc_hdl_from_hdl]: [1283]: invalid device or handle!
usrvcsm: [vcsm_lock]: [1283]: invalid device or invalid handle!
mmal: main: could not allocate 18580480 bytes of shared memory (handle 0)
mmal: Create pool of 6 buffers of size 18580480
mmal: Now streaming...

Any ideas of what the issue might be? I don't understand C code well enough (though I can see that the IMX477 is shown to be RGGB while elsewhere it is shown as BGGR. And Gain is capped at 10 bits while elsewhere it is shown at 12+).

Also, what does the Timing output refer to and why does it need to create a pool of 6 buffers? Shouldn't one suffice for now?

[6by9]

6 * 18580480 bytes is 111482880bytes, or 106MB. Did you increase gpu_mem to something to match?

rawcam will only release the buffer when a new one has been returned to put the next buffer in. It also fills pairs of buffers - one for the embedded metadata, and one for the image data.

Feel free to rewrite the app to fit your needs, but you will need a fair amount of knowledge over how sensors and CSI2.

[CanPi]

6 * 18580480 bytes is 111482880bytes, or 106MB. Did you increase gpu_mem to something to match?

rawcam will only release the buffer when a new one has been returned to put the next buffer in. It also fills pairs of buffers - one for the embedded metadata, and one for the image data.

I thought I saw that the 3A+ set aside 128MB for that but I will check tomorrow. Why 6, if all is asked of raspiraw is 1? That seems rather wasteful.

Feel free to rewrite the app to fit your needs, but you will need a fair amount of knowledge over how sensors and CSI2.

I am not fluent in C but I can possibly give it a stab if you can point me to the documentation that explains how to set up the sensor for completely unprocessed raw stills at the lowest level. Just the basics, no need to disturb NDAs.

What I need is a minimalist piece of code that puts manual exposure, totally unprocessed, full resolution 12-bit raw data into 16 bit files, as fast as possible, 10+ fps. Not video, stills. A light weight hot rod.

[6by9]

6 * 18580480 bytes is 111482880bytes, or 106MB. Did you increase gpu_mem to something to match?

rawcam will only release the buffer when a new one has been returned to put the next buffer in. It also fills pairs of buffers - one for the embedded metadata, and one for the image data.

I thought I saw that the 3A+ set aside 128MB for that but I will check tomorrow. Why 6, if all is asked of raspiraw is 1? That seems rather wasteful.

Where did you tell raspiraw that you wanted one frame? There isn't such an option.
I've already explained why it asks for 6 buffers.

Feel free to rewrite the app to fit your needs, but you will need a fair amount of knowledge over how sensors and CSI2.

I am not fluent in C but I can possibly give it a stab if you can point me to the documentation that explains how to set up the sensor for completely unprocessed raw stills at the lowest level. Just the basics, no need to disturb NDAs.

What I need is a minimalist piece of code that puts manual exposure, totally unprocessed, full resolution 12-bit raw data into 16 bit files, as fast as possible, 10+ fps. Not video, stills. A light weight hot rod.

There is no difference between stills and video when dealing with the raw Bayer data.

raspiraw already does all of the above for you.

10fps, 12MPix, unpacked to 16bpp is 240Mbytes/s. You'll have to think hard about your storage media to deal with that much data for more than about a second. SD cards won't keep up (25Mbyte/s bus speed), and USB2 on a 3A won't either (max 480Mbit/s including overheads). USB3 storage on a Pi4 has a chance (5Gbit/s, or 625Mbit/s including overheads).

https://picamera.readthedocs.io/en/late ... -operation gives a good intro as to how imaging stacks work.

[CanPi]

Ok thanks, to be honest I had not understood that your reply was an explanation for the large amount of memory required. Now that I do perhaps you can clarify: release buffer when other is filled = 2x; fills pairs of buffers for metadata = 4x. Where does 6x come from?
And what is all the metadata for? Where is it? If we wanted just one frame, would 2x the memory be enough?

Anyways, increasing gpu_mem from 128MB to an arbitrary 180 did it, it now works with this simple command

Code: Select all

~/raspiraw/raspiraw -t 100 -g 1010 -eus 1000 -o /home/pi/Pictures/out.%03d.raw

As for the documentation the linked page is a start but it is too generic, too much info in certain respects and not deep enough for raspiraw purposes. Questions:

Why can't I use a -t lower than 100ms with that command line?
What set up would I need for the fastest 10 capture burst at full-resolution, 12-bit?

'preciate the help.

[CanPi]

FYI the minimum gpu_mem in config.txt that works with the HQ camera on a 3A+ is 140

[CanPi]

Code: Select all

pi@raspberrypi:~/raspiraw $ ~/raspiraw/raspiraw -eus 2000000 -o /home/pi/Pictures/longdarkg_0_s_2.raw
Using i2C device /dev/i2c-0
RaspiRaw: Probing sensor ov5647 on addr 36
RaspiRaw: Probing sensor imx219 on addr 10
RaspiRaw: Probing sensor adv7282 on addr 21
RaspiRaw: Probing sensor imx477 on addr 1A
RaspiRaw: Found sensor imx477 at address 1A
RaspiRaw: Setting exposure to 83333 from time 2000000us
RaspiRaw: Invalid exposure:83333, exposure range is 0 to 65535!

RaspiRaw: Invalid exposure:83333, vts range is 0 to 65535!

[CanPi]

~/raspiraw/raspiraw -t 100 -g 1010 -eus 1000 -o /home/pi/Pictures/out.%03d.raw

Why can't a -t lower than 100ms be used with that command line?
What command line/changes would be needed for the fastest X capture burst at full-resolution 12-bit, with X less than 10?

I would still be interested in an answer to those questions, if anyone could spare the time.

Thx

[CanPi]

After much trial and error this is how I was able to get raspiraw to work on a 3A+ with the HQ camera. First sudo apt update, sudo apt full-upgrade and sudo rpi-update (this last one may not be necessary in the future but it is recommended for now). Then:

1) sudo raspi-config
2) turn on Camera, I2C and SPI in Interfacing Options
3) sudo nano /boot/config.txt
4) change: gpu_mem=140
5) add at bottom: dtparam=i2c_vc=on
6) ctrl-x, y, enter
7) sudo nano ~/.bashrc
8) add at bottom: PATH=~/raspiraw:~/raspiraw/tools:$PATH
9) ctrl-x, y, enter
10) sudo reboot
11) git clone https://github.com/6by9/raspiraw.git
12) cd raspiraw
13) ./buildme (it says nothing and returns to command line if everything went well)
14) ./camera_i2c
15) modprobe i2c-dev
16) ./camera_i2c (14-15-16 in this sequence works for me, otherwise it does not find the camera)
17) capture a 1s raw image: ~/raspiraw/raspiraw -eus 1000000 -o /home/pi/Pictures/long_g0_s_1.raw

Hope it helps others.

[HermannSW]

12) modprobe 12c-dev
13) ./camera_i2c (11-12-13 in this sequence works for me, otherwise it does not find the camera)

That are instructions if you run 5.4 kernel only (eg. after an rpi-update).

This is on my Pi4B with standard Raspberry Pi OS (32bit):

Code: Select all

🍓 uname -a
Linux raspberrypi4B 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux
🍓 ls -l /dev/i2c-*
crw-rw---- 1 root i2c 89, 0 Jun  7 16:03 /dev/i2c-0
crw-rw---- 1 root i2c 89, 1 Jun  7 16:03 /dev/i2c-1
🍓 

[CanPi]

God point Hermann, I have edited my post accordingly.

Any suggestions for the earlier questions?

[HermannSW]

Any suggestions for the earlier questions?

I doubt that you can go below 100ms because the maximal framerate for default mode and mode3 (12MP) is 10fps, from my tools measurements it is 11fps, therefore for sure you cannot go below 90ms. You need to use one of the other modes to capture with up to 50fps allowing for 20ms, or to mode4 with 120fps (better 80fps to avoid frameskips). 1s/80 would allow for 12.5ms:
https://www.raspberrypi.org/documentati ... /camera.md

[had]

Hello,

I use dcraw on a raw image taken with raspiraw.
I want to use the dcraw option +M which takes into account an embedded color matrix .
Do you know how to embed a color matrix inside the raw file ?

[CanPi]

Take a look at 6x9's fork of dcraw.c:

https://github.com/6by9/dcraw/blob/master/dcraw.c

Starting around line 6570 you will see a long list of matrices for every camera supported by the code. They are shown multiplied by 10000 written row-wise as 16 bit integers. Keep in mind that each of these matrices is what DNG calls a 'reverse' Color Matrix, meaning that it takes triplets from XYZ to Camera Neutral space (this is quite different from the matrices in libcamera or raspistill, for instance, that instead take Camera Neutral data directly to sRGB). For more info on how to generate dcraw matrices have a read of this pdf:

https://rcsumner.net/raw_guide/RAWguide.pdf

It would be interesting to know what matrix 6x9 uses in the fork, since I don't see any matrices for the HQ camera in the list (RP_testc is its nickname - although RP_imx477 would be more appropriate, but I digress).

[6by9]

It would be interesting to know what matrix 6x9 uses in the fork, since I don't see any matrices for the HQ camera in the list (RP_testc is its nickname - although RP_imx477 would be more appropriate, but I digress).

Already been fixed in the firmware - it's now imx477 rather than testc.

[CanPi]

Good work, thanks. How do you deal with the matrix in dcraw?

[therealdavidp]

If anyone wants to know the colour matrices that we use, at least in the libcamera (rather than the proprietary firmware) based stack, you can find them in the camera tunings that we ship with libcamera. Clone the libcamera tree (git://linuxtv.org/libcamera.git) and look for the folder libcamera/src/ipa/raspberrypi/data. There's a JSON file for each supported sensor, search for "rpi.ccm" and you'll find a 3x3 matrix for a variety of different colour temperatures.

[6by9]

IIRC dcraw has a calibration mode where you need to take a capture of a Macbeth chart ideally at noon on a sunny day (davidp would tell you the colour temperature of that).

From the dcraw FAQ

Why does dcraw output have a green tint and weak color?
Because dcraw doesn't have a color matrix for your camera model, it outputs raw color instead of sRGB. To fix this, I need a photo of a Wolf Faust, ColorChecker, CMP, or other calibrated color chart. Follow this checklist:

Use a real chart, not a printout or screen image.
Wait for sunny weather, local noon ± two hours.
Carefully brush any dust off the chart.
Tilt the chart 90° to the camera and 45° to the sun to avoid specular reflections.
Set the camera two meters away and use telephoto zoom.
Use the lowest ISO setting.

So those are the conditions required, although he doesn't detail how to then calibrate.
Looking at the code, you then have to program in the co-ordinates of each patch into the array cut of dcraw.c (function colorcheck around line 3455), and define COLORCHECK. Run dcraw with -v and it should print out the ccm that it wants to use.

I haven't worried about the actual CCM in use as I mainly want to check that the image looks vaguely right for driver development, not produce perfect images.

[CanPi]

If anyone wants to know the colour matrices that we use, at least in the libcamera (rather than the proprietary firmware) based stack, you can find them in the camera tunings that we ship with libcamera. Clone the libcamera tree (git://linuxtv.org/libcamera.git) and look for the folder libcamera/src/ipa/raspberrypi/data. There's a JSON file for each supported sensor, search for "rpi.ccm" and you'll find a 3x3 matrix for a variety of different colour temperatures.

Thanks David. Any reason why values don't move monotonically, sometimes dramatically so, from one extreme of the cct range to the other? For instance look at how the very first value of the matrices varies with cct.

If because of the type of illuminant (e.g. D50 sunlight vs LED vs fluorescent) is there a way to know what cct goes with which?

[therealdavidp]

The CCM measurements are calculated directly from a set of calibration images. Indeed they do move about but generally we go with whatever the fitting procedure gives us. Anyone interested can find out all about the procedure here https://www.raspberrypi.org/documentati ... ra_1p0.pdf (see chapter 6).

[CanPi]

Thanks for that, I have moved the discussion to the libcamera thread