#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

se6ast1an: could you create a collection of different raw frames from the beta somewhere

best would be one image per scene as the compression scheme does not do inter frame compression

good night everyone :)

se6ast1an: but where are the RAW files? seeing only MP4, MOV and DNG

but we have more :)

ah, now i see, thanks

hi eppisai!

I added a comment to https://lab.apertus.org/T1202 and would like to talk to you if you could take over that task as it also evolves around your checkbox icon

great, please take a look

if anything is unclear let me know then we can discuss it

hi eppisai, please also check the task https://lab.apertus.org/T1193 before that, as the icon needs slight adjustment

hi

good day!

hi all

just as a reference re earlier: I collected interesting frames here: inverse_multi_stage_wavelet2d(transformed, 3)

whoops wrong clipboard

EmilJ: the software side is the linux kernel

we load kernel modules with devicetree overlays

the overlay generation is - eh - a bit ad hoc ;)

for the overlays to work you need some things

thanks, I'll try to replicate that

well the pynq has its own machinery, I'll see what I can do

happy Monday...

maybe that is easier to get started with

camera body etc...

thanks, ill check it out...

hmmm, can't figure out what framebuffer *driver* does axiom-firmware use

but I don't get `/dev/fb0`

EmilJ: how is your devicetree looking?

Bertl: that was a good idea, apparently it is refusing to create the overlay. The error I'm getting (create_overlay: Failed to create overlay (err=-22)) typically is due to problems with devicetree symbols

I'm in neither of those situations though

EmilJ: you need to compile your devicetree with the '-@' option to get symbols

I did that

well, the overlay, at least, but I verified the `__symbols__` directory exists in the device tree directory

ahh

I used the emitted overlay

do you have the source for your devicetree available?

it's not super transparent since xilinx assumes you're using their tools and abstracting everything, probably

I do have that

hmm

Welp, that didn't boot

well what did you do?

gnome-disks

you probably need to use a proper u-boot and a proper devicetree

(fsbl.elf is not needed anymore, bitstream.bit is not needed aswell)

the ps7_init_gpl.c thing can be extracted from vivado if you create a fsbl project targeting your board

MEETING TIM!

* bluez is here

e

great, metal_dent[m] would you like to start the reporting?

last week i worked on the image button PR (haven't pushed the changes yet)

today i was going through the code and learning more about FBO and shaders

other work was related to the USB code but i haven't tested that yet so waiting for the remote to come ':D

great metal_dent[m], many thanks

yes, sure

yep!

https://github.com/Swaraj1998/axi-lite-slave

i used the axi verification ip for verification using simple reads and writes

would be nice to have the full project with the verification IP as well

(online I mean :)

i just did the verification today.. will add the tcl part on the repo so it can be reproduced

thats all from me i guess!

many thanks bluez!

Thank you :) I bought a MicroZed board, and tried I tried serial communication from my Linux laptop, and read this link (https://wiki.apertus.org/index.php/AXIOM_Beta/Enclosures) up to around "5."

I will do my best to catch up.

Thank you! I will read it carefully : )

vup2: your turn!

nice!

(in the python implementation)

now we are starting to experiment with different quantization parameters for the different wavelet parts to find a sweet spot of image size and image quality

what is the issue with image size vs speed vs quality ?

so the compression works by throwing away some bits of the high frequency components of the image

but obviously lowers the image quality

yup it doesnt

that does affect the runtime obviously

would an FPGA implementation be able to work with arbitraray resolutions or would that make it hard to parallelize the process?

the paralelization is not a big problem there

(currently there is no paralelization in the fpga implementation)

so we can set an upper bound during synthesis and then support everythnig that is lower than that

great, that should do, as the image sensor max resolution is "static" but reading smaller windows would increase FPS

yup

are the next steps already the step onto the FPGA?

the next step would probably be to find good parameters for the quantization and good codebooks for rle and huffman

tables used for the huffman compression

right

yes

should we seek to collect more or are the ones on the server sufficient?

great

but if there is anything you definitely dont want to compress badly, send it now ;)

yep

dont have a beta currently with me but will keep it in mind

(we were using a image that had lower optical resolution that the image resolution and it showed :)

sure

with acompanying quality "ratio"

the nextpcb order has advanced a few steps further

we had to upgrade the copper thickness as they quote the thcikness not per layer but per top and bottom layers combined

today we received again "production files" for verification

maybe just a mix up with another project...

https://wiki.apertus.org/index.php/AXIOM_Beta/Manual#WiFi_Access_Point_Setup

I started diving into the AXIOM Remote code again

explaining the terms and classes better

and BAndiT1983 merged the visualizer adjustments upstream

yay!

two chinese companies have agreed to ship free samples if we cover shipping

samples will tell if they are of useable quality

and $0.39$/dm³

shipping still needs to be calculated of course

next steps now that Tele is back from vacation are to prepare anything left before we can start the assembly run

discussion who buys which components from the bom, etc.

I guess thats it from my side

thanks!

very intense!

so nothing really to report from my side this week

next steps are to get the SATA plugin working so we can do some tests there

great!

anything else for todays meeting, or does anyone else have topics or things to discuss/share?

eppisai fixed the checkbox icon on the remote just today for example: https://lab.apertus.org/T1193

lets see what 2021 will bring for the project

since it seems like the pynq setup is a pain to extract information from, since it's all linked together with petalinux/yocto config files, I'm delving deeper into the devicetree overlay I'm trying to load. There isn't really a good reason for it not to work

the overlays need to match the device tree labels

compiling without symbols and adding it stops the dmesg error from appearing

> Using the non-phandle based target method allows one to use a base DT which does not contain a __symbols__ node

I arrived at the conclusion that simplefb is outright not shipped with the pynq image

hmm that repo is something else

https://gitlab.com/-/snippets/2056747

off for now ... bbl

EmilJ: hmm yeah, the simplefb module seems to be disabled

I think `make M=drivers/video/fbdev/simplefb` should work

I guess I'll find what Makefile builds it

it builds the .o but doesn't link it into .ko, that's frustrating