Current Server Time: 20:19 (Central Europe)

#apertus IRC Channel Logs

2019/06/08

Timezone: UTC


01: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
02:03
Bertl_oO
oh my ... we should have been more careful I guess? :)
02:26
dev_
joined the channel
02:30
dev_
BAndiT1983|away, When we call the SetRedChannel again, it should assign pointer to next red channel
02:31
dev_
which is not doing , as i am fixing the OCImage, and the _redData is no longer contain nullptr
02:32
dev_
so it keeps pointing the first one every time we call it
02:32
dev_
I think , that is the problem
02:34
dev_
left the channel
02:36
aombk
joined the channel
02:45
Bertl_oO
off to bed now ... have a good one everyone!
02:45
Bertl_oO
changed nick to: Bertl_zZ
02:48
RexOrCine
changed nick to: RexOrCine|away
03:44
aombk
left the channel
03:53
dev_
joined the channel
03: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
04: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
04:35
dev_
left the channel
04:35
dev_
joined the channel
04:41
dev_
left the channel
05:44
aombk
joined the channel
06:36
dev_
joined the channel
06:43
dev_
left the channel
06:49
niemand
joined the channel
06:50
dev_
joined the channel
06:56
dev_
left the channel
07:21
BAndiT1983|away
changed nick to: BAndiT1983
07:23
BAndiT1983
dev_, sorry, but you don't understand the principles of the application and the code
07: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
07:24
BAndiT1983
this is a serious lack of knowledge which rises my doubts that you can complete the gsoc task at all
07:50
Y_G
joined the channel
08:32
Y_G
left the channel
08:43
Nira|away
changed nick to: Nira
09:15
se6astian|away
changed nick to: se6astian
10:11
BAndiT1983
changed nick to: BAndiT1983|away
10:41
Nira
changed nick to: Nira|away
10:43
BAndiT1983|away
changed nick to: BAndiT1983
10:59
Bertl_zZ
changed nick to: Bertl
10:59
Bertl
morning folks!
11:40
Y_G
joined the channel
11: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
11:55
BAndiT1983
can assist you there, as it was done at the beginning of the development also
11:55
BAndiT1983
if you want, then i can try to restore the old test page and give you the sources
12: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
12:01
Y_G
What priority is the WebUI currently?
12: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
12:02
BAndiT1983
so prio 1 is daemon and it'S comms
12:02
BAndiT1983
prio 2 is web page comms
12:03
BAndiT1983
we had several attempts for web UI, like plain JS, vue.js, current one uses riot.js
12: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
12:05
Bertl
I've heard there is a nice web framework for rust ... :)
12:08
BAndiT1983
yes, let's grab another technology and start all over
12: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 ?
12: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
12:10
BAndiT1983
Bertl, the problem is not a framework, but how to pack everything in web UI so it's self-contained
12:11
Bertl
no worries, it was a joke ...
12:12
Y_G
Yes that meeting would be really helpful
12:12
Bertl
(not rust or rocket/iron)
12:13
Bertl
from my side, everything after noon (not necessarily afternoon) is fine
12:13
Bertl
i.e. check with se6astian when he can make some time and you should be good
12:13
BAndiT1983
Bertl, i know, but many people are taking it seriously
12:16
Bertl
obviously not seriously enough when I read your discussions with dev ...
12: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
12:25
BAndiT1983
Bertl, have you checked the beta at the hub, before the install? seems like the firmware has quite some problems
12: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
12:40
BAndiT1983
here was downscaler already explained -> http://irc.apertus.org/index.php?day=02&month=06&year=2019
12: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
12: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
12:47
Bertl
(most likely only a few scripts need updating there)
12:47
BAndiT1983
ok, will do, as i lack an overview of things at the hub ;) it's a bit far away
12:48
BAndiT1983
have already got some improvements from Y_G for it and will try them later
12:49
Y_G
left the channel
15:03
BAndiT1983
off for a moment, will be back later
15:03
BAndiT1983
changed nick to: BAndiT1983|away
17:04
supraraj
joined the channel
17:07
BAndiT1983|away
changed nick to: BAndiT1983
17:17
Nira|away
changed nick to: Nira
17:25
BAndiT1983
changed nick to: BAndiT1983|away
17:30
supraraj
left the channel
18:30
Fares
joined the channel
18:30
Fares
Hi
18:36
Bertl
hey
18:38
Fares
Hi Bertl, how are you?
18:39
Bertl
fine, thanks! and you?
18:40
Fares
I'm fine too thank you
18:40
Fares
I have pushed last changes on github now
18:40
Bertl
great! tx!
18:40
Fares
I spent last week testing the core and fixing some bugs
18:40
Fares
I also did several tests on the fpga
18:41
Bertl
sounds good
18:41
Fares
and it does work correctly so far
18:42
Bertl
even better! :)
18:42
Fares
it is on github named "integration_3" and I packaged it with axi stream interfaces
18:42
Bertl
okay
18: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
18:45
Fares
I synthesized the core at 50..*
18:45
Fares
I was thinking to synthesize the whole core*
18:45
Fares
sorry for the mistakes
18:46
Bertl
no problem
18: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
18: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?
18:48
Bertl
yup, so if you can crank it up to 200MHz, it's roughly half the resources
18:48
Fares
4 pixel every cycle**
18:48
Fares
400 million pixels** sorry
18:49
Fares
enough to do 4096 * 3072 at 30 fps
18:49
Bertl
yeah, if we can do more, even better
18:50
Fares
more MHZ?
18:50
Bertl
so it makes sense (to some extend) to see where the limitations are
18:53
Fares
so generally I should try to maximize the clk speed in the design? to what extend?
18:55
Bertl
well, both the clock rate and the parallelism have significant implications on the usability
18: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)
18: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
19: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?
19:02
Bertl
the priority is probably to integrate it in the existing codebase (for both Beta and Micro)
19:02
Bertl
then I'd say you want to tune it and get an idea what can be done regarding clock rate
19:03
Bertl
and what resources a 'single' instance actually requires
19:03
Bertl
and of course, how that scales when you have 2 or 4 (or maybe even more)
19:05
Fares
integrating it with the existing codebase will put constraints on the clock rate correct? you mean by single instance, one pixel/cycle?
19:07
BAndiT1983|away
changed nick to: BAndiT1983
19:09
Bertl
well, the clock is rather flexible in the current design
19:10
Bertl
don't forget, you are basically reding from DDR and writing to either an external FPGA or DDR memory again
19:10
Bertl
in both cases the clock can be somewhere between 50-300MHz
19:13
Fares
okay
19: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
19:14
Bertl
why not
19: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
19:19
Bertl
sounds good!
19:21
Fares
well okay, thank you for your time!
19:21
Bertl
thanks for the update!
19:25
Fares
left the channel
20:06
Nira
changed nick to: Nira|away
21:28
se6astian
changed nick to: se6astian|away
21:38
BAndiT1983
changed nick to: BAndiT1983|away
21:50
niemand
left the channel