Current Server Time: 18:46 (Central Europe)

#apertus IRC Channel Logs

2019/06/08

Timezone: UTC


02:30
RexOrCine
New AXIOM Beta and AXIOM Shell exploded - https://wiki.apertus.org/images/d/d3/00-ABExp-001_AXIOM_Beta_in_AXIOM_Shell_Exploded_V5.jpg
03:03
Bertl_oO
oh my ... we should have been more careful I guess? :)
03:26
dev_
joined the channel
03:30
dev_
BAndiT1983|away, When we call the SetRedChannel again, it should assign pointer to next red channel
03:31
dev_
which is not doing , as i am fixing the OCImage, and the _redData is no longer contain nullptr
03:32
dev_
so it keeps pointing the first one every time we call it
03:32
dev_
I think , that is the problem
03:34
dev_
left the channel
03:36
aombk
joined the channel
03:45
Bertl_oO
off to bed now ... have a good one everyone!
03:45
Bertl_oO
changed nick to: Bertl_zZ
03:48
RexOrCine
changed nick to: RexOrCine|away
04:44
aombk
left the channel
04:53
dev_
joined the channel
04:58
dev_
why are you debayering in MLV loader and again in presenter? : In MLV loader, The code only extract red, green and blue channel using downscaler (line 226, 228) , there is no debayering . while in processingtest::show , the frames are getting debayered using algorithms like bilinear, SHOODAK etc
05:00
dev_
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
05:35
dev_
left the channel
05:35
dev_
joined the channel
05:41
dev_
left the channel
06:44
aombk
joined the channel
07:36
dev_
joined the channel
07:43
dev_
left the channel
07:49
niemand
joined the channel
07:50
dev_
joined the channel
07:56
dev_
left the channel
08:21
BAndiT1983|away
changed nick to: BAndiT1983
08:23
BAndiT1983
dev_, sorry, but you don't understand the principles of the application and the code
08:23
BAndiT1983
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
08:24
BAndiT1983
this is a serious lack of knowledge which rises my doubts that you can complete the gsoc task at all
08:50
Y_G
joined the channel
09:32
Y_G
left the channel
09:43
Nira|away
changed nick to: Nira
10:15
se6astian|away
changed nick to: se6astian
11:11
BAndiT1983
changed nick to: BAndiT1983|away
11:41
Nira
changed nick to: Nira|away
11:43
BAndiT1983|away
changed nick to: BAndiT1983
11:59
Bertl_zZ
changed nick to: Bertl
11:59
Bertl
morning folks!
12:40
Y_G
joined the channel
12:55
BAndiT1983
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
12:55
BAndiT1983
can assist you there, as it was done at the beginning of the development also
12:55
BAndiT1983
if you want, then i can try to restore the old test page and give you the sources
13:00
Y_G
Hi BAndiT1983 ,I have done some web-dev ,so it should not be difficult to set up the page ,will need to go through the current state
13:01
Y_G
What priority is the WebUI currently?
13:02
BAndiT1983
it has to be restored, like gulp tasks reviewed and actual state, but i would suggest that you create just a simple test page for daemon communication through WSServer for now
13:02
BAndiT1983
so prio 1 is daemon and it'S comms
13:02
BAndiT1983
prio 2 is web page comms
13:03
BAndiT1983
we had several attempts for web UI, like plain JS, vue.js, current one uses riot.js
13:04
BAndiT1983
it has to settle down at some point, as this constant changes are just creating a lot of gaps, because it's hard to continue when you have to learn new framework every time
13:05
Bertl
I've heard there is a nice web framework for rust ... :)
13:08
BAndiT1983
yes, let's grab another technology and start all over
13:09
Y_G
hmm, allow me some time (around 2) weeks for Daemon and it's communication and then we can create the plan for WebUI maybe ?
13:10
BAndiT1983
Y_G, sounds good, we should also arrange a meeting with Bertl and se6astian to check on priorities of functionality in scripts, as the GDocs file contains some which cannot be implemented right now, as FPGA gateware is not done yet
13:10
BAndiT1983
Bertl, the problem is not a framework, but how to pack everything in web UI so it's self-contained
13:11
Bertl
no worries, it was a joke ...
13:12
Y_G
Yes that meeting would be really helpful
13:12
Bertl
(not rust or rocket/iron)
13:13
Bertl
from my side, everything after noon (not necessarily afternoon) is fine
13:13
Bertl
i.e. check with se6astian when he can make some time and you should be good
13:13
BAndiT1983
Bertl, i know, but many people are taking it seriously
13:16
Bertl
obviously not seriously enough when I read your discussions with dev ...
13:21
BAndiT1983
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
13:25
BAndiT1983
Bertl, have you checked the beta at the hub, before the install? seems like the firmware has quite some problems
13:28
BAndiT1983
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
13:40
BAndiT1983
here was downscaler already explained -> http://irc.apertus.org/index.php?day=02&month=06&year=2019
13:43
Bertl
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
13:45
Bertl
so, please coordinate and check with rex/seb when somebody is at the hub if a new image needs to be written to the SD card, otherwise remote updates should be possible as well
13:47
Bertl
(most likely only a few scripts need updating there)
13:47
BAndiT1983
ok, will do, as i lack an overview of things at the hub ;) it's a bit far away
13:48
BAndiT1983
have already got some improvements from Y_G for it and will try them later
13:49
Y_G
left the channel
16:03
BAndiT1983
off for a moment, will be back later
16:03
BAndiT1983
changed nick to: BAndiT1983|away
18:04
supraraj
joined the channel
18:07
BAndiT1983|away
changed nick to: BAndiT1983
18:17
Nira|away
changed nick to: Nira
18:25
BAndiT1983
changed nick to: BAndiT1983|away
18:30
supraraj
left the channel
19:30
Fares
joined the channel
19:30
Fares
Hi
19:36
Bertl
hey
19:38
Fares
Hi Bertl, how are you?
19:39
Bertl
fine, thanks! and you?
19:40
Fares
I'm fine too thank you
19:40
Fares
I have pushed last changes on github now
19:40
Bertl
great! tx!
19:40
Fares
I spent last week testing the core and fixing some bugs
19:40
Fares
I also did several tests on the fpga
19:41
Bertl
sounds good
19:41
Fares
and it does work correctly so far
19:42
Bertl
even better! :)
19:42
Fares
it is on github named "integration_3" and I packaged it with axi stream interfaces
19:42
Bertl
okay
19:44
Fares
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
19:45
Fares
I synthesized the core at 50..*
19:45
Fares
I was thinking to synthesize the whole core*
19:45
Fares
sorry for the mistakes
19:46
Bertl
no problem
19:46
Fares
so for now the design is to accept 4 pixel every second, with 100MHZ that is 100 million pixels at max, which is enough to do 4096 * 3072, so every piece of logic in the pipeline is repeated four times, and in the last part it work with big buffer
19:47
Fares
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?
19:48
Bertl
yup, so if you can crank it up to 200MHz, it's roughly half the resources
19:48
Fares
4 pixel every cycle**
19:48
Fares
400 million pixels** sorry
19:49
Fares
enough to do 4096 * 3072 at 30 fps
19:49
Bertl
yeah, if we can do more, even better
19:50
Fares
more MHZ?
19:50
Bertl
so it makes sense (to some extend) to see where the limitations are
19:53
Fares
so generally I should try to maximize the clk speed in the design? to what extend?
19:55
Bertl
well, both the clock rate and the parallelism have significant implications on the usability
19:55
Bertl
i.e. if we can get higher clock rate while reducing the parallel units, we have less resource usage (not necessarily less power consumption)
19:56
Bertl
when we have enough resources, it might also make sense to use higher clock rates (maybe not that high) to make it work with higher frame rates
20:01
Fares
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?
20:02
Bertl
the priority is probably to integrate it in the existing codebase (for both Beta and Micro)
20:02
Bertl
then I'd say you want to tune it and get an idea what can be done regarding clock rate
20:03
Bertl
and what resources a 'single' instance actually requires
20:03
Bertl
and of course, how that scales when you have 2 or 4 (or maybe even more)
20:05
Fares
integrating it with the existing codebase will put constraints on the clock rate correct? you mean by single instance, one pixel/cycle?
20:07
BAndiT1983|away
changed nick to: BAndiT1983
20:09
Bertl
well, the clock is rather flexible in the current design
20:10
Bertl
don't forget, you are basically reding from DDR and writing to either an external FPGA or DDR memory again
20:10
Bertl
in both cases the clock can be somewhere between 50-300MHz
20:13
Fares
okay
20:13
Fares
I think I would need to refactor the code to easily generate 1/2/4/.. in parallelism, tune the design, then during the integration we can pick the suited one
20:14
Bertl
why not
20:19
Fares
okay :) so the code is now on Github if you want to check it. Later, I will push the code I used to test it on the fpga. then I will start refactor the code and write last module to detect and fix 0xFF bytes
20:19
Bertl
sounds good!
20:21
Fares
well okay, thank you for your time!
20:21
Bertl
thanks for the update!
20:25
Fares
left the channel
21:06
Nira
changed nick to: Nira|away
22:28
se6astian
changed nick to: se6astian|away
22:38
BAndiT1983
changed nick to: BAndiT1983|away
22:50
niemand
left the channel