| 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
|