#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

Hi

Hi supragya

Yeah

well, you could generate one by running the emulator at your end :)

Okay, will y

Will usr your generator then

will need to join those

best is to clone locally and run ./setup.sh

axiom.mlv

Okay will do this tonight

according to proposal?

Evaluation period​: Analysis phase ends: report findings and suitability of each

This is evaluation 2:

encode/decode the decided video container format.

improvements can be made.

okay... where do you say we should work on then?

Workflow yeah

well, buffers are a problem for sure yes

Mlvfs already does this step

Hi

if current recorder is able to encode mlv, and mlv2cdng can be done, it only needs modification for example when PLR or dualexpo is added to the stream

Okay

Person A goes, fires up the axiom and the recorder, and records the mlv

1st step in post production is mlv->CDNG and then everything else

*on-set

like a hot backup?

backup is optional but good practice indeed

and how to make sure that we write to disk as fast as the stream

you cannot write as fast as the stream as the disk also needs some time

and there are some components in betwtween whcih also require their time

BAndiT1983, then over time ram will fill up and how do we act on bufferoverflows etc?

stream is pushed to us, more like UDP that's the problem. Take it or leave it thing

you get data in ram, when some amount is there, then write to disk, plain and simple

btw, is there anything we are not clear about how the system should work?

We talked about that the system shall convert to cdng while recording and later

nope, not while recording, it can leave to lost data on-set

record mlv and nothing else, otherwise there are too many risks of lost data and wasted money

I am sure, I have been living under this assumption (that BAndiT1983 put forth) since the day we had chat on how system should look like

Then its fine

also had trouble with raw2dng lately and it has to be reviewe after long time

Then look into converting the mlv to cdng using e.g. mlvfs

It already produces proper cdng and allows either on-demand conversion (quite effortless)

maybe because it is already giving correct cdng

just wondering about performance of it

however, since on demand can be done

If we can pass through raw12 plr wothiut conversion it should be very inexpensive

Sure, could be ported to OC

looked into dng specific methods on bitbucket (not sure if they are mlv2cdng) but, much of it is canon specific details, am i wrong?

Most likely there is even more

can you point me to a starting point?

just to be clear, I will try to take FUSE out for our specific system.

FUSE complicates a little (for starting point)

You mean for camera emulation? Yeah

BAndiT1983, did not get you... are you thinking about FUSE for mlv2dng?

it was the idea of g3gg0, my point was, that you should access the MLV data directly first and try to convert it

Provides already proper mlv parsing, preview code and cdng generation

*grammar

According to danieel, cdng does 1:1 accept our payload and adding a tag for the linearization table should be enough

Id say thats a week of effort

Then we have one possible workflow which allows CDNG being produced with reasonable effort

I am sorry, but what does linearisation table do exactly?

are we not going from 12bit to 12bit raw from mlv to cdng

i'Ve posted a paper on that before

BAndiT1983, on linearisation?

same paper is linked on the page

page 7 in the pdf is about linearization

We had two options: convert raw12-plr to raw16-lin during conversion

The other one, discussed yesterday, was to simply pass the raw12-plr

i have the 12bit bit order snippet, can I paste?

A) convert by hand to raw16-lin using probably a per-pixel-lut as alex proposed

Who votes for which option? I prefer B) if it is possible

off for now ... bbl

C) convert to 16bit in per pixel and apply a global lut/curve to reduce data to 12 bit

Hehe

hard to tell if the sensor is that bad in doing plr, that it needs per pixel correction

C) is like A) ;)

Yep. Preferrable

or some other things?

what about dark frame?

either burn-in into raw data, or match with the reel number / camera model

Tool support is quite bad iirc

yes, i can remember the still tools have dark frame / flat field correction which is matched by that

if you burn this in, then there is a question wheter to mask and interpolate the hot pixels :)

implement conversion first, as the discussion is drifting off a lot

because the bad pixel list feature is also a problematic feature of the tools

these things could have a configuration option, generalized as: ignore/reference/embed/apply , for the various levels of processing

se6astian, ping!

or scilab?

okay!

on a real world plr shot or artificially generated one? so that the sensor "shittiness" can be adjusted

real world plr would be good to test experimentally

is it in the scope of gsoc?

this may well be a part of gsoc

but is it really important at the moment?

can'T you just create some useful curve and test with it? as the task was about container for axiom and not all the processing and bits

if we think raw12 is without plr, it does not need a LUT since it is linear (am I wrong)?

i would definitely start with A, to dont block the whole thing.. and when the proper 16bit linearizaton is implemented, then packing it with a lut/curve to 12 bit is trivial (C)

Wait. First check efforts.

how to account for plr in cdng

g3gg0-mobile2, sure... will do some research, and get back to you within a few days with some thoughts on it

Please ask if things are unclear

Gtg. Continue per mail please

Ok cu

np, off for shopping too

hi TofuLynx

I added the manual paths on ProcessingTest Cmakelist

pastebin your cmakelists.txt please

Here is it

?

I mean

Running "/usr/bin/cmake /home/claubit/opencine '-GCodeBlocks - Unix Makefiles'" in /home/claubit/Source/build-opencine-Desktop_Qt_5_10_1_GCC_64bit-Debug.

ok!

?

I have a problem

do you use qtcreator for git?

never worked for me well

i think the problem is Qt not detecting the .cpp file

yeah

so you can adjust

Can you check it?

Is it neccesary to add a CMakeLists.txt to lodepng folder?

nope

alternatively you could copy them to the folder where you need them

I will wait for your try :)

enjoy your meal

replace your paths to lodepng with this ->

"${CMAKE_SOURCE_DIR}/3rdParty/lodepng/lodepng.h"

Let me try it

Thanks!

Ok

But I can't really confirm

Sent :)

i like gedi more

Yeh I will be

Well, finally I can compare the different algorithms with GIMP

Now, as I said yesterday, I will review the code and document it.

Good Night Folks!