Current Server Time: 14:43 (Central Europe)

#apertus IRC Channel Logs

2019/04/01

Timezone: UTC


00:13
apurvanandan[m]
I had doubt about the HDMI hack
00:13
apurvanandan[m]
the axiom only has one hdmi currently
00:14
apurvanandan[m]
and how would we direct to the plugin module?
00:14
Bertl_oO
there are two plugin slots on the AXIOM Beta each with 6 LVDS pairs (potential TMDS channels)
00:15
apurvanandan[m]
okay!
00:16
Bertl_oO
so you can use two 'Single HDMI' plugin modules or you can use the triple display port plugin, a 'dual plugin module' and LVDS - TMDS converters for up to three HDMI outputs
00:16
Bertl_oO
there are also four high speed LVDS channels on one of the shield sockets, so in theory you could add a fourth HDMI output there
00:19
apurvanandan[m]
okay, now I am getting things slowly!
00:21
Bertl_oO
the main reason for the current USB 3.0 plugin design is that Zynq used in the MicroZed (which is used as base for the AXIOM) does not support any MGTs, so we need 'something' to allow for high speed USB
00:22
Bertl_oO
unfortunately there are no 'high speed' LVDS to USB 3.x bridge solutions readily available only 16/24/32 bit parallel to USB 3.x
00:22
Bertl_oO
and wasting high speed LVDS channels for medium speed parallel connections wouldn't be a good idea either
00:23
apurvanandan[m]
You make things so clear :D
00:23
Bertl_oO
so we need something which can act as gearwork, receiving the high speed LVDS data and converting it to the medium speed parallel data which then again is converted to USB 3.x
00:24
Bertl_oO
of course, as mentioned before, it could also work the other way round, because the basis for the gearwork is the MachXO2 FPGA on the plugin
00:25
Bertl_oO
in theory one plugin could even support bidirectional solutions where data is sent in both directions
00:32
apurvanandan[m]
Okay I will think of complete mechanism and will discuss with you
00:32
apurvanandan[m]
Thanks :)
00:32
Bertl_oO
you're welcome!
01:10
aSobhy
Ok I check for that and inform you :)
01:10
aSobhy
another question : I saw that the task updated and "pll" is added
01:11
Bertl_oO
yeah, that was just done as an example for clarification
01:12
aSobhy
I am now confused a little for "You can assume a clock with 100MHz and a fixed phase relation."
01:12
Bertl_oO
you can assume that there is a fixed clock of 100Mhz available (to drive your design)
01:13
Bertl_oO
i.e. you usually use a PLL to generate the required frequencies, but it is also fine to 'assume' other clocks if it makes sense
01:13
aSobhy
Ok as an input that I will detect it using pll
01:14
aSobhy
I am assuming the clk is an input for my module
01:16
aSobhy
Ok i got it :)
01:16
aSobhy
thanks Bertl
01:17
Bertl_oO
excellent! you're welcome!
02:43
saurabh_raj
joined the channel
04:27
Bertl_oO
off to bed now ... have a good one everyone!
04:27
Bertl_oO
changed nick to: Bertl_zZ
05:11
saurabh_raj
what is the recommended indent, 2 spaces, 4 spaces or tabs?
05:12
BAndiT1983|away
changed nick to: BAndiT1983
05:14
saurabh_raj
Hi BAndit1983: 2 spaces, 4 spaces or tabs which one is recommended indent?
05:24
BAndiT1983
hi saurabh_raj, would go with 4 spaces for now
05:25
BAndiT1983
at the moment we are evaluating a clang format config, to be able to provide something, because a lot of code is not formatted when sent to review
05:27
saurabh_raj
ok,, I tried to make modifications to my code as per the suggestions you provided, but there seems to be some issue with byte swapping
05:27
saurabh_raj
the images produced look fine without byte swapping but when I add byte swapping they look wrong
05:28
BAndiT1983
changed nick to: BAndiT1983|away
05:29
BAndiT1983|away
changed nick to: BAndiT1983
05:29
mrohit[m]
yes, even I faced this
05:30
mrohit[m]
I think byte swapping isn't required for this data
05:30
BAndiT1983
changed nick to: BAndiT1983|away
05:30
BAndiT1983|away
changed nick to: BAndiT1983
05:35
BAndiT1983
then the cause is wrong splitting of sensel data, there are just 2 causes at this
05:38
saurabh_raj
so the file is in little endian, from what I know endiness does not change bit order, so a 12 bit number like 0x123 is stored as 0x231 or 0x312?
05:41
saurabh_raj
its a silly question, I know but most of the documentation I could find about endiness dealt with 16, 32 bit numbers
05:42
BAndiT1983
changed nick to: BAndiT1983|away
05:42
BAndiT1983|away
changed nick to: BAndiT1983
05:43
BAndiT1983
you can check the data with a hex editor, as i don't remember what the beginning is looking like
05:43
BAndiT1983
but first suggestion is to check the splitting
05:43
BAndiT1983
can't see your code anymore, so you have to check it yourself
05:44
saurabh_raj
yes, I have turned my github repo private. May I have your github id so I may add you as a collab?
05:45
BAndiT1983
changed nick to: BAndiT1983|away
05:46
BAndiT1983|away
changed nick to: BAndiT1983
05:47
BAndiT1983
why have you switched to private?
05:48
BAndiT1983
nevertheless, off to work, will be back on later
05:48
BAndiT1983
changed nick to: BAndiT1983|away
07:27
se6astian|away
changed nick to: se6astian
08:23
aombk
joined the channel
08:25
aombk2
left the channel
09:07
aombk2
joined the channel
09:09
aombk
left the channel
09:27
se6astian
changed nick to: se6astian|away
10:01
se6astian|away
changed nick to: se6astian
10:44
saurabh_raj
Hi se6astian
10:47
saurabh_raj
se6astian: I was doing the C++ challenge and I had some doubt when with endiness, I was hoping you could clarify that
10:57
comradekingu
left the channel
11:33
Bertl_zZ
changed nick to: Bertl
11:33
Bertl
morning folks!
11:35
saurabh_raj
morning Bertl
11:36
saurabh_raj
I had some doubt, maybe you could clarify that for me
11:37
Bertl
so you have a question to one of the qualification tasks?
11:38
saurabh_raj
yes
11:38
Bertl
let's hear then
11:40
aombk3
joined the channel
11:41
saurabh_raj
the raw12 file is in little endian, so from what I know a 12 bit number like 0x123 will be 0x2301 in little endian, but since we are storing two sensels in 3 bytes I figured we must be ignoring the leading zeros
11:41
Spirit532
left the channel
11:41
saurabh_raj
so is 0x123 stored as 0x231 in the file?
11:43
aombk2
left the channel
11:47
aombk2
joined the channel
11:51
aombk3
left the channel
11:51
aombk
joined the channel
11:52
aombk3
joined the channel
11:53
aombk2
left the channel
11:56
aombk
left the channel
12:00
saurabh_raj
Bertl: is that correct?
12:06
RexOrCine|away
changed nick to: RexOrCine
12:07
aombk
joined the channel
12:08
aombk3
left the channel
12:10
aombk2
joined the channel
12:13
aombk
left the channel
12:22
Bertl
there are no 'leading' zeros in the data stored in the raw12
12:22
Bertl
i.e. the raw12 are packed and each bit contains data
12:23
saurabh_raj
so the number 0x123 will be as 0x231 in the file?
12:23
saurabh_raj
i mean since it is little endian
12:24
Bertl
it depends on the position in the datastream
12:24
Bertl
and the endianess of your system and how you read the data
12:24
saurabh_raj
if I read the entire data into a char array then the data is read as is
12:25
saurabh_raj
then will I have to swap then access the values?
12:25
Bertl
then the stream will consist of bytes
12:25
Bertl
<B0><B1><B2><B3> ...
12:25
Bertl
B0 and half of <B1> will make up the first 12bit value
12:26
Bertl
the other half of <B1> and <B2> the second 12bit value
12:26
saurabh_raj_
joined the channel
12:28
saurabh_raj_
so the starting part of sensel 1 should be in B1 right? or is it in B0?
12:29
saurabh_raj
left the channel
12:30
Bertl
with the file being little endian, the least significant bits are in <B1>
12:39
Spirit532
joined the channel
12:42
saurabh_raj_
so the least sgnificant 4 bits among the 12 bits will be in B1 for sensel 1. bo
12:43
Bertl
that is what little endian means, yes
12:43
saurabh_raj_
and since we need 8 bits so we can leave B1 for sensel 1..
12:43
Bertl
that depends on what you are doing with the data
12:47
saurabh_raj_
so I think no byte swapping will be required for getting 8 bit sensel values for sensel 1 as the most significant bits will be in B0 and endiness does not change bit order.. right?
12:52
Bertl
do you want me to solve the challenge task for you?
12:55
saurabh_raj_
left the channel
13:13
saurabh_raj
joined the channel
13:15
saurabh_raj
Bertl: Thats funny.. actually one of mentos suggested that I should consider byte swapping since I was getting some artifacts in the output image so I was just checking with you if what I was doing is wrong or not?
13:29
saurabh_raj
left the channel
13:41
Bertl
well, part of the challenge is to figure things like this out (on your own)
13:42
Bertl
it is rather simple to check whether you need to swap anything by separating out the channels
13:43
Bertl
i.e. read the raw12 in whatever way you consider appropriate, then generate a separate 8bit or 12bit image per channel (R,G1,G2,B)
13:43
Bertl
then look at the images and combine the channels to an RGB image
13:43
Bertl
any bit or byte order problems or issues with your interpretation of the data should be pretty obvious
14:04
saurabh_raj
joined the channel
14:06
saurabh_raj
Bertl: Thanks, found the bug.
14:15
moustafa
joined the channel
14:15
saurabh_raj
left the channel
14:33
moustafa
hi Bertl, i want to ask if i can do code challenges using verilog not vhdl? as i am interested in Pixel Re-mapper task.
14:33
rohan_
joined the channel
14:34
moustafa
left the channel
14:35
moustafa
joined the channel
14:35
rohan_
hey BAndiT1983, se6astian
14:36
rohan_
had been going through T1121 over the past few days
14:38
rohan_
guess you guys are away right now. will come back later
14:42
se6astian
I am here
14:43
moustafa
left the channel
14:51
rohan_
se6astian, i have completed the T872 challenge
14:53
rohan_
I found T1121 to be interesting, so was learning shell scripting when I got time
14:54
rohan_
so I wanted to ask some questions to confirm what is expected for the task
15:02
se6astian
sorry about to leave the axiom office now
15:02
se6astian
email?
15:02
rohan_
sure
15:03
rohan_
can you provide your email id?
15:04
se6astian
https://www.apertus.org/GSoC-2019-Mentor-Contact-List
15:04
se6astian
changed nick to: se6astian|away
15:04
rohan_
left the channel
15:07
aSobhy
hello Berlt, I have simulated the module after synthesizing on clock 100ps on modlesim and worked fine :)
15:07
aSobhy
could you explain what is meant by "add the data as VCD file?" for me !
15:10
aSobhy
and the max frequency of dropped to 665 MHz on max10 fpga ("there was a mistake")
15:11
RexOrCine
"(16:38:19) rohan_: guess you guys are away right now. will come back later" < Even if this seems to be the case, still post your questions here as nothing is lost and they'll be answered when someone comes back online.
15:11
aSobhy
and I have send the git-hub link for the code to your mail :) can you check it :)
15:16
Bertl
aSobhy: 100ps ?
15:16
aSobhy
100 pico
15:16
Bertl
VCD = value change dump https://en.wikipedia.org/wiki/Value_change_dump
15:17
Bertl
aSobhy: that would be 10GHz
15:19
aSobhy
yeah its a simulation !
15:19
Bertl
I'm pretty sure your 'favorite' simulation tool can write those
15:19
Bertl
aSobhy: there is no point in running functional simulation in the GHz range, it will always be just fine
15:20
Bertl
but if you managed to get a post implementation simulation running at 10GHz, then something is definitely wrong :)
15:22
dcz
joined the channel
15:23
aSobhy
so iam wrong the process i have done :
15:23
aSobhy
- synthesis and routing
15:23
aSobhy
- start post-synthesis and output the generated .vho file
15:23
aSobhy
- simulate it on model-sim
15:24
Bertl
post-synthesis = functional, no implementation done there
15:25
Bertl
post-implementation (timing) is what you want
15:25
shivamgoyal
joined the channel
15:28
shivamgoyal
left the channel
15:31
aSobhy
OK iwill find it :)
15:32
dcz
hi guys, is there anyone around knowing which 1/2.3 and smaller sensors are FLOSS-friendly?
15:33
dcz
there's the image sensor table in the wiki, but it's only general
15:33
Bertl
we are quite happy with the ones we investigated (see AXIOM Beta page)
15:33
RexOrCine
https://wiki.apertus.org/index.php/Image_Sensor_Table
15:33
Bertl
we also know that OnSemi is quite FLOSS friendly
15:33
Bertl
especially on the small sensors
15:33
dcz
ah, good to know
15:38
anuejn
dcz: well onsemi is about the only thing, that is purchasable at all
15:38
anuejn
i would not call them FLOSS friendly by any means
15:39
dcz
I think there's Samsung sensors possible to buy as well?
15:39
anuejn
we went for the ar0330 and it is _possible_ to interface them with the existing documentation
15:39
anuejn
but it is not _nice_
15:39
anuejn
dcz: if you could provide a link, that would be great
15:40
dcz
I should have a datasheet somewhere, but I don't know about availability outside China
15:40
anuejn
many sensors have a high moq, so it is difficult to design anything with them
15:41
anuejn
can you give the datasheet?
15:41
dcz
I'm looking for it rn
15:41
anuejn
there also some other onsemi image sensors which are interesting
15:42
dcz
interesting in what sense?
15:43
anuejn
but most of them are either hard to source in small quantitys (only chinese distributors) and / or not (intentionally) publicly documented
15:43
anuejn
mostly bigger sensor size or more resolution then the ar0330
15:44
dcz
porcupinefactory.org/data/S5K3L6XX_Preliminary_Data_Sheet_REV0.05.pdf
15:44
dcz
add http:// in the front
15:46
anuejn
oh nice!
15:47
anuejn
do you know how much it is and how easy it is to source?
15:48
dcz
anuejn: I can ask around, do you mind if I send you an email?
15:48
anuejn
no, definitely not
15:49
anuejn
would be great :)
15:49
dcz
what's your address?
15:49
anuejn
send you a pm
15:50
anuejn
did you find any other interesting sensors?
15:51
anuejn
(am asking for https://github.com/axiom-micro/mainboard)
15:51
dcz
that's a bit of a problem, because I'm not entirely sure what to look for
15:52
BAndiT1983|away
changed nick to: BAndiT1983
15:52
dcz
I'm trying to get something good for https://puri.sm/products/librem-5/
15:52
anuejn
ah i see
15:53
anuejn
so you are probably looking for a rather high res cmos?
15:53
dcz
10MPix+
15:53
dcz
the big worry of mine is writing the software if the sensor doesn't come with a DSP\
15:54
dcz
and the performance of encoding video on an ARM chip
15:55
dcz
you're not interfacing with the sensor using Linux, are you?
15:55
anuejn
but the i.mx8 does have hard ip for h264 encoding, no?
15:55
anuejn
dcz: well... we are interfacing it with an fpga
15:56
dcz
the version we will use only has a hw decoder :(
15:56
anuejn
then the raw image data is in ram which is shared between arm and fpga but the main idea is to explicitly not move all the data through the arm core
15:57
anuejn
that might get... sportive ;)
15:57
anuejn
does it have a mipi interface
15:57
anuejn
?
15:57
dcz
yes
15:57
dcz
thankfully
15:57
anuejn
hm...
15:58
anuejn
I have to say, that i doubt that it is possible to do realtime compression of video on that soc then
15:58
anuejn
anyways, battery performance will probaby get really poor
15:58
dcz
we're gonna have to cut down on resolution
15:59
anuejn
hm... what do you have in mind there?
15:59
anuejn
and did you conclude any testing on the performance?
16:00
dcz
assuming it's not moving the data that's the most expensive, then encoding a downsampled stream is going to be less intensive
16:00
saurabh_raj
joined the channel
16:00
dcz
not of the camera performance
16:00
saurabh_raj
Hk BandiT1983, back from work?..
16:01
anuejn
but did you try simple encoding tests with for example ffmpeg?
16:01
dcz
nope
16:01
anuejn
hm k
16:02
anuejn
if it is possible, it might be helpfull to throw a hardware decoder / fpga at the problem
16:02
anuejn
but idk anything about the project in depth so my comments are probably not really helpful
16:03
dcz
we're going to have to think about it some day, but that's unlikely to happen with the first hardware revision
16:03
dcz
we're running out of space and costs
16:03
dcz
nah, it's fine, I'm happy to describe some challenges that we've had :)
16:04
anuejn
but we have had performance troubles with just coppying the raw data to the ethernet with the arm
16:04
dcz
anuejn: do you know of any phone-like sensors that have the encoding hardware on board? the biggest I've seen was 5MPix
16:04
BAndiT1983
saurabh_raj, yes
16:04
anuejn
i also think, that it got less
16:05
anuejn
there are fewer new sensors to my finding
16:05
anuejn
probably bc. all the new socs are doing hardware encoding themselves
16:06
saurabh_raj
I have turned my code back to public, maybe you could have a look, n let me know there is more to be fixed
16:06
dcz
yeah, that's what I've been thinking too
16:06
dcz
skipping the video topic, what do you think is worth to look for in sensors suitable for stills, outside of price?
16:06
dcz
or, what would you like to see in a phone sensor?
16:07
BAndiT1983
saurabh_raj, should i reply by mail, so it's only visible to you and some mentors?
16:07
saurabh_raj
sure. please do.
16:08
anuejn
definitely raw access to the data
16:09
BAndiT1983
ok, will do it a bit later, have to switch off from work first , as i'm doing coding all day long
16:09
dcz
that's going to be easy
16:09
anuejn
yeah :)
16:11
dcz
do they usually come with lens assemblies?
16:11
anuejn
the image sensors?
16:11
anuejn
no
16:11
anuejn
but you can order ready made modules
16:12
anuejn
that was one of the questions i wanted to ask :) what kind of optics do you plan?
16:12
dcz
oh, I suppose then mechanical stabilization could come in handy
16:12
dcz
I don't actually have the faintest clue
16:12
dcz
here's your chance to influence the design :)
16:12
saurabh_raj
BandiT1983: not an issue,
16:12
anuejn
yes, but that might be hard to do (i dont know, but suppose)
16:13
anuejn
i would be interested in fast optics, as this directly infulences image quality drastically
16:13
dcz
fast as in bright?
16:13
anuejn
yup
16:14
anuejn
maybe changable lenses would be nice but probably somehow utopic
16:14
dcz
I'm afraid that would be difficult to design
16:14
anuejn
(there is a lens mount, that is actually only an m8 thread)
16:15
dcz
how do you measure how fast the optics are? bigger f/ numbers? more transparent materials?
16:15
anuejn
yeah for a phone it would probably be way to big
16:15
anuejn
smaller f numbers mean geometrically brighter lenses
16:15
anuejn
(on a log scale)
16:16
dcz
right, the scale is reversed
16:17
dcz
focusing speed doesn't depend on lenses, does it?
16:17
anuejn
so f1.0 is about double the light of f1.3
16:17
anuejn
https://en.wikipedia.org/wiki/F-number
16:18
anuejn
t stops measures the amount of light, that makes it actually through the lens
16:18
dcz
my camera goes down to 3.2 :( I think that's also the sensor size
16:18
dcz
(in inverse)
16:19
anuejn
f stops is independent of sensor size
16:19
dcz
yeah, but coincidentally ;)
16:19
anuejn
(actually it way is easier to design a fast lens for a small sensor)
16:20
anuejn
also, the f number impacts the depth of field (together with the sensor size)
16:21
dcz
no bokeh with my camera
16:21
anuejn
so if you have a really small sensor (and therefore a short focal length for a "normal" zoom) and a not-too-bright lens, you can probably get away without autofocus at all
16:22
anuejn
but that is also dependent on how near the nearest object can come
16:22
dcz
f/3.0, 1/3.2, 2m+?
16:22
anuejn
I would like to have manual focus, if there is any focusing posibility :)
16:23
dcz
that's software though
16:23
dcz
I think focusing is quite reasonable to have, considering that people take macro pictures
16:23
anuejn
focal length is normally given in mm and should be in the range of ~5mm for your usecase (i guess)
16:24
dcz
is there a calculator somewhere I could use to estimate whether we need focusing?
16:25
anuejn
http://www.dofmaster.com/dofjs.html
16:25
dcz
thanks
16:26
saurabh_raj
left the channel
16:30
anuejn
that would be ~50cm for the closest sharp projection with your setup
16:30
dcz
seems so
16:30
anuejn
are you planing on having a front facing camera?
16:31
dcz
yes, that's going to be something smaller and I think with a DSP
16:31
dcz
5MPix
16:32
anuejn
ah ok
16:32
anuejn
have you decided on the chip and optical assembly already?
16:33
dcz
don't think so
16:33
danieel
dcz: some cameras adhere to SMIF standard for control, it is a defined API without custom blobs / secret registers
16:33
dcz
I'm sure we have a couple of candidates
16:33
dcz
looks up SMIF
16:33
anuejn
you might also want to buy a ready made optical assembly for the back camera
16:33
anuejn
maybe even from another phone, to reduce complexity
16:34
dcz
I think that's what's going to happen actually
16:35
se6astian|away
changed nick to: se6astian
16:35
dcz
danieel: can you post a link to SMIF?
16:35
danieel
looking for it, maybe some letter wrong :)
16:36
danieel
SMIA ! mostly nokia phones used that, even up to the 41MP sensor in the lumia
16:36
anuejn
otherwise you need a way to precisely manufacture mechanical / optical parts which might be out of scope for your project
16:37
dcz
thanks
16:37
dcz
that is definitely out of scope :)
16:37
danieel
the other way is just snoop the i2c of a existing camera
16:38
danieel
because you need something that is physically new, not a trashbin part :)
16:39
dcz
there are a couple of Samsung drivers in the Linux kernel thanks to Android
16:39
dcz
shouldn't be terrible
16:39
dcz
is phase-shift autofocus worth looking for?
16:40
danieel
i dont know how reliable those codes are, when we had to do something on android, there was a userspace blob that e.g. did the focusing
16:40
danieel
and other usage of the sensors, the kernel part could be just a glue code
16:40
danieel
but look for cameras that are eg compatible with something as iMX6
16:40
danieel
those shall have full source in kernel
16:42
dcz
do you mean that the glue code has some magic without which it's impossible to control the sensor?
16:42
danieel
it can have the magic missing, especially on android
16:50
moustafa
joined the channel
16:52
moustafa
left the channel
17:00
comradekingu
joined the channel
17:02
danieel
dcz: looking at the imx219 camera driver that is used in RPi, it seems a complete driver (but the camera is rather basic perf, no wonders)
17:02
dcz
that's one of the Exmor ones, isn't it
17:03
danieeel
joined the channel
17:04
danieeeel
joined the channel
17:04
danieel
left the channel
17:04
danieeeel
changed nick to: danieel
17:07
danieeel
left the channel
17:11
intrac
left the channel
17:39
Umori
left the channel
17:42
Umori
joined the channel
17:46
Umori
left the channel
17:46
Umori
joined the channel
18:04
anuejn
dcz: some of the linux drivers are rather bad
18:04
dcz
in general or for specific devices?
18:04
anuejn
they only send a bunch of undocumented sequences to the sensor
18:04
dcz
oh
18:04
anuejn
well we looked specifically for the ar0330 ones
18:07
anuejn
i think it is not too hard to write a driver, if you have proper documentation
18:07
anuejn
but if you have ndaed datasheets and register reference that is not much fun
18:08
anuejn
and all that stuff is mostly really proprietary and cursed
18:08
rohan_
joined the channel
18:09
rohan_
Hey BAndiT1983. Please go through my code for the T882 challenge when you get time : https://github.com/rohan-malik/Challenge.git
18:10
anuejn
(as in wired; the ar0330 has some magic init sequences and some binary patches that you are supposed to upload to the sensor via i2c depending on the hardware revision)
18:14
rohan_
left the channel
18:14
dcz
that's not encouraging
18:21
anuejn
well you might want to find a way to get the documentation somehow
18:22
anuejn
I heard @whitequark has a library for that kind of stuff that might be worth looking at ;)
18:34
dcz
one sensor we can apparently source: https://wholesaler.alibaba.com/product-detail/HYNIX-HI843-Hi846-Sensor-AF-Goldfinger_60666745302.html
18:35
anuejn
do you have any datasheet for that?
18:37
dcz
unfortunately not
18:37
vup2
dcz: http://www.gizbeat.com/wp-content/uploads/AR1335-D-PDF-framos.pdf this one has atleast a datasheet
18:37
vup2
and is quite sourceable
18:41
dcz
OnSemi does seem open
18:41
vup2
well open is maybe stetching it a bit
18:41
vup2
you can find some datasheets on some websites
18:42
vup2
but officially you only get them under NDA
18:42
niemand
joined the channel
18:42
niemand
left the channel
18:42
niemand
joined the channel
18:42
vup2
also the really interesting stuff like register references or developer guides are nearly impossible to find without NDA
18:42
vup2
but atlesat for the register reference of this sensor there might be some possibilities
18:43
dcz
how were the sensors in the wiki tested? with an NDA or were the documents available with some luck?
18:47
anuejn
idk, I think se6astian is the person to ask there
18:49
se6astian
which sensors? (wiki link)?
18:50
anuejn
https://wiki.apertus.org/index.php/Image_Sensor_Table
18:51
se6astian
right, how do you mean "tested"?
18:53
intrac
joined the channel
18:59
se6astian
the wiki tablet does not contain any information acquired under an NDA if that is the question
19:28
vup2
Bertl: which connectors does the beta use for connection between the sensor board and mainboard / interface board?
19:32
se6astian
you can find them in the bom on the wiki
19:33
se6astian
Hirose FX10 series IIRC
19:33
se6astian
in 100 and 144 pin variants depending on the board
19:35
se6astian
more pins between sensor board and interface board
19:35
se6astian
less between interface board and mainboard
19:47
Dev_
joined the channel
19:47
niemand
left the channel
19:49
Dev_
Hello , Can i submit draft proposal for review on GSoC website, so i can change it accordingly or is it too early
19:50
RexOrCine
Dev_ Is this your first contact with us?
19:50
Dev_
No i am here for a long time
19:50
Dev_
i have completed the c/c++ challenge
19:51
RexOrCine
OK. Best thing to do would be to put the text into a Google Doc and I'll take a look at it.
19:51
RexOrCine
(I'd need edit privileges probably). If you send a link to the team email address.
19:52
Dev_
okay, i will do it
19:52
Dev_
Thanks
19:53
Dev_
also BAndiT1983 , Can u review the challenge code once agian, i tried to change AVI generation , hope it is okay now
19:55
Dev_
If you send a link to the team email address : RexOrCine should i send it to team email adress or on GSoC website
20:00
intrac
left the channel
20:01
intrac
joined the channel
20:03
BAndiT1983
hi Dev_, where is your code residing?
20:04
Dev_
Link : - https://github.com/kakashi-Of-Saringan/T782-Apertus-Qualification-Task
20:06
BAndiT1983
ok, will check when i have some time
20:06
Dev_
Np
20:06
Dev_
thanks
20:18
Dev_
RexOrCine: for edit privileges, can you please give me your Email adress
20:18
Dev_
address*
20:28
RexOrCine
You shouldn't need that. Go to share, select "anyone with the link can edit" from the options, then copy the resulting link.
20:35
RexOrCine
Found it?
20:35
Dev_
yes ,
20:37
Dev_
How should i share it u, PM??
20:37
RexOrCine
OK.
20:38
vup2
se6astian: thanks
20:39
RexOrCine
Dev_ Actually no, please send it to the team email address - https://www.apertus.org/contact Will look at it through the night/morning.
20:41
Dev_
to Team emial address ?, okay
20:41
Dev_
email*
20:41
RexOrCine
changed nick to: RexOrCine|away
20:42
intrac
left the channel
20:42
intrac
joined the channel
20:45
Dev_
left the channel
20:49
Dev_
joined the channel
20:50
Dev_
Done !!
20:51
dcz
left the channel
20:54
Y_G
joined the channel
20:59
Y_G
Hi ,in the https://github.com/apertus-open-source-cinema/axiom-beta-firmware/blob/master/software/scripts/set_wb.py how are we determining the value of color_matrix?
20:59
Y_G
Would these be different for different illumination conditions ?
21:01
Dev_
left the channel
21:03
araml
joined the channel
21:21
se6astian
Y_G: yes
21:21
se6astian
Y_G: how are we determining the value of color_matrix? <- that is the whitebalancing mystery to be solved
21:23
se6astian
it could be done empirically
21:25
se6astian
gotta go
21:25
se6astian
good night
21:26
se6astian
changed nick to: se6astian|away
21:29
Y_G
left the channel
21:57
BAndiT1983
changed nick to: BAndiT1983|away
22:01
Ashu
joined the channel
22:03
Dev_
joined the channel
22:15
Ashu
Hello, Bertl !!
22:17
Y_G
joined the channel
22:18
Y_G
Thanks se6astian
22:18
Ashu
I read about visualisation part , I have made a plan about it .
22:19
Y_G
So we are focusing on semi automatic white balancing here ,where we can set various illuminations like sunny ,fluorescent and get the respective white balanced/color corrected image ,right?
22:20
Y_G
I'll get back to you on this tommorow ,good night :)
22:20
Y_G
left the channel
22:22
Ashu
which is as following : we will be using Graphicmagic as it is preferred over imagemagick for speed (read in stackoverflow and few blogs about it).
22:24
Ashu
we can re-use the same fixed-size image (basic graphical cordinates and scales) and re-write it over and over everytime we need new graph using SetImagePixels() .
22:27
Ashu
followed by SyncImagePixels().
22:31
Ashu
for this we can use Wand API, which is prefered for drawing graphical primitives.
22:34
Ashu
what you think about this approach ?
22:36
Ashu
please let me know if there are some changes needed . I will be reading logs ;) .
22:43
Ashu
left the channel
22:48
uberardy_
left the channel
22:49
uberardy
joined the channel
23:20
Dev_
left the channel
23:27
Bertl
Ashu: let's talk about that tomorrow evening ...
23:28
Bertl
off to bed now ... have a good one everyone!
23:28
Bertl
changed nick to: Bertl_zZ
23:45
Ashu
joined the channel
23:46
Ashu
Okay, Bertl fine with me .
23:49
futarisIRCcloud
joined the channel
23:51
Ashu
left the channel