Current Server Time: 18:33 (Central Europe)

#apertus IRC Channel Logs

2016/05/21

Timezone: UTC


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