Current Server Time: 14:08 (Central Europe)

#apertus IRC Channel Logs

2016/05/21

Timezone: UTC


02:08
jucar
joined the channel
03:33
jucar
left the channel
03:33
jucar
joined the channel
03:37
John-K
left the channel
03:44
John-K
joined the channel
03:50
John-K
left the channel
03:53
John-K
joined the channel
03:57
John-K
left the channel
03:58
John-K
joined the channel
04:23
jucar
left the channel
07:37
fredy
left the channel
07:40
fredy
joined the channel
09:01
John-K
hey Bertl_zZ can you ping me when you're around?
09:16
Bertl_zZ
changed nick to: Bertl
09:16
Bertl
morning folks!
09:16
Bertl
John-K: ping
09:18
John-K
hey Bertl, I was wondering if you could help me understand the image format and pixel ordering of the data that comes into cmv_snap3
09:18
John-K
it appears to at least have the even and odd rows swapped
09:19
Bertl
into, i.e. the data the input pipeline bursts into memory
09:19
John-K
ie where pixels get pulled from one of the four buf_base frame buffers via the uint64_t *dp array
09:20
John-K
that sounds about right
09:20
Bertl
yeah, that is basically four pixeel a 12 bit in a 64bit block
09:20
John-K
I'm snapping in 12-bit from a monochrome sensor
09:20
Bertl
the pixel are the ones from a complete bayer pattern, i.e. RG/GB
09:21
Bertl
the lower 16 bit are used for overlay data
09:21
John-K
ah, so the VHDL does de-bayering of the data incoming from the sensor?
09:21
Bertl
no, it doesn't, it just puts four sensel together in one block
09:21
Bertl
basically the firs 64bit word gets:
09:22
Bertl
(0,0) (1,0) (0,1) (1,1) <overlay>
09:22
John-K
ah
09:23
John-K
so a four pixel zig-zag and then overlay data that we can throw away
09:23
Bertl
when the image is flipped (the default) it will become:
09:23
Bertl
(0,1) (1,1) (0,0) (0,1) <overlay>
09:23
Bertl
(0,1) (1,1) (0,0) (1,0) <overlay>
09:23
Bertl
*sorry*
09:23
John-K
ah ok
09:31
John-K
so it seems that in the flipped mode that write_dvalue won't output pixels in the correct order if the pixel order is (0,1) (1,1) (0,0) (1,0) <overlay>
09:33
Bertl
yes, the cmv_snap doesn't account for flipping yet
09:36
John-K
k
09:36
Bertl
feel free to add/fix that and send me a patch
09:40
John-K
sure
09:49
John-K
Bertl: if you have a second, the pixel order is slightly off here but I'm having trouble figuring out how http://kelley.ca/temp/slightly_off.png
09:50
John-K
pixel output code https://gist.github.com/John-K/476fec0a17c4625ef423c5dffa788439
09:50
John-K
the wrapping is expected
09:59
John-K
figured it out
10:02
John-K
https://kelley.ca/temp/fixed.png
10:03
John-K
pixel order is (1,0) (1,1) (0,0) (0,1) <16-bit overlay>
10:06
toxitobi
joined the channel
10:08
John-K
Bertl: gist updated with working pixel order
10:10
toxitobi
moin moin
10:10
John-K
morning
10:11
toxitobi
I was wondering if there is a list from all the teammates in the axiom beta project?
10:14
John-K
not that I have seen
10:14
John-K
sebastian or Bertl would know
10:14
RexOrCine
https://apertus.org/team
10:16
toxitobi
Ahh nice thx
10:44
se6astian|away
changed nick to: se6astian
10:45
Bertl
those are actually only those who have bothered to enter themselves there
10:49
Bertl
John-K: thanks, btw, the cmv_snap3 was written in a simple but generic way, because we didn't know what in-memory format we will end up using
10:49
John-K
makes sense
10:49
Bertl
it would improve speed a lot if it would use a line (actually double line) buffer
10:49
Spirit532
joined the channel
10:50
John-K
an output buffer you mean?
10:50
Bertl
i.e. remap two lines of data into an output buffer
10:50
Bertl
then flush that in a single operation
10:50
Bertl
this probably can speed things up by a factor of 10 or so
10:51
John-K
I haven't thought to benchmark it yet, probably some nice optimizations to be had with neon
10:52
Bertl
so if you want to e.g. get high transfer rates for ehternet or save the image efficiently on SD card, then this would be the best place to optimize
10:53
Bertl
if you don't need that speed, don't bother :)
10:53
John-K
it would probably make more sense to swap it in Logic though...
10:54
John-K
*shrug*
10:54
John-K
oh btw, there appear to be some troubles meeting timing requirements when building the VHDL - have you encountered this?
11:04
Bertl
builds fine here, what vivado version do you use?
11:11
John-K
I think I'm on 20161
11:11
John-K
2016.1 rather
11:31
Bertl
ah, we are still on 2015.2
11:31
Bertl
2015.3 had some 'problems' with the timing calculations
11:34
Bertl
off for now ... bbl
11:34
Bertl
changed nick to: Bertl_oO
12:09
John-K
ah, good to know
12:29
John-K
Bertl_oO: when you're back, do you know what causes cmv_snap3 to capture images with part of the image wrapped? I'm starting things with the HDMI disabled
12:29
John-K
if I have to re-run kick_manual.sh for some reason, the offset increases
12:30
John-K
I tried cat /dev/zero > /dev/xdevcfg to see if I could clear PL bitstream before re-running kick_manual.sh but that seems to have no effect
14:58
jucar
joined the channel
15:59
jucar
left the channel
17:09
Bertl_oO
changed nick to: Bertl
17:09
Bertl
John-K: yes, I know what causes that wrapping
17:10
Bertl
there are fifos between the image pipeline and the AXI interface, they need to be 'drained' before a rerun of kick_manual.sh
17:11
Bertl
the problem is, they are not part of the PL, they are part of the hardened AXI interface
17:12
Bertl
so they cannot be properly reset (at least I haven't found a way to do that)
17:13
Bertl
so you need to do a number of steps to properly flush those fifos and make sure that they are not filled when you reload the bitstream
17:13
fredy
left the channel
17:14
Bertl
if you find a way to reset the hardened AXI IP in they Zynq, please let me know :)
17:16
fredy
joined the channel
17:31
John-K
ah :\
17:32
John-K
do you have anything written to drain that AXI interface?
17:35
John-K
left the channel
19:13
danieel
left the channel
19:45
John-K
joined the channel
19:49
John-K
left the channel
21:22
Guillaume_Chooks
left the channel
21:49
Gabe
joined the channel
21:49
Gabe
hello
21:54
toxitobi
Hello Gabe
21:55
Gabe
hi. I was wondering if anyone here has tried out the Haida IR cutoff filter with a wide angle lens on the Beta yet. I know some IR cutoff filters have issues with wide angle lenses
21:56
Gabe
the Haida filter was one suggested by Sebastian
21:58
toxitobi
I don't know and currently there are not so many cameras out there have you got one?
22:00
Gabe
a beta is on its way to me
22:00
Gabe
I can email Sebastian and see what he knows about the filter
22:18
se6astian
answered email :)
22:18
se6astian
are you worried about the filter vignetting the image?
22:40
arpu
left the channel
22:53
arpu
joined the channel
23:17
se6astian
changed nick to: se6astian|away
00:08
toxitobi
left the channel
00:11
John-K
joined the channel
00:12
Bertl
John-K: no, but there are mechanisms in the existing firmware to avoid it
00:13
Bertl
but it shouldn't be too hard to write PL code which drains the fifos
00:16
John-K
left the channel