| 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 |