#apertus IRC Channel Logs

off to bed now ... have fun!

I am working towards focus peaking project

and then the processing (ARM/FPGA) is performed...

As mentioned in my proposal...I had implemented the kernel using HLS tools but I process the pixels in line without buffering (VDMA)...

Now, my question is that

morning folks!

first, there is no classical VDMA in the AXIOM Beta pipeline

naturally the focus peaking has to go into the output pipeline

if you want to test with HLS (which is fine) you can use a streaming interface with some local buffering (line buffer)

then there is the question whether to do the peaking in raw or demosaiced domain

So, in my proposal i mentioned two different kernels to be placed in the pipeline

but later I found paper (I posted on the focus peaking task page of the aperus) where debayering and edge detection can be done in the same kernel

rahul_: if there are any questions, do not hesitate to ask ...

need a more detailed overview of image pipeline than [https://wiki.apertus.org/index.php/AXIOM_Beta/Manual#Image_Acquisition_Pipeline]

Here are a few things: se6astian said that atleast 4 frames are buffered before flushing to disk... what is the current way you do this? Are videos recorded at this moment in time and how are they done? (implemetation / code may be fine to look at)

what happens is the following:

at the same time (i.e. in parallel) a different frame is retrieved from memory and encoded as HDMI (for example)

this allows to lock one buffer (i.e. disable it) during live preview/recording and create a raw snapshot

both input and output happen in the FPGA without any intervention from the CPU

ddr as in [https://www.edaboard.com/showthread.php?t=79556] ?

using ddr buffers one after other... does that mean a perfect correlation of frame and buffer -> [F1,buf1];[F2,buf2];[F3,buf3],[F4,buf1]... and so on

Is serialisation automatic for HDMI?

(as till date)

out where? :)

hi supragya, early for an evening, usually in germany "good evening" starts from 6pm ;)

ah, right, you are going to the conference

26/04 22:00->00:00 Chennai -> Mumbai ---6 hrs layover--- 06:00->07:30 Mumbai -> Vadodara (Home)... 11:00 Avengers... 19:00 Vadodara -> Indore (conference)... on 28/04 20:00-> 04:00(next day) Indore -> Vadodara

raw container... yes

:), see... could not help it...

sometimes it's required, got a lot of impressions and ideas at oop2014, around that time i've decided to try to become a software architect

<supragya> XD flight got delayed.. 1 hr.. so layover is now 5 hrs... big deal :)

still missing some puzzle pieces here and there, at least to get some sort of emulation of camera pipeline

why do you want to emulate the camera pipeline?

for AXIOM camera

However, if format (serial packets / their format / the order / the markers etc) are known beforehand... we are good to proceed

separate recording usually

other metadata is much more of concern, like wb, aperture and so on

BAndiT1983: I am going to start changing the preprocessor loops

Hello g3gg0 :)

it's on average 3ms faster :)

Yeah wait a moment, I am just finishing the benchmark

I will do the PR

you can see it :)

Ok! :) I have to go to dinner soon too

Didn't try it, but I guess it would be slower, no? As it is in a single thread

try it please, as having more threads is not automatically faster

it depends on how big the RAM areas are, which get locked while reading/writing

hmm

dataUR[index + 1] = _outputData[index + 1];

dataLR[index + _width + 1] = _outputData[index + _width + 1];

have to go now, but will be back shortly, then i will reflect on it

cu

it's slower

so, the old loops took 42ms, the single loops (those I did a PR) took 38ms and, finally, the complete extracting on a single loop took 48ms

could you pastebin the single loop code?

https://pastebin.com/zR5BaPzk

is the output still correct?

yeah the output is still correct

have a nice meal

Good evening BAndiT1983, g3gg0 !

This time from Mumbai !

:)

Very close indeed

Very down...

this is an ongoing task, so it will remain open for some time

you could inspect the docs of RAW video formats, like RED and ARRI, to see which metadata or frame data is usually required, like WB, aperture etc.

(although there is nothing yet)

custom marks (button presses)

exposure info (exposure time, ISO etc)

lens infos (lens name/type, aperture, focal length)

lens info is at the moment not possible, as there is no active part for it in axiom beta yet

if i remember correctly, then the lens could be read out if we would have it

no, lenses usually have firmaware themselves

prepare for the future

button press -> in some situations, you would want to place cropmarks

not really understood you g3gg0

yep

so the editor knows in and out positions

not a film maker, but i suppose that the camera starts also before the main scene, so markers are helpful to get required material

custom tags like scene or take number

any meta information could be useful in post, maybe even the sensor temperature. be at least prepared how to handle such information :)

BAndiT1983: are we able to read the lens settings now?

read my previous comments, but to say it again, no

http://www.dyxum.com/dforum/emount-electronic-protocol-reverse-engineering_topic119522.html

how does custom tags like scene number and take number added on cameras?

does not matter right now

not: how can this data be retrieved from the camera

custom tags should be supported

also: find out which kind of data would have to get stored and which implications this has

extensible

you could also use mp4 format for that

me too, as i defined the MLV format

but supragyaraj is not biased yet

I try not to be... but seems like everything (infact even requirements) are discussed with that bias in mind :)

MP4 reference

you can also use multi-part TIFF, but it's missing some important tags, so you should look into CDNG, if it can store many frames in one file

even if you come to the conclusion that mp4 is far better because block handling and audio stream sync tasks will be perfectly handled by libraries, but maybe some licensing issues are a hurdle - the advantages should be documented

one thing I really like about MLV is the non linear storage of frames... I would really like a discussion on what kind of issues you faced with Canon... maybe AXIOM may run into it sooner or later...

MXF *hides*

> but let's reserve this sentence for later

this was a format also on first JVC fullhd cameras, but the quality was terrible

guys don't forget, that we are talking about some format which axiom should deliver at the end, optimistic way

so we can't just spit out full-blown format

-> pro/cons with assumptions and guesswork

https://en.wikipedia.org/wiki/MPEG_transport_stream

1. Current status analysis and requirement definition

technical possibilites and requirements of the signal processing path in terms of video container format (i.e. "what could we do with it and where are limits?")

;)

and yes, it might be guesswork at some point

but you can talk to experts about the possibilities of the hardware

Hello! I'm back!

hi

and all are limited by what in-camera storage you have

maybe the formats limit what you can do in camera

whats that ?

Guess what happens when dual sensor system is setup on let's say a single file... everything may break (hypothetically)

with dual sensors you get 2 files?

What if you need one... maybe sync things inherently

most of containers can take multiple video tracks

long time no talk!

so it supports subchannels

you can update that after stopping, that is not uncommon

BAndiT1983: 2 frames

supragyaraj, you cannot know it beforehand

BAndiT1983: exactly my point

it does... very easily

but for multiple streams... offset is to be known

? it's just a discussion that sometimes formats can be a limited thing too....

if you hope to do #include <container.h> then yes, that is limiting you.. not the actual format

(probably not the best thing to do btw)

ffmpeg.h* ffs

havent they dropped 32bit support.. soo.. nope :P

One of Kjetil's other jokes: http://irc.apertus.org/index.php?day=26&month=03&year=2018#41 ;)

supragyaraj: I am great too :p

TofuLynx: What jokes have you cracked?

ah, on apertus chat?

i'm confused

But on the topic I'm note sure that MPEG2TS is that suitable. You get synchronization but is kind of hard to extract frames afterwards without parsing the entire stream

BAndiT1983: you afk?

TofuLynx, yep, sort off, dinner and big bang theory

BAndiT1983: I saw that you merged the PR i made. Any considerations you want to say?

Ok! :)

the debayer class

Ok!

yep, it crowd is still her favourite, but tbbt is also good

I don't know little britain

yep, british humour, not for everyone

I do like it :P

so, off for today, see you

See you!

xD

nevermind

found*

See you tomorrow!