Pavel Machek
Posts
1993Following
95Followers
183
Pavel Machek
pavel
@MOOMANiBE Ok, let's say that was an "interesting" hardware. And they probably had 'unlimited' ROM, so... yep, nice trick, but not even too crazy.
0
0
1
Pavel Machek
pavel
@mkyral Na radaru vidim vodu na zapadni hranici a vic vody v nemecku. Horko bych si v tuto chvili neodvazil predpovidat. Teplomer zatim ukazuje nejakych 23C, coz odpovida datum z intenetu (21C).
pavel@duo:/data/l/k$ weather lkpr
Current conditions at Praha / Ruzyne, Czech Republic (LKPR) 50-06N 014-15E 365M
Last updated Jul 03, 2025 - 03:30 AM EDT / 2025.07.03 0730 UTC
Temperature: 77 F (25 C)
Relative Humidity: 47%
Wind: from the N (360 degrees) at 12 MPH (10 KT)
Muj odhad je ze dneska nebude tak silene vedro -- diky te vode.
pavel@duo:/data/l/k$ weather lkpr
Current conditions at Praha / Ruzyne, Czech Republic (LKPR) 50-06N 014-15E 365M
Last updated Jul 03, 2025 - 03:30 AM EDT / 2025.07.03 0730 UTC
Temperature: 77 F (25 C)
Relative Humidity: 47%
Wind: from the N (360 degrees) at 12 MPH (10 KT)
Muj odhad je ze dneska nebude tak silene vedro -- diky te vode.
1
0
0
Pavel Machek
pavel
@datenwolf I believe I'm limited to OpenGL ES 2.0. Presumably hardware can do more but our current drivers can not, so we are stuck there.
On the other hand... #librem5 main sensor can not do 10bpp at the moment, due to missing drivers. So maybe we can focus on 8bpp, first. Probably ineffecient conversion is "good enough" too, as GPU is a bit overpowered for this job.
On the other hand... #librem5 main sensor can not do 10bpp at the moment, due to missing drivers. So maybe we can focus on 8bpp, first. Probably ineffecient conversion is "good enough" too, as GPU is a bit overpowered for this job.
2
0
0
Pavel Machek
pavel
@datenwolf So linearization should be doable with functions, too. Small trouble is that it is sensor-dependent but ... we have enough mathematical tools to deal with that. Actual functions can be seen here: https://blog.brixit.nl/fixing-the-megapixels-sensor-linearization/
0
0
0
Pavel Machek
pavel
Yep, recent bwtest shows that (extremely simple) debayer is feasible, and possibly more. So far I integrated debayer-gpu + gstreamer, and I'm meeting the deadlines.
0
0
0
Pavel Machek
pavel
I, once again, believe that GPU on Librem 5 can be useful for debayering. #librem5 #linuxphone https://gitlab.com/tui/debayer-gpu/-/tree/master/bwtest?ref_type=heads
0
0
1
Pavel Machek
pavel
@dos It seems that ignoring half of green pixels is right thing to do at the moment: https://gitlab.com/tui/debayer-gpu/-/tree/master/bwtest?ref_type=heads "Normal" debayer is 40% too slow. (That's better than 5 times too slow, but still not good enough). If you can can get it to 24 loops in second, you'll become a hero :-).
1
0
0
Pavel Machek
pavel
@robertfoss I know about that one, see gitlab.com:tui/debayer-gpu.git . I could not get that to anywhere near the required performance.
0
0
0
Pavel Machek
pavel
@dos As for copies... Yes, I'm currently doing more copies than needed. I measured Librem 5 at about 2GB/sec memory bandwidth, and stream is about 30MB/sec. At 1Mpix/24fps resolution, gstreamer should be able to encode it in real time.
Here's huge problem with v4l, which gives uncached memory buffers to userspace. That means one whole CPU core is dedicated to copying that to "normal" memory. If that is ever solved, yes, other optimalizations are possible. Currently, this means it is not even possible to copy anything bigger than 1Mpix out of the v4l.
Here's huge problem with v4l, which gives uncached memory buffers to userspace. That means one whole CPU core is dedicated to copying that to "normal" memory. If that is ever solved, yes, other optimalizations are possible. Currently, this means it is not even possible to copy anything bigger than 1Mpix out of the v4l.
1
0
0
Pavel Machek
pavel
@datenwolf This is probably easiest to use (after pngtopnm): https://gitlab.com/tui/debayer-gpu/-/blob/master/test.png?ref_type=heads .
0
0
0
Pavel Machek
pavel
@datenwolf Sorry. Example frame is here: https://gitlab.com/tui/debayer-gpu/-/blob/master/test.png?ref_type=heads (You probably want to run pngtopnm it, so that your code only works with uncompressed data).
Alternatively, I started file format for this. https://gitlab.com/tui/tui/-/tree/master/4cc?ref_type=heads dirgen.sh can generate example frames using gstreamer. You get raw data after 128 bytes header.
Alternatively, I started file format for this. https://gitlab.com/tui/tui/-/tree/master/4cc?ref_type=heads dirgen.sh can generate example frames using gstreamer. You get raw data after 128 bytes header.
0
0
0
Pavel Machek
pavel
@datenwolf Example of frame is here: https://gitlab.com/tui/tui/-/blob/master/ucam/bayer2rgb.rs?ref_type=heads (I also have frame generator and real frames captured from libobscura).
Anything that works on Librem 5 is fine, bonus points if I can understand it. Robot generated code using -lEGL -lGLESv2 -lm ... and that builds and does something. Librem 5 reports:
Vendor: etnaviv
Renderer: Vivante GC7000 rev 6214
OpenGL Version: OpenGL ES 2.0 Mesa 21.2.6
GLSL Version: OpenGL ES GLSL ES 1.0.16
Anything that works on Librem 5 is fine, bonus points if I can understand it. Robot generated code using -lEGL -lGLESv2 -lm ... and that builds and does something. Librem 5 reports:
Vendor: etnaviv
Renderer: Vivante GC7000 rev 6214
OpenGL Version: OpenGL ES 2.0 Mesa 21.2.6
GLSL Version: OpenGL ES GLSL ES 1.0.16
2
0
0
Pavel Machek
pavel
@dos @tizilogic I know. And I have "the rest" prototyped here: https://gitlab.com/tui/debayer-gpu/-/blob/master/isp.frg?ref_type=heads But I feel I need fast-enough naive debayering first, so that I can improve that.
0
0
0
Pavel Machek
pavel
@tizilogic @dos I tried simd, https://gitlab.com/tui/tui/-/blob/master/ucam/bayer2rgb.rs?ref_type=heads , it did not have good enough performance. (I could not do 512x384 at 23fps).
GL versions are:
Vendor: etnaviv
Renderer: Vivante GC7000 rev 6214
OpenGL Version: OpenGL ES 2.0 Mesa 21.2.6
GLSL Version: OpenGL ES GLSL ES 1.0.16
Doing input in u8, with output in u8 and internal computation in u16 fixed point should be "good enough". Doing everything in u16 would be even better. Floats are okay, too.
GL versions are:
Vendor: etnaviv
Renderer: Vivante GC7000 rev 6214
OpenGL Version: OpenGL ES 2.0 Mesa 21.2.6
GLSL Version: OpenGL ES GLSL ES 1.0.16
Doing input in u8, with output in u8 and internal computation in u16 fixed point should be "good enough". Doing everything in u16 would be even better. Floats are okay, too.
0
0
0