#apertus IRC Channel Logs

hi BAndiT1983

se6astian: are you available?

.

hi g3gg0

just replied to your email

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

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

then my vote is B)

illustration as in graphs/etc

and see no point in c)

I am good and need no further illustrations/references

need experimental evidence as you did with PLR experiments

However, as g3gg0 wanted me to dig deeper into this, I wanted to know what he really wanted (how deep, and in which direction)

just came home from a canoe event

I know alexML already started with the math model but I am not even convinced we need one, we can just measure the sensors response curve with as many samples as we desire and create a LUT from it

iirc my idea was to look into effort needed for each A) and B)

B is a low hanging fruit, if it is easily possible to forge a DNG which has the LUT *and* tools can read it

having features in a standard, doesnt mean that all tools support it

yes

sensor delivers 12 already

best i could think was a gamma curve, but that's non linear

g3gg0: :)

why convert it down again?

12 -> 16 -> 12 (I don't get what's going on)

12 -> 16 makes sense

16 -> 12 why and how

at least that there the things i saw in other cinemadng files

B makes sense...

as said, C is more or less like A, just with a downconverison to 12 bit. so...

can someone point me to papers or something like that, which describe this downconversion

thats why i said A and C are similar

still see no point in losing data, with proper debayering it would be no problem with noise, especially with dark frame

so compressing things back to 12bit is losing data, or am I wrong?

maybe you should discuss it with danieel ;)

so why is C even a consideration when we talk RAW?

also in canon raw video we use only 12 bits instead of 14 bits, as the two bits are partially noise

so C is perhaps "smoothing out" to accomodate ?

capture everything you can and let the whole processing stuff for post

and that is always 12bit, be it a,b or c

Just because I am not able to understand it's use case, and the mentality behind it

nothing more than that ;)

might be, might not.

that has to be tested in practical way

go for general 12bit from sensor and curve for linearization to 16 bit or so

it's about the range, so one can teak the colors and exposure in tools

*tweak

check what a DNG needs for the LUT, like the tags etc

g3gg0: should be a general header preceeding a LUT structure

I would need exiftool analysis

is it just DNG specific stuff or is it also used for TIFF?

LUT is general

but tags depend on the format

https://www.adobe.com/content/dam/acom/en/products/photoshop/pdfs/dng_spec_1.4.0.0.pdf

that is understood

that a paragraph :)

of what linearisation "is"

50712 - DNG/LinearizationTable

i get the idea of process (LUT + 12bitPLR = 16bitLINEAR)

a need a struct of sorts with datatypes to understand how to add it to publisher

something, that we figured in AVI, RIFF when making the frameserver

I plan on using their mlv2dng system

yep

you can still manually forge the DNG

e.g. get a DNG out of mlvfs and handcraft / add the table if you are comfortable

g3gg0: btw, why did you wanted the mlv generated by AXIOMRawStreamHandler(generator)?

BAndiT1983: seems plausible, however needs a working "publisher" to build upon

but first, let's make sure that synthetic frames (Emulation) are encoded correctly

which way do you mean?

first, let's make the emulation complete I mean

and then add LUT etc. ?

as BAndiT1983 said, craft such a CDNG (with or without mlvfs) and check if it will properly render in common tools

(was it danieel?)

getting old ;)

nope

(yeah it was danieel)

so best is to check if all use the same interpretation of the standard

LUT standards, you mean?

yes. maybe the LUT format, as it is specified will be interpreted fine by every DNG reader. but still the file will not load due to dozens of other issues and missing tags

https://www.magiclantern.fm/forum/index.php?topic=11899.0

you mean emulation?

okay.. thanks

will look into it and report back

or am I missing something critical which differs from canon mlv?

let's look at that too.

there were minor things. i think i asked you via mail

e.g. frameSpace being set to 22008

that is probably a bug perhaps

i'd also fill the raw_info properly

check a sample mlv file which values it uses

g3gg0: sure

yep, cool

ok good night. will answer your mail tomorrow.

i like the proposal for the PLR block

more details tomorrow. cya

Bertl, is busy with some stuff for few days so I'd need you and alexML :)

So, we were running some tests on beta and realized that many factors affected the run time of the code

so, after talking to sebastian we have decided that I should write an overview of what kind of access is good/bad

I'll probably make a doc and will share with all my mentors, so I'd need your feedbacks :)

if you could look into it, it'd be amazing :)

sure, you have my mail address? if not pm me

sure, night!