Woohoo, #libobscura returned an image from the #librem5 !

```
Buffer size: 823296, seq: 0, timestamp: 18178.362439 [s]
Writing to frame.GRBG
```

Now I'm scared to look at the data. It's probably garbage.

But the proof of concept is there: you can treat the Media Controller API as a database and query it for valid image pipeline configurations.

I wonder if the debayering #shader still works.

But first, clean up and publish.

#images #camera #linuxmobile #linux #rust

@dcz First, cleanup and publish. Second, ping me so I can reproduce that :-).

@pavel Published and described!

https://codeberg.org/libobscura/libobscura#devices

Cleaned... not so much :P

I'm still going to bump version numbers, run CI and publish crates, but it's already useable.

Also I'm not proud of how messy some parts are...

@dcz Thanks. I got it do build. AFAICT this should fix the docs:

+++ b/README.md
@@ -77,7 +77,7 @@ cargo run --bin demp
The **Librem 5** has support for collecting frames (demo not adapted yet):

```
-LIBOBSCURA_DEVICES_DIR=crates/vidi/config/ cargo run --bin camera_getframes -- 'imx7-csi:imx-media:776794edba9cf34e:s5k3l6xx 3-002d'
+LIBOBSCURA_DEVICES_DIR=crates/vidi/config/ cargo run --bin obscura_getframes -- 'imx7-csi:imx-media:776794edba9cf34e:s5k3l6xx 3-002d'
```

Aspirations

I did this to get it to build:

apt install curl, remove rustc.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

default host triple: aarch64-unknown-linux-gnu
default toolchain: beta
profile: default
modify PATH variable: yes

. "$HOME/.cargo/env"

sudo apt install librust-clang-sys+libloading-dev libgbm-dev

@dcz I'm not exactly sure how, but I now got frame.GRBG. I believe that's good :-).

@pavel We're on the same page now :D
Thanks for the bug report.

@dcz Thank you! Another thing I noticed is typo in filename: "video_fotmats.rs". I could not get "cargo run --bin raw -- --raw foo.sv GRBG delme.tif" to work. Thanks again!

@pavel cargo run --bin raw -- --raw width_px,height_px,bpp foo.sv GRBG delme.tif

you missed the params to --raw. Any idea how to make that clearer?

Also maybe I should print the used resolution somewhere.

@dcz Sorry, I misquoted the command line. To be sure I retried, this time

cargo run --bin raw -- --raw 1052,780,8 data/51345663907.1052x780-GRBG.sv GRBG delme.tif

and am getting

thread 'main' panicked at crates/conv/src/bin/raw.rs:62:7:
called `Result::unwrap()` on an `Err` value: GenericError(MappingFailed { reason: "Permission denied (os error 13)", source: Os { code: 13, kind: PermissionDenied, message: "Permission denied" } })

. Same error over ssh and from phosh.

@dcz Controls do not seem to work for me. cargo run --bin vidi_controls results in

[crates/vidi-examples/src/bin/vidi_controls.rs:22:5] camera.get_id() = "imx7-csi:imx-media:d0e30f0703ab04c0:hi846 2-0020"

thread 'main' panicked at crates/vidi-examples/src/bin/vidi_controls.rs:25:48:
called `Result::unwrap()` on an `Err` value: Os { code: 25, kind: Uncategorized, message: "Inappropriate ioctl for device" }

I'd like to play with AE, and I guess I need them for that.

@pavel

sudo usermod -a -G render purism

that should take care of this problem. Also, the new master is more informative about where it came from if you use RUST_LOG=debug

It still fails on mapping the memory :/ I hope I don't have to bisect that.

@pavel Well, I'm bisecting now :P

@pavel Bisected, fixed. Please update.

The bayer conversion test returns even worse garbage than last time so I'll have to investigate but at least it runs.

@pavel Okay, it had always returned this garbage. Moving on to controls.

@dcz I got it running, thanks. I did not look at the output, but it takes 1.2 seconds on Librem5. Simple on-cpu solution is faster than that :-(.

@pavel If you measured a single frame, then that's epected with all the GPU initialization. I'd wager it will get amortized if you process several frames in a row.

@dcz Okay, so ... I did some rather crazy hacks, and my python scripting can now do live preview (at 1fps) and am close to taking photos. Would there be interest in that?

@dcz But the code in raw.rs can only do single frame ATM, so that is not easy to test...?

@pavel Totally! Please post on the repo.

That 1 fps is worrying though.

@pavel Yeah, raw.rs is more of a verification tool than an example.
The live demos show how to process multiple frames but they are also complicated with drawing.

vidi_loop_frames and vidi_shared_buffers.

I guess I need a shader loop example.

@dcz So my plans are:

Modify obscura_getframe:

1) add GRW trailer specifying format

2) create files as .tmp, only moving them to .grw when hey are complete

3) capture continously

More details and how to get ucam working are on https://gitlab.com/tui/tui/-/tree/master/ucam?ref_type=heads .

Any comments? :-)

@pavel I guess continuous capturing is unavoidable unless you're fine with a 2-3 frames delay.

> Rumors say it is bandwidth limit somewhere

Nope, I just decided not to make it too hard for myself and use the simplest format. Then more important things came up. The other camera streams 10 bit, so definitely possible and desired.

I'll try to get bayer working this weekend but then I'm out for the funding finale for a few days.