Current Server Time: 19:31 (Central Europe)

#apertus IRC Channel Logs

2015/12/10

Timezone: UTC


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