Current Server Time: 02:04 (Central Europe)

#apertus IRC Channel Logs

2018/05/21

Timezone: UTC


01:57
lexano
joined the channel
02:51
jucar
left the channel
03:12
jucar
joined the channel
03:29
Bertl_oO
off to bed now ... have a good one everyone!
03:29
Bertl_oO
changed nick to: Bertl_zZ
03:29
rton
left the channel
03:30
aombk
left the channel
03:34
aombk
joined the channel
04:53
futarisIRCcloud
left the channel
05:42
ymc98_1
left the channel
05:42
ymc98_1
joined the channel
06:12
illwieckz
left the channel
06:26
illwieckz
joined the channel
06:30
BAndiT1983|away
changed nick to: BAndiT1983
09:21
se6astian|away
changed nick to: se6astian
10:39
TofuLynx
joined the channel
10:40
TofuLynx
Good Morning!
10:40
Bertl_zZ
changed nick to: Bertl
10:40
Bertl
morning folks!
11:45
se6astian
changed nick to: se6astian|away
11:58
rton
joined the channel
12:18
BAndiT1983
hi TofuLynx, how is it going?
12:49
ymc98
left the channel
12:55
TofuLynx
Hey BAndiT1983
12:56
TofuLynx
I am struggling to find a optimal solution to demosaic the borders
12:56
TofuLynx
Due to the fact that the places where are stored usable values are always changing
13:01
Bertl
off for now ... bbl
13:01
Bertl
changed nick to: Bertl_oO
13:04
BAndiT1983
values for borders should be copied from next available ones, and then adjusted through luminance or something like that, just so that they are not totally different
13:04
BAndiT1983
is the other stuff working? as borders should be of least concern
13:07
BAndiT1983
so, off for some time, will be back later
13:08
BAndiT1983
changed nick to: BAndiT1983|away
13:10
TofuLynx
Yeah the other stuff is working
13:11
TofuLynx
you can see the commit on the chat at lab
13:55
ArunM
joined the channel
14:46
se6astian|away
changed nick to: se6astian
14:47
RexOrCine|away
changed nick to: RexOrCine
14:54
RexOrCine
anuejn: Is there likely to be any more technical information related to plugin modules added to that section of the Wiki?
16:06
anuejn2
Yes definitely
16:07
anuejn2
The pinout an mechanical spec of the plugins and some power reluted stuff
16:13
RexOrCine
anuejn2: OK, then it might be worth starting a separate page so that we can evaluate what's suitable for where. At the moment that section is kind of an overview, in which case, and if we maintain that feel, a link to a dedicated page referring to the technical details of plugin modules might be best (or at least something to consider) - https://wiki.apertus.org/index.php/AXIOM_Beta/Camera_Structure/Plugin_Modules
16:15
RexOrCine
Let's see what you build up and take it from there.
16:42
BAndiT1983|away
changed nick to: BAndiT1983
16:45
TofuLynx
BAndiT1983: Hello
16:57
g3gg0
joined the channel
16:57
g3gg0
yoyo
16:57
g3gg0
hi
17:00
TofuLynx
Hello g3gg0 :)
17:00
TofuLynx
How are you?
17:00
g3gg0
uuuh just realized we had meeting at 19.00
17:00
g3gg0
fine thanks, a bit busy as you might have noticed
17:00
g3gg0
and how are you?
17:05
TofuLynx
Wait, who is "we" ?
17:05
TofuLynx
I am fine too :)
17:11
BAndiT1983
hi TofuLynx
17:12
g3gg0
oh im so dumb
17:12
g3gg0
we had yesterday (SUN) at 18.00 and today (holiday in germany) at 19.00
17:12
g3gg0
and i mixed up both -.-
17:12
g3gg0
thats why i am here at 18.00
17:26
TofuLynx
Hey BAndiT1983
17:26
TofuLynx
Did you see what I wrote after you went afk?
17:26
TofuLynx
We have a meeting today?
17:27
BAndiT1983
yes
17:28
BAndiT1983
and yes
17:31
Iti_
joined the channel
17:32
Iti_
Good evening everyone!
17:32
BAndiT1983
hi
17:33
Iti_
How are you BAndiT1983 ?
17:34
TofuLynx
What kind of meeting? I know nothing
17:35
TofuLynx
Hello Iti_!
17:35
Iti_
Sebastian send a mail on apertus-gsoc about weekly meeting 2-3 days ago I guess
17:35
Iti_
Hi TofuLynx :D
17:35
Iti_
Good that you're already here, but would recommend you to join that group
17:36
BAndiT1983
Iti_: fine, and you?
17:36
BAndiT1983
TofuLynx: it was in the mails
17:37
BAndiT1983
ressurection of regular meetings on mondays
17:37
TofuLynx
Ok, I have to add myself to the mailing list to be notified
17:37
BAndiT1983
bi-weekly ones
17:37
TofuLynx
wait, but I am on the group. How do I get notified?
17:38
BAndiT1983
if you are a member of apertus-gsoc, then it should come automatically
17:38
Iti_
BAndiT1983 : I'm kind of tired because exams going on, but just one exam is left which is on 23, so hopefully after that I can breathe a little!
17:38
BAndiT1983
check your spam folder
17:38
BAndiT1983
is end of may general phase of exams?
17:38
Iti_
In India, mostly yes
17:39
Iti_
Some Universities get over with it in early May, but my Uni is kind of late in such stuff. So, it ends on almost end of May
17:40
TofuLynx
In my university the first phase of exams is June
17:40
BAndiT1983
hope that it does not affect gsoc too much
17:40
TofuLynx
Also, I fixed the issue with the mailing group. I had to check a box to get notified
17:40
TofuLynx
Hopeful not :)
17:41
TofuLynx
It's a exam per week, it's well organized. Not too crowded
17:41
Iti_
BAndiT1983 : It's almost over, after 23 I'll have almost 2 months off as summer vacation! :D
17:41
TofuLynx
That's Great! :D
17:42
TofuLynx
BAndiT1983: Do I have to prepare something for the meeting?
17:48
supragya
Good evening!
17:48
Iti_
Good evening supragya!
17:49
TofuLynx
Hello supragya!
17:50
supragya
:)
17:50
supragya
How are you guys doing?
17:52
se6astian
hi there
17:52
se6astian
good, meeting in 8 minutes
17:52
Iti_
Hello,se6astian!
17:52
ArunM
left the channel
17:54
TofuLynx
I am good
17:54
TofuLynx
Hello se6astian
17:55
g3gg0
re
17:55
g3gg0
hi supragya
17:55
g3gg0
got my mail?
17:56
supragya
as always, I am losing packets
17:56
BAndiT1983
TofuLynx: no, it's just about current states, problems and so on, general overview usually
17:58
supragya_freenod
joined the channel
17:59
supragya_freenod
It's tuff for my network to hold up for IRC packets today..
17:59
g3gg0
IP over avian carrier?
17:59
Bertl_oO
changed nick to: Bertl
17:59
Bertl
evening folks!
17:59
se6astian
perfect timing
18:00
supragya_freenod
left the channel
18:00
se6astian
so a very warm welcome to everyone
18:00
ArunM
joined the channel
18:00
se6astian
this is the first official GSoC, student, mentor, community & team meeting
18:00
se6astian
we want to make it a weekly habbit from now on
18:01
se6astian
same time same place, every week
18:01
se6astian
for anyone not aware of this feature yet, this channel is being logged 24/7
18:01
se6astian
http://irc.apertus.org/
18:01
se6astian
you can read up on any past meeting/conversation that way easily
18:01
se6astian
note the timestamps are UTC
18:03
TofuLynx
Great! :D
18:03
Bertl
the basic idea behin the meetings is that the students and mentors can coordinate
18:03
supragya
ping!
18:03
Iti_
Weekly meeting sounds good :)
18:03
Bertl
and mainly the students can brag about their phantastic achievements during the last week
18:03
ArunM
:-)
18:03
se6astian
and see what the others have been up to
18:04
se6astian
after all we want us and you to also learn from each other
18:05
TofuLynx
Ok! :)
18:05
se6astian
to give everyone a chance to talk/report after another (instead of all at the same time - can get confusing) what worked well so far is that one person leads the meeting
18:05
se6astian
and everyone who wants to talk pms that person
18:05
TofuLynx
So, who will lead it?
18:05
supragya_2
joined the channel
18:05
se6astian
that person then asks every speaker one by one to have a go
18:06
RexOrCine
Present.
18:06
se6astian
for today that will be me, but it doesnt necesarily be me every time
18:06
se6astian
*need to be me
18:06
Iti_
Nice :)
18:07
se6astian
so please PM me now if you want to share a bit of what you worked on so far, next steps, current challenges
18:07
se6astian
while I collect PMs a questions from my side: Bertl whats the current situation with the IRC bouncers, ZNC?
18:08
Bertl
in the meantime, it looks to me like nobody (from the students) is actually using the IRC bouncer ...
18:08
se6astian
for students/mentors in particular
18:08
Bertl
it is working just fine and was tested by myself and BAndiT1983
18:08
se6astian
great
18:08
supragya
I am using it
18:08
Iti_
Bertl : Give me two days I'll set it. Currently all my time goes to final.
18:09
supragya
I just have other account connected using webirc... because i am dropping packets that's all
18:09
Bertl
supragya: okay, sorry, just saw your supragya_2 :)
18:09
Bertl
you might want to connect both to the bouncer then :)
18:10
supragya
I don't trust my Hexchat today...
18:10
supragya
so webirc ;)
18:10
ArunM
left the channel
18:10
Bertl
there are good alternatives to Hexchat, for example Pidgin (which is FOSS and available on all major platforms)
18:10
ArunM
joined the channel
18:11
supragya
It is something that I face during nighttime... no worries... hexchat is not at fault
18:11
Bertl
let me know (pm) if you have any problems with access to the IRC bouncer or need/want an account there
18:12
RexOrCine
Hexchat > Pidgin
18:12
supragya
sure :)
18:12
g3gg0_shell
joined the channel
18:13
se6astian
ok then Iti_ you were the first to PM me, please feel free to talk now about your progress so far, etc.
18:13
Iti_
Great!
18:13
Iti_
So, on April 27 Bertl gave me some tasks to complete. Here are the details of my approach and things that I have completed.
18:14
Iti_
May 3 - Understanding effective dynamic allocation in C for my histogram code as it cannot use pool allocator.
18:14
Iti_
May 6 - Calculating data size and required bandwidth, this gave me some required information.
18:14
Iti_
May 7 - Read and understood microZed architecture ( this was helpful in finding ways to optimize code specifically cache optimization)
18:15
Iti_
May 9 - Figuring out what data is used for which visualization (Bertl helped me in this as I wasn’t able to clearly understand some things )
18:15
Iti_
May 12 - Benefits from managing cache efficiently and how to do so (This took some time but I am now able to figure out what should I do in my code to minimize cache miss, thanks for alexML_ and Kjetil for further insight!
18:16
Iti_
May 13 - Figuring out how does mmap work and what area needs to be mapped.
18:16
Iti_
Further, I did tried to find out about the code that triggers a capture. And documented my approach here -> https://docs.google.com/document/d/1Qj1kC6bCDld9pIEHq_l2PoXKRXRwxOzxeDUrM2U5HAc/edit?usp=sharing
18:17
Iti_
and also about "How long does it takes to access an entire frame + figure out what access pattern and good and what are not
18:17
Iti_
"
18:17
Iti_
I still need feedback on those two tasks
18:18
Iti_
On, May 13 if I remember correctly Bertl asked me to write a small c program which would map only frame buffer and read from it
18:18
Iti_
This would help me in testing my code on beta (on which I have been provided root access )
18:19
Iti_
As I mentioned earlier, this week I was really busy with my final exams going on. So, I am still working on the code. This code should be ready till 24 at max
18:20
Iti_
After 23, I'll working on the assigned task and will update my status here
18:20
Iti_
That's all I guess :)
18:20
Bertl
great! thanks for the detailed update!
18:20
Iti_
You can see more links and stuff on my trello board
18:20
Iti_
Which I keep updating (Also I am always updating on irc)
18:20
se6astian
perfect, thanks
18:20
Iti_
https://trello.com/b/pSdCOkMt/untitled-board
18:21
Iti_
Thanks Bertl and se6astian!
18:21
TofuLynx
That's great!
18:21
se6astian
TofuLynx: you are next, please go ahead
18:21
TofuLynx
Iti_: If you need, I have a link for a pdf which explains a lot about low level functions such as mmap
18:22
TofuLynx
Ok!
18:22
Iti_
Thanks TofuLynx I did already read on that. But I'd like to see your pdf as well
18:24
TofuLynx
I started talking and discussing with my mentors on 25 April, BAndiT1983 and g3gg0. We had to decide about having a private room for exchanging info about the task and images, mainly when we aren't simultaneously online
18:25
TofuLynx
And, for timestamping my progress, we decided to use a google doc, but it hasnt been used and I am thinking about creating a Trello Board
18:26
TofuLynx
Before I started working with my task, BAndiT1983 wanted me to do some experiments with several classes on OpenCine and creating unit tests, so I could have some training and familiarize with the ideal workflow
18:27
TofuLynx
The unit tests, in my opinion, were the most important thing I learned in that time. They are so valuable and help a lot with bugs
18:28
TofuLynx
We also decided to start developing in dev branch of OpenCine, instead of incrementally inserting on master branch. So we kind of recovered the purpose of the dev branch.
18:29
TofuLynx
So, after this, I started working on my task: I have to implement a Bilinear Demosaic for OpenCine
18:30
TofuLynx
And I struggled a lot in the start, mainly because I approached the problem with a wrong vision. But BAndiT1983 helped me a lot in this regard and I finished the debayering!
18:30
TofuLynx
However, I found some issues with the OpenCine loading DNG images, which have to be resolved
18:31
TofuLynx
And that's all!
18:31
se6astian
great, thanks!
18:31
Bertl
excellent! tx!
18:32
se6astian
anyone else who wants to talk/share?
18:32
supragya
can I?
18:32
se6astian
please do!
18:33
supragya
Good evening everyone!
18:33
supragya
My project is to actually figure out a good way to get video streams out of Beta and give a good enough format for that
18:34
supragya
So, during the community bonding phase, g3gg0, BAndiT1983 and me looked at various formats that could be usable
18:34
supragya
while many formats showed promise... we wanted the format that we chose to be simple.. that AXIOM Beta can handle easily
18:35
supragya
This meant that we would ideally like well defined constant sized blocks/ files/ headers etc.
18:35
supragya
MLV seemed like a great choice.. because it is easy to encode and much of it's codebase could be taken up for our use... since it is C
18:36
supragya
comes with MLV is the benefit of MLV->CDNG encoder
18:36
supragya
So, we began with an idea in mind as follows:
18:37
supragya
AXIOM Beta connects to PC recorder using high speed USB3 to send frames and maybe another (perhaps Gbe) to send meta
18:37
supragya
Keeping AXIOM Beta end as black box (not knowing what it can do), we were to look into what performance was to be expected
18:37
supragya
if PC recorder is put to full throttle
18:38
supragya
An in memory emulation (on i7-4710HQ, DDR3 1333MHz) of MLV through this mechanism showed promise
18:38
supragya
and gave a result of over 7000 frames per second handling speed
18:39
supragya
when passing RAW12 as MLV blocks (in memory)
18:39
se6astian
wow, not bad
18:39
supragya
if we expect x10 or even x20 degradation in speed, using SSD RAID 0
18:39
Bertl
7000 4k frames?
18:39
supragya
we can still achieve over 300 frames per second RAW12 streams
18:40
supragya
Bertl: it's in memory...
18:40
supragya
so it's fast... 15GB/s
18:40
supragya
so yes, MLV feels like where we would head out to
18:40
supragya
nevertheless, the next leg of our discussion will be around HDR using PLR
18:40
TofuLynx
what is PLR?
18:41
supragya
and how to incorporate that in our MLV based system
18:41
supragya
as our emulation results showed promise that it could handle things on PC end very well,
18:41
Bertl
but 7000 FPS, 4k raw is 132Gigabyte/s no?
18:43
supragya
That was a max control.. and I highly doubt that number myself
18:43
supragya
I am more on what to expect..
18:43
g3gg0
well, its too early for numbers
18:43
supragya
the result is that 60fps... could be handled quite easily
18:43
supragya
as it is nearly 1 GBps
18:43
se6astian
TofuLynx: PLR (piecewise linear response) is a HDR (high dynamic range) mode of the image sensor
18:43
supragya
and 4xSSD RAID0 should be enough for that
18:44
se6astian
it allows increasing the dynamic range by selectively reducing highlight sensitivity with 2 kneepoints
18:44
supragya
as on AXIOM Beta, we need two 3GBps out ports if we are to go above like 150fps... but that's for later
18:44
g3gg0
i'd wait with numbers till the prototype is fully working. memcopy speeds are not telling much :)
18:45
supragya
yes...
18:45
supragya
also in memory control is very linient...
18:45
supragya
in terms of what to expect... we need a contol or RAID0 to test for benchmarks
18:45
se6astian
supragya: what are the considerations with PLR and the container? metadata for non-linear rawdata?
18:46
supragya
I have not looked into PLR myself... and find myself struggling in that domain
18:46
supragya
however, we have to look how to put that into MLV
18:46
alexML
supragya: I've looked into PLR and tried to calibrate it some time ago
18:46
alexML
(hi, btw)
18:47
supragya
the case can be summarised in two points:
18:47
g3gg0
we had this discussion and are not quite sure if the CDNG format would support it properly. well CDNG probably will, but we dont know about the tools that should process the CDNG
18:47
supragya
1. MLV is not handling non-linear raw data as of now... so would have to either change things to canon way... or change MLV subsytems accordingly
18:47
supragya
2. MLV-> CDNG convertor has to be changed accordingly too
18:48
supragya
hi alexML :)
18:49
supragya
In general, I feel we need to know the exact use cases and the representations surrounding this PLR, both me and g3gg0
18:49
se6astian
I can be of assistance for that topic, lets schedule a separate meeting
18:49
g3gg0
as a starting point we decided to potentially convert the PLR into linear raw when writing either MLV or CDNG
18:50
supragya
but I worry that we will lose valuable info on that part then
18:50
g3gg0
so the CDNG has linear raw for the start
18:50
Bertl
so use 16bit instead of the 12bit for example?
18:50
g3gg0
yep
18:51
g3gg0
both MLV and CDNG are capable of bpp > 12
18:51
supragya
I need to know how that mapping is to be done
18:51
Bertl
we still should keep the PLR info in metadata
18:52
Bertl
because it isn't completely map-able to linear
18:52
Bertl
anyway, as long as the information is not lost, it's fine for me
18:53
supragya
PLR poses problems for publisher (MLV-> CDNG)... we would really have to look at encoding once again
18:53
g3gg0
so PLR -> linear isnt perfectly mappable at all?
18:53
g3gg0
or do you need too much post processing for that?
18:54
Bertl
I don't think it can be perfectly mapped
18:54
supragya
:)
18:54
se6astian
an approximation should be possible though :)
18:54
Bertl
yes, definitely
18:54
se6astian
but again I think we should move this topic to a separate meeting as it would go beyond the scope of today
18:55
g3gg0
if "we" cannot map, i doubt some CDNG capable post processing tool will be :)
18:55
se6astian
supragya are you done ?
18:55
supragya
sure...
18:56
se6astian
many thanks!
18:56
se6astian
ArunM: your turn!
18:56
ArunM
Good Evening everyone
18:56
supragya
se6astian: just ping us all in (Bertl, you, g3gg0, me, BAndiT1983, alexML etc...) on our meet
18:56
TofuLynx
supragya:
18:56
supragya
time wise
18:56
se6astian
will do
18:56
TofuLynx
Oops
18:56
TofuLynx
wron input
18:56
TofuLynx
se6astian: I have a question
18:56
tjstyle
Hi all, are in the shield port have an I2S pinout?
18:57
ArunM
After thoroughly understanding the datasheet, I’ve already posted detailed architecture for my project CMV12000 emulation/simulation
18:57
tjstyle
oh, sorry. this is share time for progress, nevermind. just ignore my question.
18:57
TofuLynx
If, at the end of GSoC, I had a good documentation of what I did and my experience during GSoC, would you publish it on Apertus website?
18:57
ArunM
here it is again https://docs.google.com/document/d/1JIUxDIvjf85m0RCa2SDYGKCRv28YbKdpGoXXqD9tii8/edit#heading=h.wdn5c6ej19pv
18:57
se6astian
TofuLynx: definitely
18:57
TofuLynx
Ok! :)
18:57
ArunM
I have completely programmed two modules (ROW_BUFFER, SPI Interface) and currently in the middle of third (SERIALIZER)
18:58
ArunM
I'll upload clean code of all three modules on 25 May (Day after tomorrow is my last exam) and soon after that i’ll start working on the last (SEQUENCER).
18:58
ArunM
After that I am going to integrate all these modules with SEQUENCER and also write final test bench for the complete system
18:58
ArunM
Up until now everything is going as planned, if I were to believe my test benches ;-)
18:59
ArunM
but i think problems may arise as I start programming SEQUENCER.
18:59
ArunM
That i can inform you on IRC itself.
18:59
ArunM
Thats all
19:00
Bertl
great! is the code online somewhere?
19:01
ArunM
its not organised, okay i'll upload it tommorow only
19:01
ArunM
in watever state it is now
19:01
Bertl
make sure to have copyright notice and (FOSS) license on the files
19:01
ArunM
its functioning thats for sure,i'll clean it b4 25 thats for sure
19:02
ArunM
okay
19:02
Bertl
no problem, was just curious
19:02
Bertl
i.e. it's fine if you need some time to clean it up
19:03
se6astian
great, many thanks for sharing!
19:04
ArunM
:-)
19:04
ArunM
:)
19:04
se6astian
anyone else want to share/say/discuss anything?
19:04
se6astian
otherwise I would conclude todays meeting
19:04
Bertl
maybe just as information for the students:
19:05
Bertl
we are currently preparing for the upcoming Maker Faire in Berlin
19:05
se6astian
it will happen on the next weekend
19:05
Iti_
Great! :D
19:05
supragya
se6astian: Where are our other GSoC fellows? just curious!
19:06
Bertl
so we will be a little more busy than usual and kind of away over the weekend (friday - monday)
19:06
Iti_
So, do we have meeting next monday?
19:06
Bertl
yes, we should be back till then
19:06
Iti_
Okay, cool!
19:06
se6astian
supragya: we will try to get in touch with them
19:07
Bertl
rahul- seems to be 'virtually' present but not around right now
19:09
se6astian
ok, meeting concluded!
19:09
supragya
have a good night everyone! :)
19:09
Bertl
great! thanks to everyone!
19:09
se6astian
feel free to stick around and discuss/chat of course
19:10
supragya
still here
19:10
g3gg0
good night!
19:10
Iti_
Will be going now, have exam on 23 :)
19:10
supragya
good night g3gg0
19:10
ArunM
left the channel
19:10
Iti_
Good night everyone!
19:10
se6astian
all the best!
19:10
g3gg0
(have to leave for a hour)
19:10
supragya
gut nacht Iti_
19:10
supragya
(am I correct ?) :)
19:11
ArunM
joined the channel
19:11
se6astian
almost! "gute nacht" :)
19:11
Iti_
Thanks again Bertl, se6astian,g3gg0, alexML and BAndiT1983
19:11
Iti_
supragya : right xD
19:11
se6astian
you are welcome!
19:12
se6astian
supragya if you want we can chat a bit about PLR now
19:12
supragya
sure se6astian
19:13
Iti_
left the channel
19:13
RexOrCine
Well done everyone. Thanks for the updates.
19:14
TofuLynx
Loved it!
19:14
supragya
se6astian: could you explain me the idea behind PLR... in contrast to other methods of HDR
19:14
se6astian
sure
19:15
se6astian
traditionally HDR is collected from exposure time bracketing (collecting images with different exposure times)
19:15
se6astian
this means you have different images to fuse together
19:15
supragya
yes
19:16
se6astian
with motion this can lead to problems as the motion continues with each bracketed image
19:16
se6astian
leading to artifacts, issues
19:16
se6astian
and a lot of data in general
19:17
se6astian
which makes the process to fuse the HDR image together time/resource intensive and the resulting HDR image large in filesize
19:17
supragya
seen such artifacts myself... takes a toll on sharpness at very least
19:18
se6astian
another HDR mode the image sensor supports is different exposure times for even/odd coloumns (or was it lines, cant remember)
19:18
se6astian
which basically gives you two bracketed images, both reduced in horizontal or vertical resolution
19:18
supragya
lines... iirc
19:18
se6astian
right
19:18
supragya
that's dual expo
19:19
se6astian
correct
19:19
supragya
if expo is unchanged and ISO is varied
19:19
supragya
that's dual ISO... mlv thing
19:19
se6astian
how you process the result is up to you, the image is still a 12 bit 4096x3072 image from the image sensor
19:20
tjstyle
Bertl: There is available I2S port in Shield section? or any interface protocol can be made in FPGA side?
19:20
tjstyle
I just see couples of LED and LVDS pinout
19:20
se6astian
now PLR is interesting because the fusing of different exposures already happens on the image sensor level
19:21
Bertl
tjstyle: basically all GPIOs on the shields connect to an FPGA
19:21
se6astian
the result is one image 12bit 4096x3072 but you can select 1 or 2 kneepoints for the response curve
19:21
Bertl
tjstyle: so I2S can be implemented but is not present yet
19:21
se6astian
and for each kneepoint you can set voltage level and turn-off time IIRC from the datasheet
19:22
se6astian
so you can basically define X/Y position of each kneepoint in the resulting response curve
19:22
supragya
is kneepoint something like keyframes in timeline (analogy)
19:22
Bertl
on the technical side what's happening is the following:
19:22
supragya
and response curve is a bezier?
19:22
Bertl
the photosites are charged to an initial voltage
19:23
se6astian
supragya: yes you can see it that way
19:23
tjstyle
Ok then, need to find a codec chip or separate ADC & DAC chip that fit on Shield dimension.
19:23
se6astian
but the response curve is in general linear
19:23
se6astian
or almost linear
19:23
se6astian
and the kneepoint defines where two linear sections meet
19:23
Bertl
se6astian: during the first 'exposure' the discharge (by light) is limited to a certain voltag V1
19:24
se6astian
http://www.nocturncamera.com/image/hrd2.png
19:24
Bertl
then after T1, the voltage is lowered to V2
19:24
Bertl
and for another interval (T2) the exposure is limited to this voltag
19:24
Bertl
*voltage
19:24
se6astian
Bertls explanations are visualized here: http://www.nocturncamera.com/image/hrd.png
19:25
Bertl
finally the voltage limit is removed and the last interval can expose (discharge) the photosites in T3
19:25
TofuLynx
BAndiT1983: Are you online? Can I add you to the trello board?
19:26
Bertl
supragya: if you think about it, this results in a piecewise linear exposure as long as there are no sudden changes
19:27
supragya
you are breaking a straight line to span over higher HDR
19:27
Bertl
I'd guess that it would give strange results with a really short flash which isn't perfectly timed
19:27
supragya
but then here are a few issues... are we losing details in middle?
19:28
supragya
I mean... as there is a bound on voltage... during this bound... you are flat out leaving the details...
19:28
Bertl
it is always a tradeoff because 12 bits are 12 bits whatever you do :)
19:28
se6astian
as we are redistributing the 12 bit we have available over different areas of latitude we are indeed loosing information in some areas
19:28
alexML
roughly speaking, 3 overlapped exposures (with 3 different exposure times) encoded in the same image
19:29
alexML
so, indeed, in highlights the exposure time is shorter
19:29
supragya
is it always 3?
19:29
alexML
or 2
19:29
se6astian
you can have 1 or 2 kneepoints
19:29
se6astian
so 1, 2 or 3 exposures
19:30
supragya
i seem to get a hold of it.. a little bit
19:30
se6astian
https://www.youtube.com/watch?v=jF68AJ14Uu4
19:30
supragya
i was wondering of artifacts in such scenario
19:31
se6astian
we still need to discover those
19:32
se6astian
how they look and when they occur
19:32
supragya
is it always a global shutter?
19:32
se6astian
yes
19:32
ArunM
left the channel
19:33
supragya
I mean even if sensors are swapped
19:33
se6astian
well the CMV12000 is global shutter only
19:33
Bertl
other sensors will have completely different features
19:33
se6astian
if we use a different sensor, everything is different
19:33
BAndiT1983
TofuLynx: yep, am online, was just doing household stuff
19:33
se6astian
it might not even support PLR
19:34
BAndiT1983
was there the question about the pattern already? is it always fixed for the CMV12000 or does it change from sensor to sensor??
19:35
supragya
se6astian: with what you helped me understand... I guess, with a few tweaks PLR could be incorporated
19:35
supragya
as always -> two ways
19:35
supragya
12 bit -> 16 bit could help... to encode all (we would need that in CDNG finally)
19:35
supragya
a few ways would be:
19:35
se6astian
BAndiT1983: the colorfilter array is the same from sensor to sensor
19:36
supragya
1. to encode PLR info in meta stream and send it over
19:36
supragya
or 2. to map 12bit -> 16bit in camera which is costly and inefficient
19:37
se6astian
I also think the best way is to save raw data and metadata (your 1.) and decide in post how to utilize it
19:37
supragya
se6astian: considering the use case of Beta, how likely is that a user would need to swap a sensor for other one?
19:38
supragya
it is doable.. but really how many would like to do it, any idea
19:38
se6astian
same model/brand or completely different sensor?
19:38
supragya
completely different featureset
19:38
se6astian
well currently the CMV12000 is still THE best one available
19:38
se6astian
but who knows what will become available in the future
19:39
se6astian
the hardware is designed to be modular so the foundation for another sensor is in place
19:39
supragya
because incorporating PLR such as this in system would only bolster use of CMV12k more... and other sensors will have to use.. a different streaming system and a differenct version of recorder maybe
19:39
se6astian
correct
19:40
intrac_
left the channel
19:40
supragya
I have a few queries regarding how to emulate this system
19:41
se6astian
in any case, the concept of saving raw image data and all metadata the sensor provides works with any sensor
19:41
se6astian
of course the kind of metadata might vary
19:41
supragya
for correct benchmarks on PC recoder + AXIOM Beta, I may need as I said... atleast SSD RAID0 to get the capabilities
19:42
supragya
if that is a necessity obviously
19:44
se6astian
lets see what we can organize
19:44
supragya
btw, what kind of meta format should I expect for PLR
19:44
se6astian
another topic for PLR but also linear raw data is a viewfinder LUT
19:45
supragya
[linear raw data is a viewfinder LUT] ?
19:45
TofuLynx
BAndiT1983: Can you send me your email via the chat at lab?
19:46
se6astian
please check the cmv12000 datasheet about the PLR parameters
19:46
se6astian
bitdepths, etc.
19:46
supragya
thanks for help se6astian
19:46
se6astian
viewfinders normally operate on 8 bit per channel color images
19:47
se6astian
so 24 bit RGB
19:47
se6astian
generated from 12 bit raw
19:48
supragya
why are we concerned about viewfinder?
19:48
se6astian
problem is that a 12 bit image converted to 8 bit just by using the MSB looks very contrasty
19:48
supragya
for the same reason as what we save in cdng?
19:48
se6astian
so in the beta we apply a gamma curve
19:48
se6astian
to make the image less contrasty
19:48
se6astian
it would be helpful if the raw format could also store this gamma curve somehow
19:49
supragya
well... what's a gama curve
19:49
supragya
gamma
19:49
supragya
a mapping function?
19:50
supragya
like a CURVES adjustment?
19:51
se6astian
exactly
19:51
se6astian
off for dinner for a bit
19:51
se6astian
will be back soon
19:51
supragya
per channel or global
19:51
se6astian
global
19:52
supragya
a bezier?
19:54
g3gg0
re
19:54
g3gg0_shell
left the channel
19:55
supragya
hi g3gg0
19:55
g3gg0
hi :)
19:55
alexML
supragya: for PLR, to get good results, I'm afraid one has to calibrate a curve for every single pixel
19:56
alexML
for preview you may get away with a global curve though
19:56
supragya
se6astian: (when you get back obv): if I set the gamma curve parameters, am I going to change these during "on the fly" recording?
19:57
supragya
alexML: is that so? the basis of this is the imperfect nature of pixel in relation with others....
19:57
supragya
but that should be taken care during the caliberations right?
19:58
supragya
or am I missing some reason... why would every pixel need a curve caliberation of it's own
19:58
supragya
and how do you do that manually?
19:58
BAndiT1983
TofuLynx: done
19:58
supragya
BAndiT1983: hi, how are you
19:59
BAndiT1983
hi supragya, fine, and you?
19:59
supragya
figuring things out mostly
19:59
BAndiT1983
why are there multiple accounts of yours?
19:59
supragya
was losing packets today
19:59
BAndiT1983
seen the logs
19:59
Bertl
off for now ... bbl
20:00
supragya
g3gg0: have you seen the logs regarding PLR?
20:00
Bertl
changed nick to: Bertl_oO
20:00
BAndiT1983
supragya, every sensel has some offset
20:00
BAndiT1983
depending on temperature and other factors
20:01
BAndiT1983
maybe also on how clean the micro-lenses are
20:01
g3gg0
just reading
20:01
supragya
that is taken care of by caliberations (dark frames) right
20:01
BAndiT1983
dark frame is for noise, iirc
20:01
TofuLynx
Ok BAndiT1983, done
20:01
TofuLynx
You should be able to access my trello board
20:01
alexML
with PLR it's not just a single offset, or just an offset + gain
20:02
alexML
the transition between the segments may differ, too
20:03
supragya
offset... regarding voltage/ readouts ? is it something that is corrected simply by [actualvalue - offset] ?
20:03
supragya
or more complicated?
20:03
BAndiT1983
probably curve
20:03
g3gg0
that has to be done before the CDNG conversion then
20:03
alexML
feel free to try; I've got some gigabytes of reference frames to interpret, but don't have a working PoC yet
20:03
supragya
I am having trouble understanding this segment to be honest
20:04
TofuLynx
You will eventually understand it! :)
20:04
supragya
g3gg0: seems like it
20:04
g3gg0
any slight variation in the knee point of a pixel would cause serious noise artefacts?
20:04
TofuLynx
I am going to dinner now, See you!
20:04
supragya
g3gg0: I guess not
20:05
supragya
you will just loose details at the most I guess
20:05
g3gg0
for this reason does every single pixel need a proper calibration?
20:05
alexML
yeah, unfortunately not just random unbiased noise
20:05
g3gg0
maybe some patterns etc, but not deterministic?
20:06
g3gg0
if thats so, you would have to shoot a rising-exposure scene for the sensor to calibrate?
20:06
alexML
I'm pretty sure most of it is deterministic, just hard to calibrate with a global curve
20:06
alexML
I've captured a sunset timelapse without lens
20:07
alexML
from overexposed to nearly pitch black
20:07
se6astian
back
20:08
g3gg0
hmm sounds the best way is to do X * Y kalman estimators :D
20:08
g3gg0
"best"
20:08
supragya
* just lost it completely now :D
20:08
g3gg0
@supragya: the point was/is: that PLR shows knee points, right?
20:09
supragya
yes
20:09
se6astian
so to summarize: the applied gamma curve is just a remapping to make the viewfinder image more useful, it would make sense though to save it with the metadata so the raw data can be interpreted to look similar as what was on the viewfinder (even if much more data is available "behind the scenes")
20:09
g3gg0
so a sensel's value rises non-linear
20:09
supragya
yes
20:09
g3gg0
if a scene continuously gets brighter, the sensel's values will raise at three different rates
20:10
supragya
yes
20:10
g3gg0
the first derivate would have a jump
20:10
supragya
yes
20:10
se6astian
alexML: already did some quite accurate estimations of the response curve: https://wiki.apertus.org/index.php/PLR
20:11
g3gg0
if that knee point has a small offset and you apply the reversing algorithm, you will get strange effects
20:11
supragya
as in?
20:11
g3gg0
and as alex said, there are offsets/drifts/whatever
20:11
g3gg0
some pixels/rows/columns/whatever patterns darker/brighter than others
20:12
g3gg0
just think of e.g. a vertical darker line due to that
20:12
supragya
is this because of pixels getting excited around a kneepoint extrapolating the effect?
20:12
g3gg0
usually you might think those 1-value-offsets are no problem
20:13
supragya
more like enhancing the effect
20:13
BAndiT1983
wasn't there something about homogenous lightning in the scene?
20:13
g3gg0
but when there are regular patterns of such, people will notice
20:13
BAndiT1983
*sorry, not scene, sphere
20:13
se6astian
yes we have an integrating sphere for such tests/calibrations
20:14
g3gg0
if you know the exact pattern, you can compensate this afterwards. but having a "correct" PLR-curve for every single pixel, will for sure improve the image quality
20:14
g3gg0
(its always better to prevent errors than to compensate)
20:14
g3gg0
prevent = per-pixel-plr-curve
20:14
g3gg0
i hope i understood correctly, alex?
20:15
alexML
yep
20:15
supragya
so, this per pixel PLR is one big chunk of data that is to be saved per recoding/ per camera?
20:15
BAndiT1983
hm, sounds like a task for LUT to me
20:15
g3gg0
no LUT
20:15
g3gg0
as it is per-pixel :D
20:16
g3gg0
2048 x 1088 x 2^12
20:16
BAndiT1983
3d lut should be suitable
20:16
g3gg0
9GiB of LUT
20:16
se6astian
per image sensor, per PLR settings most likely
20:16
BAndiT1983
as you don't need the full range, it could be compressed in linear areas
20:16
g3gg0
if you use interpolation less, ok
20:17
g3gg0
its very expensive when processing then
20:17
supragya
can this thing... PLR table per pixel be changed per recording/ is constant across recordings for is some per image sensor thing
20:18
g3gg0
@alexML
20:18
supragya
because if it is per sensor thing, it can be offleaded once and then used later on... and not stored with every stream (video)
20:18
se6astian
(9:16:54 PM) sebastian: per image sensor, per PLR settings most likely
20:18
g3gg0
guess it drifts with temperature. but maybe not too much
20:18
supragya
*offloaded
20:19
g3gg0
ok then it can considered to be constant for a sensor/setting pair
20:19
se6astian
it can pretty likely be calibrated once and stored for later use in postprocessing
20:20
supragya
g3gg0: in that case, this is to be modified for in MLV->CDNG encoder?
20:20
supragya
the PLR settings can be given along with MLV to encode a CDNG then
20:20
supragya
and the resulting CDNG can be 16bit maybe?
20:20
g3gg0
i'd place it there for now, yeah
20:21
supragya
the gamma curves change frequently, se6astian ? or are they as constant as PLR?
20:21
se6astian
constant
20:21
supragya
then that can be offloaded too..
20:21
slikdigit
joined the channel
20:22
se6astian
or rather there might be 2-3 presets to choose from but each of them is constant
20:22
BAndiT1983
dng has linearization table for compression
20:22
BAndiT1983
otherwise the files tend to become rather big
20:22
BAndiT1983
so most are 12 or 14 bit
20:22
supragya
are we considering file sizes too now?
20:22
BAndiT1983
it's the standard way, you cannot omit it just like thatz
20:23
BAndiT1983
*that
20:23
supragya
gamma curves are also per pixel?
20:23
g3gg0
in the DNG we expect linearized raw
20:25
supragya
[gamma curves are also per pixel] -> silly question I guess :)
20:25
BAndiT1983
https://blogs.mathworks.com/steve/2011/03/08/tips-for-reading-a-camera-raw-file-into-matlab/
20:25
supragya
it should be a global thing i suppose
20:25
se6astian
correct
20:25
se6astian
its actually a single value for the entire image, like gamma "0.6"
20:26
se6astian
off for a bit now
20:26
supragya
gamma "0.6" would map 12bits to 8bit how?
20:26
alexML
https://rcsumner.net/raw_guide/RAWguide.pdf (next step after reading Bandit's link)
20:26
BAndiT1983
dng specs say something about gamma curve
20:27
alexML
look at page 13
20:27
BAndiT1983
supragya, first is the processing line done, before you convert it down, so linearize before downscaling the values
20:28
supragya
got it BAndiT1983
20:29
supragya
I would be leaving for now
20:29
g3gg0
okay, goodnight then
20:30
g3gg0
or whatever daytime it is where you are right now :D
20:30
supragya
thanks everyone. have a great night ahead
20:30
supragya
Its 01:00 AM here
20:30
g3gg0
ok, then goodnight ;)
20:35
supragya_2
left the channel
20:44
BAndiT1983
TofuLynx: do you update your OC fork from time to time?
21:03
g3gg0
left the channel
21:09
BAndiT1983
left the channel
21:35
TofuLynx
left the channel
21:50
RexOrCine
changed nick to: RexOrCine|away
22:06
se6astian
changed nick to: se6astian|away
22:08
slikdigit_
joined the channel
22:09
slikdigit
left the channel
22:09
slikdigit_
changed nick to: slikdigit
22:48
TofuLynx
joined the channel
22:54
TofuLynx
Bertl_oO: too occupied in Operation Octopus?
22:57
TofuLynx
Just saying that the pattern issues i have been facing were OpenCine's fault and I have solved it. Now the images appear perfect :D
23:18
Bertl_oO
TofuLynx: excellent!
23:20
slikdigit
left the channel
23:23
TofuLynx
Good Night Folks!
23:23
TofuLynx
left the channel
00:11
intrac
joined the channel
00:21
ymc98_1
left the channel
00:22
ymc98_1
joined the channel
00:39
intrac
left the channel