Current Server Time: 17:01 (Central Europe)

#apertus IRC Channel Logs

2019/06/24

Timezone: UTC


05:10
BAndiT1983|away
changed nick to: BAndiT1983
05:25
BAndiT1983
changed nick to: BAndiT1983|away
05:38
Bertl_oO
off to bed now ... have a good one everyone!
05:38
Bertl_oO
changed nick to: Bertl_zZ
05:55
LordVan
joined the channel
06:11
alexML
joined the channel
06:15
comradekingu
left the channel
06:15
alexML_
left the channel
06:18
aPinky
left the channel
06:19
Topic
apertus° - open source cinema | www.apertus.org | join the apertus° Lab: http://lab.apertus.org/ | IRC Logs available at: http://irc.apertus.org
06:19
se6astian
has set the topic
06:22
se6astian|away
changed nick to: se6astian
06:32
se6astian
changed nick to: se6astian|away
07:12
sebix
joined the channel
07:29
se6astian|away
changed nick to: se6astian
07:56
se6astian
changed nick to: se6astian|away
07:57
se6astian|away
changed nick to: se6astian
07:57
se6astian
left the channel
07:58
se6astian|away
joined the channel
07:58
se6astian|away
changed nick to: se6astian
07:58
se6astian
left the channel
07:58
philippej
left the channel
07:58
RexOrCine|away
left the channel
07:58
Nira|away
left the channel
07:58
BAndiT1983|away
left the channel
08:45
vup
left the channel
08:46
vup
joined the channel
09:45
se6astian|away
joined the channel
09:45
se6astian|away
changed nick to: se6astian
09:45
BAndiT1983|away
joined the channel
09:45
philippej|away
joined the channel
09:45
BAndiT1983|away
changed nick to: BAndiT1983
09:45
philippej|away
changed nick to: philippej
09:45
Nira|away
joined the channel
09:45
RexOrCine|away
joined the channel
12:17
Y_G
joined the channel
12:21
siddhantsahu
left the channel
12:41
tjstyle
left the channel
12:51
RexOrCine|away
changed nick to: RexOrCine
14:10
Bertl_zZ
changed nick to: Bertl
14:10
Bertl
morning folks!
14:11
apurvanandan[m]
Good morning Bertl
14:54
sebix
left the channel
15:51
Fares
joined the channel
15:51
Nira|away
changed nick to: Nira
16:00
se6astian
meeting time
16:00
se6astian
hello everyone!
16:01
se6astian
please again message me now if you want to report
16:01
apurvanandan[m]
HI
16:04
dev__
joined the channel
16:06
se6astian
please fares go ahead
16:06
Fares
Hi everyone!
16:06
Fares
I worked earlier this week on a different encoding approach trying to optimize the core but it turned out to be worse.
16:07
Fares
so I continued in the development of the core, completed the 0xFF fixer module and optimized two modules, then I put everything together and tested it on fpga.
16:08
Bertl
sounds good
16:09
Fares
I did several basic testing with several images, and it worked correctly but timing and efficiency is still something to work on.
16:11
se6astian
very nice!
16:11
Fares
that would be all, and I would like to get samples of a noisy images out of the sensor please
16:12
Bertl
there are some .raw12 (and maybe even .raw16) images available
16:12
Fares
I found this, https://files.apertus.org/AXIOM-Beta/snapshots/BetaRawTests/2.2.2016-PropsRawSnaps/
16:14
Fares
does the sensor provide noisy pictures more than props01 image in this folder?
16:14
se6astian
there are tons of pictures here
16:14
se6astian
https://files.apertus.org/AXIOM-Beta/snapshots/
16:14
se6astian
but its hard to say which ones are the most noisy...
16:17
se6astian
if you look at https://files.apertus.org/AXIOM-Beta/snapshots/greyframes/
16:17
se6astian
there are gainx4 raw12 files
16:17
se6astian
higher gain -> higher noise
16:18
Fares
great! I will test them out, the idea is that the noiser the image the bigger its size, that mean it will take more time to compress and go through usb, so the worst case frame will determine the maximum fps
16:19
se6astian
great
16:20
anuejn
what will you do, if a image compresses worse than that empirically determined "maximum"
16:20
anuejn
eg. what part of the data will be dropped?
16:20
anuejn
will the compression be lossy or will frames be dropped?
16:22
Fares
the compression is not lossy but the frame will take more time to be processed and take more time to go through the usb so a future frame may be dropped, a safety margin will be needed
16:25
anuejn
hm... is there any "easy" way to make the compression lossy in that case
16:26
Bertl
not sure we want that ...
16:26
anuejn
not sure either, we want to just drop frames...
16:26
Bertl
but we definitely want some upper limit on the frame size
16:28
se6astian
lets discuss the details afterwards if that is ok for you?
16:28
Fares
the compression depends on the pixels is close in values to each others, to make it lossy we will smooth some pixels before compression
16:29
Fares
sure I will be here to discuss it further
16:29
Fares
pixels are*
16:29
apurvanandan[m]
Can I start?
16:30
se6astian
anything else fares or can apurvanandan[m] start?
16:30
Fares
That would be all se6astian, thank you!
16:31
se6astian
great, thank
16:31
apurvanandan[m]
Hi everybody :)
16:32
apurvanandan[m]
So here is the code that I wrote this week: https://github.com/apurvanandan1997/usb-plug-mod/tree/master/Virtex_5
16:33
apurvanandan[m]
So this week I completed major part of Zynq side of gearwork ie the BER testing model for the USB 3.0 module
16:33
apurvanandan[m]
I will be using my Virtex-5 FPGA at first and will later shift to Zynq-7020
16:35
apurvanandan[m]
I am successfully being able to setup 6 LVDS lanes between the USB module and Virtex-5 FPGA, and tested them by sending a 6-bit word to the HOST PC through the USB module :)
16:35
apurvanandan[m]
*sending 6 bit words
16:37
apurvanandan[m]
Also I formatted and cleaned up the code along with MAKEFILEs for the evaluation. Currently I am ahead of timeline :).
16:37
apurvanandan[m]
I have already started working on MachXO2 side of gearwork, finding the right primitives, and techinques for capturing the DDR stream correctly
16:38
apurvanandan[m]
After that I will implement the ECC and CRC.
16:38
apurvanandan[m]
This is all from my side.
16:39
se6astian
great, many thanks!
16:39
apurvanandan[m]
Any remarks?
16:39
Bertl
was any BER testing done so far?
16:41
apurvanandan[m]
No, because the gearwork is complete on side only, But it will be done in this week. PRNG FIbonnaci are being currently in this with 8b/10b and OSERDES at 400 serial clock.
16:41
apurvanandan[m]
*500MHz
16:42
apurvanandan[m]
on Zynq side only
16:43
Bertl
I see ...
16:43
se6astian
dev__: you are next up please
16:43
dev__
left the channel
16:44
dev__
joined the channel
16:44
dev__
sorry Bad Internet
16:44
dev__
Hello Everyone
16:45
dev__
This week, I have added static allocators for playback and they are working fine MLV files.
16:45
dev__
I tried to cover cases like random access (random requests of frames using frame number) which will be the case while seeking. --> https://github.com/kakashi-Of-Saringan/opencine/commits/dev
16:45
dev__
16:45
dev__
This week,I will be working to bring sliders into playback and also discuss and work on video clip class.
16:46
dev__
that's it
16:46
se6astian
thanks!
16:46
se6astian
BAndiT1983: any comments/questions?
16:47
se6astian
otherwise Y_G please go ahead
16:48
Y_G
Hi all,
16:48
dev__
i have updated every thing on trello, so he check
16:48
dev__
can*
16:49
Y_G
This week I worked on and tested the I2CAdapter both with and without the SMBus commands dependency.
16:49
Y_G
Time was also spent on researching which one is better . Could'nt find anything significant to discard either approach.
16:49
Y_G
Tested the current `set register` and `get register` methods . There might be some problems with set method which I'll discuss with BAndiT1983.
16:50
Y_G
Implementation of "gamma_conf.sh" in daemon was delayed this week due to the reworking of I2CAdapter.Will try to make up for it this week
16:50
Y_G
I also went through the Image sensor parameters which would be implemented in this week .
16:50
Y_G
Thanks ,That would be all from my side.
16:52
se6astian
thanks!
16:53
Bertl
so I2C register values can now be retrieved and set via daemon?
16:53
Y_G
yes they can be
16:54
Bertl
would be nice to see some of the I2C related scripts adapted to this
16:55
Y_G
https://github.com/kiquance21/axiom-control-daemon/blob/master/Modules/I2CTestModule.cpp equivalent of pac1720info.sh
16:56
Bertl
well, that certainly wouldn't work too well in a script :)
16:57
se6astian
maybe you can discuss the requirements for that after the meeting in detail?
16:58
BAndiT1983
GetPac1720Info() could have a loop to avoid manual +=
16:58
se6astian
otherwise aSobhy would be up next
16:58
Bertl
sure
16:59
Y_G
@BAndiT1983 Yes, but again the response is too big , So it would be better to not have this at all.
17:00
BAndiT1983
Y_G, this is another side of the story
17:02
Y_G
yup ,will see what can be done about it.
17:02
se6astian
aSobhy: please go ahead
17:02
Bertl
Y_G: for me the main question is: how to do a 'i2c1_set 0x38 0x01' from a shell or python script via the daemon, but as I said, fine to discuss that later
17:03
aSobhy
Hi everyone
17:03
aSobhy
that week I changed some modules for the link training,
17:03
aSobhy
I choosed the hardest way to generate the seed of PRNG after Bertl told me the easy way
17:03
aSobhy
tested(simulation) some module to ensure they correctness
17:03
aSobhy
here what I have done https://github.com/aabdosobhy/Bi-Direction-packet-protocol
17:03
aSobhy
I'm writing the documment of the code I've written
17:05
aSobhy
and I stucked in the desrilizer at the MachXO2 for a long time I used a seriliazer OSERDESE2 with SDR mode as my design and didn't find a primitive to receive it
17:06
aSobhy
I manged to finish link training by the next 2 days as It take a long time :/
17:06
aSobhy
the OSERDESE2 at the ZYNQ side
17:07
Bertl
http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/IK/ImplementingHigh-SpeedInterfaceswithMachXO2Devices.ashx?document_id=39084
17:09
aSobhy
okay I should ask earlier
17:10
Bertl
if I remember correctly, I linked this document even before the project started
17:11
Bertl
ah yes, it is even part of the 'useful links' section of the qualification task :)
17:11
Bertl
https://lab.apertus.org/T731
17:11
dev__
left the channel
17:11
dev__
joined the channel
17:12
Bertl
ah, not qualification but task description
17:13
se6astian
felix_: wanted to also report about photonsdi development
17:13
se6astian
so again aSobhy & Bertl may I ask you to discuss the details after the reports?
17:13
aSobhy
after opening the document yes you linked it before
17:13
Bertl
sure
17:13
aSobhy
ok
17:14
felix_
hi! i've written the video frame timing generator for photonsdi (that thing was way more convoluted than i expected) and fixed quite a few bugs when doing some build tests of the modules i had already written. no tests on real hardware and no a/b tests in simulation yet though
17:15
Bertl
so we still don't know if the hardware is working or not, yes?
17:16
felix_
yeah
17:18
dev__
left the channel
17:18
se6astian
thanks for the update felix_ - I hope you can continue to work on this now
17:18
se6astian
Nira: you wanted to share a bit as well
17:19
dev__
joined the channel
17:23
Nira
hello everyone, this week I have solved the problems which I had last week and finished my first little coding on PIC16
17:23
Nira
https://github.com/niratubertc/PIC16_blink
17:24
se6astian
Great!
17:25
Nira
I should improve the explanation, but you can have a first look
17:25
Bertl
yes, please explain the process to program the PIC16s on the Remote
17:29
Nira
I use pic32prog for uploading icsp_ser.hex on the PIC32, for being able to program PIC16
17:30
Nira
and then we use ser_icsp6_prog_e for uploading the wanted code (remote_e_b.hex) on the PIC16
17:31
Nira
(KME on this case)
17:31
Bertl
k, tx
17:33
se6astian
no big updates from my side this time, we went over to the equipmentcafe today - its not actually a cafe, its a equipment rental facility for cinema gear
17:33
se6astian
and tested the axiom beta compact enclosure
17:33
se6astian
with lenses and base plates
17:33
se6astian
https://twitter.com/AXIOM_Community/status/1143175236407500802
17:34
se6astian
Bertl: do you want to provide the closing words as usual
17:34
se6astian
todays meeting already stretched a bit the 60 minutes we normally try to stay under
17:34
Bertl
nah, we can skip the closing words and dive into individual discussions :)
17:34
Bertl
not much happened on my side this week, except for more rework
17:37
se6astian
right!
17:37
se6astian
official meeting concluded
17:38
se6astian
please discuss the task details and next steps
17:40
Bertl
please make sure that we all have links to your current code/status (best add them to the lab)
17:41
Bertl
also make sure that you are available during the evaluation period
17:41
Y_G
@Bertl : "how to do a 'i2c1_set 0x38 0x01' from a shell or python script via the daemon" , if this functionality is required this can be added to DaemonCLI .
17:42
Bertl
well, I'd say it is the main functionality we are looking for, i.e. a way to modify all the scripts to use the daemon
17:45
dev__
left the channel
17:47
Y_G
Hmm, we may do this with a command like "./DaemonCLI i2c_module set i2c1_reg 0x38 0x01 b"
17:48
BAndiT1983
this is too much on parameters
17:49
BAndiT1983
better add separate i2c modules, like i2c1_module or so, although you can also omit _module
17:52
Y_G
We atleast require 3 parameters(chipAddress ,dataAddress ,value {for set}) even if we have different modules like i2c*module
17:53
BAndiT1983
do we need to control it from command line?
17:53
BAndiT1983
or can we give addresses meaningful names?
17:53
BAndiT1983
also chip address can be replaced by module, or not?
17:54
Bertl
feel free to add all kind of aliases, simplifications, etc but make sure that the generic, low level access always works
17:54
aSobhy
Bertl: I'm on the document now any advice?!
17:55
Bertl
BAndiT1983: this way if somebody wants to change a bit in a register, they don't have to modify and rebuild the daemon :)
17:55
Y_G
busAddress can be replaced with different modules. the command works like this `i2cset busAdd chipAdd dataAdd value`
17:55
BAndiT1983
ok, then we should think of extending parameter number
17:56
Bertl
aSobhy: there is no SERDES in the MachXO2s, but there is quite some capable DDR mechanism
17:56
BAndiT1983
but we need proper evaluation of it, as it should also be crash-safe
17:56
Bertl
note that a read=modify-write operation might be nice to have though
17:57
Bertl
(but of course can be done on the shell/script level as well)
18:00
aSobhy
It is not necessary to change the ZYNQ side to DDR but the clk freq. on the MachXO2 will be 1/2 the freq of ZYNQ, right?
18:01
Bertl
depends on your setup on the MachXO2 side
18:01
Bertl
you can get up to 8:1 gearing on the MachXO2
18:01
Bertl
just requires careful design and use of the PLL
18:02
aSobhy
can that happened not use the same design on both side
18:02
Bertl
you won't be able to use the same design, as there are different mechanisms for serialization and deserialization on both FPGAs
18:03
aSobhy
okay
18:03
aSobhy
I'm working on it now
18:08
dev__
joined the channel
18:10
dev__
Good Evening BAndiT1983 , I have tried to make the code clean and also using log/logger.h to see the logs of playback on terminal.
18:12
dev__
please check it !
18:12
Fares
@Bertl, regarding compression variability, in my tests I noticed that timing change with the image complexity and compressed size, with the few examples I tried, it changed from 64ms to 67.8ms @100mhz for 4096*3072 image with compression size from 56% to 67%
18:12
dev__
I wanted to confirm that , Can I go for adding sliders to playback.
18:13
BAndiT1983
hi dev__
18:13
Bertl
Fares: yes, it is expected to see different compression sizes
18:13
Bertl
the main question here is how to address them
18:13
BAndiT1983
dev__, will check it when i have some time, but not today, as i had pretty long day at work and a lot of coding was done
18:13
BAndiT1983
if you feel that playback is stable then try to add sliders, but it has to be done in proper way, with focus on MVP
18:14
Bertl
Fares: the simplest option is to have fixed frame slots and just pad smaller frames to the maximum
18:14
Bertl
then have some special marker for frames which are cropped because too large
18:15
dev__
Okay , till then , I will try make a action plan for how to do it ? and read about MVP and other things
18:16
BAndiT1983
i though that i gave you quite a number of MVP links months ago
18:16
BAndiT1983
*thought
18:16
dev__
yes ,
18:17
dev__
i remember
18:18
dev__
I will update u with the approach soon
18:18
BAndiT1983
if you need an example then take a look at OCBackup and how data and events are passed around, event bus, signals etc.
18:18
BAndiT1983
ok, looking forward to it
18:19
dev__
Nice , That would be helpful
18:19
dev__
Thanks
18:21
Fares
@bertl: that assume 100% utilization of usb3.0 bandwidth correct? I think that is not doable, since if compressed image is small, we are still bounded by the inputted pixels/clk so there will be gaps in the output stream, for example if two pixels/clk, the minimum time to input all pixels to the core @100MHZ for 4096*3072 is 31.45728ms
18:22
Nira
changed nick to: Nira|away
18:23
dev__
left the channel
18:24
Fares
but as you said the simplest option will be to set a safe margin to the maximum fps - it will to be higher than uncompressed -, and enjoy only low bandwidth
18:25
Bertl
no there is no point in planning (size wise) for the worst case
18:26
Bertl
but after some evaluation, we can, for example, settle on 75% of the uncompressed size per frame
18:27
Bertl
and just make sure that frames which cross that amount can be identified
18:28
Fares
yes sure, absolute worst case is terrible, but the question is, will it be practical in the future to add a mechanism to identify and store the dropped frames in sd-card / transfer via ethernet?
18:30
Bertl
the sky is the limit, but you always end up with a 'worst case' which cannot be handled unless you have the full raw bandwidth or allow for lossy compression
18:33
Fares
yes that's true :)
18:57
BAndiT1983
changed nick to: BAndiT1983|away
18:57
BAndiT1983|away
changed nick to: BAndiT1983
18:58
anuejn
how difficult is it to apply lossy compression?
18:58
alexML
hi Fares
18:59
Fares
Hi alex
19:00
alexML
in ML, we solved the variable frame size by allocating fixed-size frames at first (85% of uncompressed size iirc), and resizing them on the fly in order to fill all the available memory
19:00
Fares
annuejn: LJ92 is not designed to be lossy, although it can be done if we smooth the pixel values first
19:00
alexML
a bit complicated, but seemed to work; we can probably reuse the approach here
19:00
Bertl
alexML: except that we do not have 'memory' to fill
19:01
Fares
The output stream is transferred to usb module then to the reciever
19:01
anuejn
ah tx, just read the wikipedia article
19:02
Bertl
it would be an option if the encoder is placed in the input pipeline and the data is already compressed when it hits the DDR memory
19:03
se6astian
changed nick to: se6astian|away
19:05
alexML
btw, that 85% we settled for, was enough for "typical" cases, but there are still users who managed to exceed this limit (with highly detailed scenes at high ISO)
19:06
alexML
(and, 56% to 67% are typical numbers for us, too)
19:08
Fares
that is for 14bits, correct?
19:08
alexML
yes
19:10
alexML
or close to 50% for a bit depth that matches the sensor noise
19:11
alexML
http://theory.uchicago.edu/~ejm/pix/20d/tests/noise/noise-p3.html - fig. 18
19:12
aombk2
left the channel
19:12
alexML
if the bit depth is too low, you get posterization; if the bit depth is too high, it no longer makes a big difference
19:12
alexML
for matching the bit depth with the "gradient 3-bit tonality" from that figure, I've got compressed ratios close to 50%
19:13
alexML
(that was at 11 bits at ISO 100 on 5D Mark III's sensor)
19:17
Fares
I read your article about about "optimal lut" and it really show difference, specially if you can tune the huffman tree used for encoding to give shorter codes for small differences, I think it can do more than 50%
19:17
Fares
but how can this be applied to the beta?
19:18
Fares
I mean practically, for every gain we should use different bit depth?
19:20
Y_G
left the channel
19:22
alexML
hm, I'm not even sure there is a good reason to use the higher gain settings on the CMV sensor...
19:23
Bertl
how about: shorter exposure time in low light situations?
19:24
alexML
yes, but the benefit was pretty small iirc
19:24
Bertl
compared to what?
19:26
alexML
the higher gain didn't result in much cleaner shadows, compared to the lower gain, iirc (need to look up the numbers)
19:27
Bertl
so you are saying that a 2x vs 1x analog gain doesn't provide any advantage over a digital gain of 2x, yes?
19:28
alexML
my old measurements show 13.6e at gain 1, 11.02 at gain 2, 10.7 at gain 3 and 10.15 at gain 4
19:29
alexML
so, if you change the gain from 1 to 4, you get 0.4 stops of less noise in shadows, at the expense of 2 stops of highlights
19:30
alexML
from 1 to 2, you get 0.3 stops in shadows at the expense of 1 stop in highlights
19:30
Bertl
well, that might be right, but if you can run at 60FPS instead of 15FPS it might be beneficial, no?
19:31
alexML
?!
19:32
Bertl
well, if there isn't enough light for a gain 1x to fill the 12bits
19:32
Bertl
or do you suggest just to shift in two zero bits?
19:34
alexML
between gain 1 and 2, the difference may be noticeable, but between 2 and 4... not so much
19:35
Bertl
I'm pretty sure you'll notice a missing bit :)
19:36
alexML
of course, but that bit will have mostly random noise :)
19:36
Bertl
note that even if the noise floor is above the lsb, it is better to fill this bit with noise
19:36
alexML
yes
19:36
alexML
anyway, the original question was whether it's worth the trouble of optimizing the LJ92 encoder for the higher gains, right?
19:37
Bertl
also, did you evaluate the 'gigabytes of data' we collected with the different sensor frontend configurations?
19:37
alexML
or whether it's enough to focus on the lower one(s)
19:37
Bertl
because I'm pretty sure we can still improve on the noise side
19:41
alexML
I think I've uploaded some numbers to the FTP server, back then, just can't remember where
19:42
alexML
(DRAM refresh cycle neded)
19:42
alexML
afk a bit
19:42
Bertl
k, cya
19:43
BAndiT1983
changed nick to: BAndiT1983|away
19:43
BAndiT1983|away
changed nick to: BAndiT1983
19:43
Fares
yes, the idea is to optimize it as possible with the noisy images that the end user may generate
19:46
Fares
Bertl: I have question regarding overclocking and timing analysis, I do timing analysis on vivado with zynq7010-1 part on synthesized desing, is that similar to the beta configuration?
19:47
Fares
Also after implementing it with low clk, I overclock it and observe no problem, is that reliable in fpga or should/must be avoided in production?
19:48
RexOrCine
changed nick to: RexOrCine|away
19:49
Bertl
the MicroZed (and thus the Beta) uses a Zynq 7020 1C grade, so yes, that is similar
19:50
Bertl
@overclocking: not sure how your do that, but it is likely the wrong approach
19:51
Bertl
if you want to verify a design for two clock speeds, you need to add proper timing constraints (for both speeds), then place and route it sucessfully
19:52
Bertl
this will guarantee that the design can work at both speeds under 'normal' circumstances
19:59
Fares
okay good notes! I will be involved more with timing analysis in the future when working with hp_reader&writer since xilinx dma is limited
19:59
illwieckz
left the channel
19:59
Bertl
okay, let me know if you need any information there or help with testing, etc
20:00
Fares
okay, thank you!
20:01
illwieckz
joined the channel
20:05
Bertl
np
20:09
se6astian|away
changed nick to: se6astian
20:51
BAndiT1983
changed nick to: BAndiT1983|away
20:52
Fares
left the channel
21:44
se6astian
off to bed, good night
21:44
se6astian
changed nick to: se6astian|away
21:48
Bertl
nn
22:43
aombk
joined the channel