Current Server Time: 10:03 (Central Europe)

#apertus IRC Channel Logs

2015/12/10

Timezone: UTC


23:16
slikdigit_
left the channel
23:54
slikdigit_
joined the channel
00:28
Bertl_zZ
changed nick to: Bertl
00:28
Bertl
back now ...
00:54
mithro
left the channel
00:56
mithro
joined the channel
02:08
slikdigit_
left the channel
06:36
cbohnens|away
changed nick to: cbohnens
06:41
se6astian|away
changed nick to: se6astian
06:41
se6astian
good morning
06:41
se6astian
hi cbohnens
07:30
mnicoletti
left the channel
07:37
cbohnens
changed nick to: cbohnens|away
08:10
LordVan
joined the channel
08:18
cbohnens|away
changed nick to: cbohnens
08:23
tezburma
joined the channel
08:58
Bertl
off to bed now ... have a good one!
08:58
Bertl
changed nick to: Bertl_zZ
10:15
tezburma
left the channel
10:28
tezburma
joined the channel
14:08
baldand
left the channel
14:12
LordVan
left the channel
14:36
tezburma
left the channel
14:41
se6astian
we captured snapshots of three color charts today with the Beta: http://files.apertus.org/AXIOM-Beta/snapshots/colorcharts/
14:59
aombk2
what is this raw12 file? magic lantern spec or something?
15:01
aombk2
nevermind, found it in the wiki
15:26
se6astian
good :)
15:26
se6astian
gotta go
15:26
se6astian
changed nick to: se6astian|away
15:44
alexML
aombk2: you can find a converter for raw12 files here: https://github.com/apertus-open-source-cinema/misc-tools-utilities
16:06
Bertl_zZ
changed nick to: Bertl
16:06
Bertl
morning folks!
17:13
se6astian|away
changed nick to: se6astian
17:34
comradekingu
left the channel
17:35
cbohnens
changed nick to: cbohnens|away
17:55
aombk2
thanks alexML
17:55
slikdigit
joined the channel
17:56
aombk2
alexML, is this the good old ML raw2dng or a new implementation?
17:57
se6astian
slightly altered for the Beta
17:58
se6astian
changed nick to: se6astian|away
18:48
alexML
some HDMI results, for Bertl and se6astian|away : https://www.dropbox.com/sh/euttc3m1fnpqvml/AACSTFaBOAlE2VGLSW96_MpYa?dl=0
18:48
alexML
Bertl: if you like this bit order, you may try it on the camera (spec is in readme)
19:04
Bertl
m1 will work, but you will get a relatively high error rate on the low order bits (which is probably fine)
19:05
Bertl
o2 I don't see working well, because of the sharp changes the overflow will generate
19:05
alexML
m1 is your encoding
19:06
alexML
yeah, o2 is the solution found by the optimizer - indeed, it looks really weird, but at least works better on simulation
19:06
alexML
(sure, the simulation probably doesn't reflect reality, since I didn't do any compression)
19:06
Bertl
what exactly does the simulation contain?
19:06
Bertl
ah yes, that's the problem
19:06
alexML
it's described in the readme
19:07
Bertl
you should simply compress the image with a jpeg codec
19:07
alexML
I can upload the code too, if you want to play with it (octave)
19:07
Bertl
then uncompress it again before data recovery
19:07
alexML
yes, that may work (though a bit slow)
19:07
Bertl
this will give you a way better estimation on the error rate
19:08
Bertl
naturally if you can assume the data is not compressed, you can choose any bitorder and it will be perfect
19:08
alexML
on my HDMI experiment on this, on Canon, the data was uncompressed
19:08
alexML
10-bit uncompressed, but last 2 bits were 0
19:08
Bertl
(note that the RGB -> YUV -> RGB conversion is a compression as well)
19:08
alexML
so, I think it was 8-bit 422
19:09
alexML
of course, and this weird pattern appears to resist to RGB->YUV->RGB fairly well (that's what I'm showing in the images)
19:09
Bertl
I think with compression we have to be tricky about the changes over the image
19:10
Bertl
i.e. avoid sharp edges where there are none in the original image
19:11
Bertl
we might also work on the YUV space and for now convert it to RGB (later directly transfer it)
19:12
Bertl
visually lossless compression has two effects we need to combat
19:13
Bertl
first, values are not exactly the same, they are "close"
19:13
Bertl
and secondly, huge changes will be "approximated" at best
19:14
Bertl
so we need to avoid discontinuities and we need to avoid putting relevant data into the lower bits
19:15
Bertl
without "raw" recording, we won't be able to fit all the data
19:17
Bertl
i.e. the compression has a certain bandwidth, and we won't be able to "encode" more data than this
19:29
alexML
sure - I'm just looking for an encoding that would minimize the differences between the recovered raw and the original
19:29
alexML
(and since I don't know where to start, I run a genetic algorithm to figure it out)
19:30
Bertl
fair enough :)
19:31
alexML
I'll try to simulate jpeg compression in this process as well
19:31
alexML
meanwhile, I found a bug in the simulation (while trying to compress)
19:32
alexML
I found out that I was only simulating the HDMI processing for one frame
19:32
alexML
the other frame passed uncompressed on the other side :P
19:32
alexML
so, the results are quite bogus
19:32
Bertl
okay
19:33
alexML
what's weird is that, even after fixing this, the optimizer still finds a similar solution
19:33
alexML
high bits on one side, low bits on the other
21:39
intracube
left the channel
22:53
alexML
ok, so I'm getting nowhere with bit shuffling, so I propose a different approach
22:53
alexML
same link: https://www.dropbox.com/sh/euttc3m1fnpqvml/AACSTFaBOAlE2VGLSW96_MpYa?dl=0