who can still make it even faster?

Pan/zoom references:

bertl mentioned that the bayer order should not be affected by different crops

initial work done by @_BAndiT1983_ but an issue remains where the thread is not really killed on stopping

https://medium.com/swlh/python-how-to-measure-thread-execution-time-in-multithreaded-application-f4b2e2112091

Unless there are actual usecases for a VPN something simpler like a pure terminal sharing solution seems better for support purposes to me.

Is this the page to discuss this project or is it being discussed on the mailing list as well. For some reason when I try to access the Archives of the mailing list I cannot access them. Also, my understanding of the project based on last GSOC is that the Packet layer is mostly done, it is the layers below that have to be optimized?

Maybe Co-Simulation with the gateware simulated in cxxrtl / verilator with qemu would be an interesting approach here

Experimental gateware provided but behaviour requires some debugging with logic analyser.

In T734#17428, @BAndiT1983 wrote:

@eppisai Was trying to answer your questions on IRC, but you weren't online. There is little reason to place a cartesian plane in the painter, as the purposes are different, it's more or less about "single responsibility". It would be better to create a base class for the graph widgets, e.g. BaseGraph, and then derive different graphs from it.

@eppisai Was trying to answer your questions on IRC, but you weren't online. There is little reason to place a cartesian plane in the painter, as the purposes are different, it's more or less about "single responsibility". It would be better to create a base class for the graph widgets, e.g. BaseGraph, and then derive different graphs from it.

Issue has been identified and a fix is available, now the next task is how to detect and fix the behaviour with the right hardware version in the upstream version: https://github.com/apertus-open-source-cinema/axiom-firmware/issues/179

I have tested the commands and they work for me. So I'm closing this task.

@sebastian I have edited the page for this task, please have a look.

Sergio tested the new Firmware 2.0 with this file
https://github.com/apertus-open-source-cinema/axiom-firmware/blob/master/software/scripts/pic_jtag_pcie.py#L20
modified to
base = 0x10
and reports the HDMI works OK!

many thanks @alex !

please elaborate on the "colored" monochrome output mode, not clear for me yet.

new firmware has been built, testing if the fix is working there as well is still to be done.

Ohh sorry my bad, Didn't considered 2nd condition.
Thank you for the explanation.

What output do you get?

hey Sebastian,
I am not getting desired output by running 2nd command. Is there some typo ?
Because on switching the last two images in the sequence. i.e -swap 1,2 gives correct output.

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

Perfect, tested and verified! Thanks!
Will update wiki now.

This should avoid the sample point setting:

Works, many thanks!

Thanks Bertl for the direction.