| 23:56 | Spirit532 | left the channel |
| 01:37 | alexML_ | joined the channel |
| 01:37 | rexbron_ | joined the channel |
| 01:41 | rexbron | left the channel |
| 01:41 | TD-Linux | left the channel |
| 01:41 | alexML | left the channel |
| 02:03 | TD-Linux | joined the channel |
| 07:10 | Bertl_zZ | changed nick to: Bertl
|
| 07:10 | Bertl | morning folks!
|
| 07:37 | pusle | left the channel |
| 08:41 | ItsMeLenny | left the channel |
| 08:41 | ItsMeLenny | joined the channel |
| 08:51 | dimaursu16 | joined the channel |
| 09:00 | Spirit532 | joined the channel |
| 09:09 | aombk3 | left the channel |
| 09:09 | aombk3 | joined the channel |
| 09:22 | dimaursu16 | left the channel |
| 09:40 | aombk2 | joined the channel |
| 09:42 | aombk | joined the channel |
| 09:43 | aombk3 | left the channel |
| 09:45 | aombk2 | left the channel |
| 09:45 | dimaursu16 | joined the channel |
| 10:15 | jucar | joined the channel |
| 10:43 | se6astian|away | changed nick to: se6astian
|
| 10:54 | jucar | left the channel |
| 10:56 | BogdanXor | joined the channel |
| 10:57 | BogdanXor | on the AWS Xilinx FPGA dev instance, I got access to the program and to their documentation + infrastructure and the documentation states clearly, as expected, that the Vivado installation is device-locked to the Virtex Ultrascale+ device they are using
|
| 10:58 | BogdanXor | btw, have you guys considered using Slack for collaboration? :D
|
| 10:59 | Bertl | we haven't considered any proprietary vendor-lock-in solution yet
|
| 11:00 | Bertl | @AWS yeah, that makes sense
|
| 11:19 | BogdanXor | left the channel |
| 11:23 | dimaursu16 | left the channel |
| 11:23 | dimaursu16 | joined the channel |
| 11:23 | dimaursu16 | left the channel |
| 11:23 | dimaursu16 | joined the channel |
| 11:41 | dimaursu16 | left the channel |
| 11:53 | Spirit532_ | joined the channel |
| 11:57 | Spirit532 | left the channel |
| 12:20 | dimaursu16 | joined the channel |
| 12:20 | dimaursu16 | left the channel |
| 12:20 | dimaursu16 | joined the channel |
| 12:32 | danieel | Spirit532_: to me it seems like a sensor defect on the 2 columns - does the camera appear as an UVC device, or you use any ximea drivers? They might be processing the image - anyway the DNGs are RGB not bayer thus that is definitely not raw data
|
| 12:33 | Spirit532_ | changed nick to: Spirit532
|
| 12:33 | Spirit532 | ximea drivers
|
| 12:33 | danieel | it might be just one broken sensor column and it show as two after debayer in their hw/sw
|
| 12:34 | Spirit532 | I don't have control over the camera's functions atm
|
| 12:34 | Spirit532 | onky esposure and gain
|
| 12:34 | Spirit532 | only*
|
| 12:34 | danieel | what else would you want?
|
| 12:34 | Spirit532 | you can turn on sensor correction & stuff
|
| 12:34 | Spirit532 | and other functions
|
| 12:35 | danieel | those are model dependant and not everything is everywhere if you refer to their xi api
|
| 12:35 | Spirit532 | yes, but it's on mine.
|
| 12:36 | danieel | Bertl: what hw corrections have the CMV* parts? I thought there are none.. as we were happy seeing the KAC did had some
|
| 12:36 | Spirit532 | none, basically.
|
| 12:36 | danieel | so just sw postprocess from the reference row/cols
|
| 12:37 | Bertl | danieel: haven't seen any hardware corrections in the CMV* parts yet
|
| 12:37 | Spirit532 | it's in the fpga
|
| 12:37 | danieel | that would be black level correction only probably :) the fpga is fairly small
|
| 12:38 | Spirit532 | not sure what it does, but it does something.
|
| 12:38 | danieel | Bertl: i know they are doing a (temperature,freq) based corrections - have you done any frequency sweep to see noise response?
|
| 12:40 | Bertl | you mean sweep the LVDS clock? no haven't tried that yet
|
| 12:40 | danieel | yes, that one
|
| 12:40 | Bertl | with temperature, we haven't seen much change in our tests
|
| 12:41 | Spirit532 | I'm not sure what is wrong with the camera running over usb2
|
| 12:41 | Spirit532 | but when I decrease exposure, it goes all funny and noisy
|
| 12:41 | Bertl | well, USB2 has probably too little bandwidth
|
| 12:41 | danieel | the freq as a factor is there probably because line time and termal generation - slower you scan, higher the difference from top to bottom
|
| 12:41 | Spirit532 | but that's what happens when you run something on something you're not supposed to run it on
|
| 12:41 | Spirit532 | lol
|
| 12:42 | Bertl | danieel: are you sure the sensor does any correction for that?
|
| 12:42 | danieel | not the sensor, the sw or fpga
|
| 12:42 | Bertl | ah, okay, yes that is correct, the FPGA is supposed to do any corrections
|
| 12:43 | danieel | we were discussing something with them + got their head here.. and asked what they really do
|
| 12:43 | Bertl | got it! thanks for clarifying
|
| 12:43 | danieel | anyway it unusable for the situation
|
| 12:57 | arpu | joined the channel |
| 14:06 | ItsMeLenny | left the channel |
| 14:58 | arpu | left the channel |
| 14:58 | davidak | joined the channel |
| 15:01 | se6astian | changed nick to: se6astian|away
|
| 15:10 | arpu | joined the channel |
| 15:58 | Spirit532 | I am very impressed with the cmv2k sensor so far
|
| 15:58 | Spirit532 | not perfect in extreme low light
|
| 15:58 | Spirit532 | but I wouldn't expect a 2/3" sensor to be, haha
|
| 16:00 | Spirit532 | but the camera tool is a bit wonky in exposure settings.
|
| 16:47 | se6astian|away | changed nick to: se6astian
|
| 17:11 | slikdigit | joined the channel |
| 17:34 | davidak | left the channel |
| 18:12 | davidak | joined the channel |
| 18:14 | slikdigit | left the channel |
| 20:48 | se6astian | changed nick to: se6astian|away
|
| 21:18 | dimaursu16 | left the channel |
| 22:11 | slikdigit | joined the channel |
| 22:49 | dimaursu16 | joined the channel |