#apertus IRC Channel Logs

oh my ... we should have been more careful I guess? :)

BAndiT1983|away, When we call the SetRedChannel again, it should assign pointer to next red channel

so it keeps pointing the first one every time we call it

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

the extracted red,green, blue channel in loader, is stored in buffer present in allocator (_mem) while in processingtest , I am trying to access those channels by setting them again in ocimage object and debayer it with chosen algorithm

downscaler is the alternative to debayering, to avoid the need to interpolate, it grabs only known pixels, but debayering interpolates unknown ones in each channel

morning folks!

hi Y_G, as the current state of WebUI is rather unknown, as Francis is absent for quite some time, you could circumvent the problem by implementing a really simple HTML page and send requests to WSServer

if you want, then i can try to restore the old test page and give you the sources

What priority is the WebUI currently?

so prio 1 is daemon and it'S comms

we had several attempts for web UI, like plain JS, vue.js, current one uses riot.js

I've heard there is a nice web framework for rust ... :)

hmm, allow me some time (around 2) weeks for Daemon and it's communication and then we can create the plan for WebUI maybe ?

Bertl, the problem is not a framework, but how to pack everything in web UI so it's self-contained

Yes that meeting would be really helpful

from my side, everything after noon (not necessarily afternoon) is fine

Bertl, i know, but many people are taking it seriously

gsoc should be seen as preparation for later work life, so it's important to invest enough time to learn the basics and then move to advanced stuff

but the setup which was done last year is great, especially when i can look at the webcam and check if lights are on, and the cherry on the cake is the HDMI live feed from the cam

as I wrote two weeks ago (and repeated a week ago or so), the remote Beta has the (back then) latest image from vup (for testing) and problems with the image (I also reported problems with the startup) should be checked with vup

(most likely only a few scripts need updating there)

have already got some improvements from Y_G for it and will try them later

off for a moment, will be back later

Hi

Hi Bertl, how are you?

I'm fine too thank you

great! tx!

I also did several tests on the fpga

and it does work correctly so far

it is on github named "integration_3" and I packaged it with axi stream interfaces

I synthesized the 50,100,142,200MHZ, it failed with 200MHZ, but I overclocked the 142MHZ design and it work but I know that is not a reliable thing. so regarding our last conversation to run some parts with higher clock speeds, I was synthesize the whole core with 200MHZ, It will consume only half of the resources

I was thinking to synthesize the whole core*

no problem

if the core run at 200MHZ, I will only need to work with two pixels per cycle which mean half the logic and smaller buffer, is that a good thing to pursue?

4 pixel every cycle**

enough to do 4096 * 3072 at 30 fps

more MHZ?

so generally I should try to maximize the clk speed in the design? to what extend?

i.e. if we can get higher clock rate while reducing the parallel units, we have less resource usage (not necessarily less power consumption)

okay, the parallelism is relatively easy to do, not sure about higher clock rate. so what is the priority now if we can do both?

then I'd say you want to tune it and get an idea what can be done regarding clock rate

and of course, how that scales when you have 2 or 4 (or maybe even more)

don't forget, you are basically reding from DDR and writing to either an external FPGA or DDR memory again

okay

why not

sounds good!

thanks for the update!