#apertus IRC Channel Logs

off to bed now ... night everyone!

good day

*sorry, wasn't available 2 hours ago, read the mail just now.

that depends whether sensor has dual-iso and the CMV12000 has not

such as ..

has that some name?

I was wondering the same :)

dual iso is when you modify the conversion gain, not the exposure, otherwise you get some nasty artifacts

off for now ... bbl

and I guess the name would be dual-exposure, no? :)

interlaced as in... into separate streams

usual post works in a way you throw into it a lot of input footage and it produces something meaningful

can you explain this? would you like for this to have in camera sync if it were two streams in single file? I think this would make sense

camera sync is about timing of sensors, completely unrelated to muxing two video tracks into a single file

sync as in ordering and timing of two streams with respect to each other

dual-iso: exactly. the big plus is that the interlaced lines have the same exposure time, preventing some tearing artefacts

e.g. if you can use non-linear sensors

that would create tearing... more of ghosting artifact no?

well maybe thats the better technical term, syes

varying exposure time is good for still photography

i am not aware of all technical solutions out there. but dual iso was a very fitting one

Piecewise linear response (https://wiki.apertus.org/index.php/PLR)

you have to be very exact when aligning and syncing those 3D cameras

ah, PLR ok. dont know if we have to transport additional data from the camera sensor to the developing application - do we?

*if* thats done, you can define your own blocks for that

hehe maybe its not clear. MLV's structure does not restrict the number and types of blocks that you use

skip what you don't understand - for readers

hmm... okay

incompatible changes to the file format

g3gg0: can I ask the thinking that went behind v2.1

you mean the field in header MLVI ?

ah okay sure

the question was (a year or so ago) how MLV could handle multiple camera video streams

the one with my first digital camera? 4 years ago or so

multiple camera video streams <- In which cases would you need it? Since for example danieel suggests that he may want two streams separate in files

PLR in file format: add a LinearizatioTable (reverse LUT) as in DNG

I think, no

the second one

genlock?

got it

in MLV every block has its timestamp relative to "recording start"

it is stored in microseconds

can you rephrase the question, i dont understand it

why would you need mulitple streams in a video file ?

there was some time ago the theoretical use case of a single camera with two sensors iirc

maybe for 3D or any other use case

also for audio

no idea if anyone has this goal, but would be simple to add

so in conclusion, am I wrong in saying that there is a limited use case of adding multiple video streams in a single file

that doesnt speak of everyone involved :)

the multistream file is useful as an editing format (multiple video layers)

could you elaborate this use case?

directly camera related could be to have an OSD in separate video track

right, i remember this example too. thanks

(use case: educational videos)

on screen display?

but iirc that one had a much lower requirement for data rates etc

OSD includes an overlay that we see on camera?

so you could simply define a block OSDI (OSD Image) and store some compressed frames here with reduced rate

does MLV define per frame duration or just occurence timestamp?

uint64_t timestamp hardware counter timestamp for this frame (relative to recording start)

call it the presentation time

yes

a custom WB has what options to configure? color temp... tint... and?

how do you define capture time with rolling shutter ? :)

iirc it was start of exposure of this frame

so when the first line was exposed

but never knew was correct

that is often a variable location if you change exposure, as the refernce point is usually the conversion/readout of the line, that happens periodically. Exposure start varies into "negative time"

so you mean that exposure might change in the middle of the frame?

modern sensor wont allow to do that, some produce garbage

really getting lost out here... why would exposure change mid flight

i'd take it as given that exposure time etc changes between frames

*doesn't it

mid flight exposure changes would be more of less like rolling shutter + flash artifact

after is > or >= ?

so g3gg0, regarding multi streams

how are they implemented in MLV?

if you produce a EXPO with ts=100 and a VIDF with ts=100 then you might be in trouble for the first line even when explaining the scenario

if you do as this... you swap between streams quite often... so multiple headers for no use..

conclusion: we would do good to make sure the EXPO/LENS block is queued before the exposure starts, ergo i'd write them with a timestamp lower than the next frame

@supragya: we have 20 bytes overhead then. for several megabyte blocks.

like constant offset checking...

(after every 100 MB maybe the stream info has to be rechecked) if it is still stream 1 or now

in case you swap constantly, you write after a given offset

but I guess this solution is very inefficient

i see the drawback of the need of scanning the whole file (with the modern caches you basically need to read the whole file to open it..)

danieel: my worry too

MLV suggest we create an index on first read and then it would all be easier

hello BAndiT1983

hi supragya

sort of header only dump with data left out would be better?

so you have that

hehe, welcome

yeah the index is some "comfort" feature like a cache

WB -> no change to raw data

its just the user's configuration what he wants to be considered in post

to understand what is important right now and what not

actually wb change could optimize the gains of individual channels - is there a separate GAIN meta info for this in mlv?

danieel: https://docs.google.com/spreadsheets/d/1ItNuLj34JlK6bZgiAJLrmG7p3iyCmCju4XYyiwjqJOM/edit#gid=0

hehe better.

no g2 gain? :)

no g2 gain it seems

others 2048 -> g2 1024

do you mean g1 and g2?

like in rg1g2b?

yes that

its raw, so gains relate often to CFA (and sensors do that)

*RGBIr

new block type <- a solution to everything?

if the given things dont fit at all, we have to extend it

i'd try to keep all at most backward-compatible as it is possible

mpeg allows the same, tiff also etc.

no

but an new block if we need this XD

canon raw is what exactly then?

offtopic a bit: one example for multiple video streams in a stream came to my mind from my study, we had to decode sattelite mpeg stream and there were multiple video streams plus additional packages, like date, UTC etc.

the 14 bit stream packed together into 16 bits with endianess reversion

(definitely easy)

BAndiT1983: satellite images have as many as 21 streams at once... I had some research consideration on that part in college

EDMAC alignment?

wait till 4k will be streamed over sattelite, how it will reduce the bandwidth ;)

i mean what is edmac alignment?

ues

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

set it to a value and this instructs the reader to ignore n bytes in the payload

n bytes from point of telling the value?

you could write in a way so that the raw payload starts at a sector start

what are the reasons of additions of mlv_colp_hdr_t

or in our case primarily the DMA destination address limitations.

okay

along with color matrices and such

bson? ?

binary json

;)

@supragya: yep and the bit coding and how to get RGB from them

it is empty. none found. :)

hehe

[bit coding and how to get RGB from them] <- example?

wrote my own

now we have 5 millions and 1 scripting languages out there ;)

https://xkcd.com/927/

Bertl_oO also uses that XKCD a lot here :D

;)

yes... [bit coding and how to get RGB from them] about this

i have an excuse: MLV is designed to be simple and written and read with few resources

is it about something like current raw12?

MLV is not the problem, it solves the overencumbering with many formats

it explains how bits are stored

14bit stream, which gave me a bit of headache to decode back then

is that a direction I should look at for my answer?

it would be enough to say it is TIFF compatible (or that it is not)... it defines tight packing well

I guess I more or less understand what MLV looks like... time to know others (MPX maybe)

thats the important part of your work.

those into consideration too... I wonder which is better to look at first

MLVFS

on fuse

on verge... need about 3-4 days rigorous work

g3gg0, it was a simple one, so we can test if OC can provide data

link: https://nofile.io/f/zejFC7uhNPg/GSoC+2018+-+libfuse-FrameServer+_+apertus.org.pdf

the current work explained in section 1

kindoff yes... did a bit of test of some modules..

why do you ask

was confused because i sent you the MLVFS link and you replied you made an avi frameserver. i thought you put it into MLVFS :D

btw i liked your proposal. but it made to me more sense to define the file format first

things that don't involve sun

you can be glad you have sun, currently dark clouds are approaching frankfurt

home office. oh well, i said i wont work today. but still i checked and replied mails.

for which target?

some age old technology he told me

nothing exciting

or 6510

yeah. signed bytes. yay

[you can be glad you have sun, currently dark clouds are approaching frankfurt] <- I am not glad, and I have sun outside... 45C /113F

that's why i'm not looking forward to dubai

last day my skin turned red... when I went to Indore

cant you prepare sous vide at these temperatures?

;)

just look for a black car and dump some eggs on the trunk, a couple of minutes and you have a meal

pffff, why should one, proteins all the way

better yet, get whey

have a nice day!

same

I have a small question about "4K HDMI Plugin Module (1x slot)" (status: not started): compared to the finalised "1x HDMI Plugin Module (1x slot)", does the aforementioned one (4K) require an actual different extension board (so new PCB/electronics design), or would it work with the finalised HDMI module (1080p), the only difference being that it w

(I'm mostly curious right now)

the 4k hdmi module will require a completely new PCB with FPGA on the module itself

the microzed fpga is not providing fast enough IO for 4K HDMI

ah, I see

se6astian: advice: dont spec 4K, but rather 4K30 or 4K60 because those have quite different needs (or better would be to say HDMI1.4 vs HDMI2.0)

Thanks supragya ! :D

hi TofuLynx

btw. have you tried to activate travis ci for your fork yet?

currently trying to implement a unit test for RGB extraction, but it requires a bit of restructuring, which is not a bad thing

and also memory pool testing was started, but it's not building correctly yet

in the original cycles

don't get stuck on optimization, push it to later phase

hmm

don'T think so, but maybe my knowledge is not up to date

I will postpone this, I guess

I think I will commit the old loops, what do you think?

Ok! :)

nope, at least couldn't find one for cmake projects, you have to open the folder by right-clicking the entry and add new file thre

ok! :)

I see

yeah!

it's for a quick build from vscode, so i don't have to change forth and back, also debugging was working nicely

went dinner

BAndiT1983: You were planing to add openMP to OC?

Ok :)

Ok!

I'm thinking about how I'll do the loop

I think I have a fast and easy solution for it

and only then I would do a loop that does nearest interpolation in the border, avoiding glitches

ok, looking forward to it, there will be some changes from my side soon too, but first the unit test has to be finished

Off for today