Current Server Time: 23:32 (Central Europe)

#apertus IRC Channel Logs

2016/02/26

Timezone: UTC


01:17
John-K
left the channel
02:15
Jumboberg
joined the channel
06:12
Jumboberg
left the channel
06:13
jucar
joined the channel
06:28
alexML
left the channel
06:28
alexML
joined the channel
06:43
jucar
left the channel
07:13
renearts
joined the channel
07:41
Bertl_zZ
changed nick to: Bertl
07:41
Bertl
morning folks!
08:39
Guillaume_chooks
joined the channel
09:25
Bertl
off for now ... bbl
09:25
Bertl
changed nick to: Bertl_oO
09:45
arpu
joined the channel
10:44
sb0
joined the channel
11:02
alexML
I have a proposal regarding calibration files for postprocessing the raw images, to be reviewed: https://wiki.apertus.org/index.php/Calibration_files
11:02
alexML
(don't have a working implementation yet)
11:03
alexML
cc se6astian|away Bertl_oO irieger troy_s intracube_afk (others interested?)
11:03
alexML
it's basically about directory structure (how to organize the files, where to store them)
11:11
danieel
i would drop axiombeta, and add a file extension which implies the data format
11:12
danieel
if the data is of low entropy, then just pack the multi-file structure into one .tgz
11:13
danieel
i am also for having a sensor-sn / sensor-board sn
11:25
alexML
well, the files have their own extension (pgm, spi1d, whatever)
11:26
alexML
they should compress pretty well, but that means more work when loading them
11:27
alexML
if we drop the "axiombeta" part, the "calibration" becomes fairly generic and might not be obvious what it is, what program uses that...
12:33
danieel
well, then something as ~/.config/axiom/beta/calib/FILESHERE
12:40
alexML
sounds good, but it retains the "axiombeta" part (with some slashes added) :P
13:27
pusle
left the channel
13:30
pusle
joined the channel
15:58
Bertl_oO
changed nick to: Bertl
15:58
Bertl
back now ...
16:05
renearts
left the channel
16:15
mgielda|`
joined the channel
16:15
mnicoletti|away
joined the channel
16:15
mnicoletti
left the channel
16:15
mnicoletti|away
changed nick to: mnicoletti
16:18
FergusL___
joined the channel
16:18
jus_
joined the channel
16:22
jus
left the channel
16:22
irieger
left the channel
16:22
FergusL
left the channel
16:22
mgielda|away
left the channel
16:22
danieel
i think that part could be picked up by the OS of the camera, maybe i did not get the idea - are those structures stored in-camera or off-camera, in the post?
16:22
irieger
joined the channel
16:26
se6astian|away
changed nick to: se6astian
16:27
se6astian
good evening
16:34
se6astian
alexML: very interesting, when you talk about location of stored files we are talking about inside or outside the cameras own filesystem?
16:47
alexML
on the PC
16:48
aombk
joined the channel
16:49
alexML
though, the directory structure could be reused for in-camera calibration files as well (maybe without the "up N levels" trick)
16:58
Bertl
what's the purpose of the ./ ../ ../../ ?
17:00
danieel
i assume autodetection, store the calib one and make it valid for a set of reels in the directories below
17:00
danieel
*once
17:02
alexML
yes, so you can have a directory for each camera (say cam1 and cam2), inside it you would have a calibration dir, and then you can organize your files in whatever directory structure you want, but inside cam1/cam2
17:02
alexML
so the raw processor would search for calibration files up one level until it finds something
17:03
alexML
that's what dcraw does for the .badpixels file
17:03
Bertl
okay
17:03
alexML
alternative would be to identify camera/sensor by serial numbers
17:03
John-K
joined the channel
17:03
Bertl
SFEs will have a unique ID
17:04
alexML
and store calibrations in a single place (maybe ~/.config)
17:06
alexML
we should use it as metadata, then
17:07
danieel
that is fine for stills, you can embed it. But if you do record the data externally, it would need to be still paired by hand
17:07
Bertl
yes, I think we should store the entire setup (i.e. hardware and software) in metadata
17:08
Bertl
we might be able to do a metadata frame for external recording (think QR code)
17:09
Bertl
which can easily be etracted and analyzed in post
17:09
danieel
good idea, reminds me a bit of the LTC on first lines for some SVHS stuff :)
17:10
danieel
if we shoot wider than 16:9, there can be per-frame metadata as well
17:10
danieel
*VITC
17:11
Bertl
anyway, I think I'll take a nap now, still quite tired from the fair ...
17:11
Bertl
have fun!
17:11
Bertl
changed nick to: Bertl_zZ
17:48
intracube_afk
changed nick to: intracube
17:48
intracube
changed nick to: intracube_afk
18:03
sb0
left the channel
18:18
Guillaume_chooks
left the channel
18:35
John-K
left the channel
18:35
John-K_
joined the channel
18:37
aombk2
joined the channel
18:38
aombk
left the channel
18:41
John-K_
left the channel
19:04
jucar
joined the channel
19:40
aombk2
i have a question. what is the most size efficient way to compress a video that contains alpha channel?
20:08
John-K
joined the channel
20:09
John-K_
joined the channel
20:09
John-K
left the channel
20:41
se6astian
aombk2: quite a tricky question, most normal consumer formats do not support an alpha channel and the transparency would not work properly anymore on a strongly compressed stream
20:41
se6astian
so those requirements kind of cancel each other out
20:43
se6astian
off to bed
20:43
se6astian
good night
20:43
se6astian
changed nick to: se6astian|away
20:50
intracube_afk
left the channel
20:51
intracube
joined the channel
20:59
John-K_
left the channel
21:28
John-K
joined the channel
21:42
intracube
alexML: is this directory structure for an interim processing setup (to be done in post)
21:43
intracube
before (at least some of it) being moved onto the camera FPGA?
22:09
alexML
yep
22:11
alexML
and when some of it will be moved to FPGA, we can probably reuse the directory structure in the camera filesystem
22:24
intracube
yep
22:25
intracube
I was suddenly worried that I missed a discussion that the processing would only be done in post :)
22:25
intracube
and some version control system for the files?