#apertus IRC Channel Logs

back again ...

hey, how are you?

I'm fine too, thanks for asking

well, the current status is probably that BAndiT1983|away is 'working on it'

yeah, he is working on it, okay I will surely ask if something else comes up, thanks Bertl

welcome Christofpap!

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

< Rex

Im checking the recent events on the lab :)

Yeah lots going on at the minute.

hi, i'm fine, and you?

i added rudimentary CMV sensor adapter to control gain or set registers

I am fine as well, aha okay, can you please send the repo link ? I am not able to find it

ok following now, thanks !

socat is a command in linux, have to be installed separately, udes for socket communication testing, currently i use it to see if the daemon receives messages

*fast to process

*used (i really think my batteries in the keyboard are dying slowly)

I see you need to test the control daemon, so after adding communication will it be ready to use ?

ok cool, I am bit curious about the daemon because I need to devise a time line for gsoc application, based on how we will proceed including some brief steps and procedures in order to complete task/T723

afterwards it can be fixed, polished etc.

i think that, depending on the language you want to use, a wrapper has to be implemented, but i don't have much details at the moment, need some time to reflect on it

i've expected you already

you had some questions about the gsoc task, just ask away

it's just the latest version and shouldn't be really relevant, until they change their API

important thing is another one, to implement a plugin which uses OC decoders or wrappers for RAW formats, first (C)DNG one i suppose, and give the user also some settings for VapourSynth scripts

so we wanted to test if wwe could handle it nicely in multi-platform style without much hassle

Oh. Could you give me the dates so that I can look into the logs of that discussion.

it was an internal discussion with se6astian, so it was in german only

Goal: Implement a plugin for VapourSynth to be able to use OC decoding and color-grading to provide RAW frames to different applications via frame server. This would allow to provide data to applications which do not support RAW formats natively. Additionaly it has to be ensured that memory usage is low enough and performance acceptable. Next step would be a mechanism to provide proxy of the clips for not high-end machines.

proxy means some replacement for the footage, in our case it's a scaled down version, as i hope to be able to playback 4k clips in the future, but many machines don't have enough power to do it, so we have to substitute it

Okay. I still have to build OC.

afterwards we can discuss the details further

*i'm not online

"thanks"..."fpga"

Bertl is not here at the moment, so you could try to look through the logs, as many people wanted to attend gdoc for the fpga regulator part

usmankhan: the idea is to drop the ADC and have one or two comparators which compare the output voltage to the reference voltage generated by the DAC

no problem

JOIN

bertl : so for sobel filter module will I assume only one input for getting the pixel input data or each for seperate RGB channel ? I want to try to perform the convolution kernel after performing RGB to gray conversion

as the sensor is monochrome itself, wouldn't it be easier to do median on data before color conversion?

BAndiT1983 : I see...I thought the cmos would have a baeyer pattern

*sorry, pressed wrong key

usually it all should be shown as grayscale

ah, Bertl is here

it definitely delivers :)

apertus page says monochrome, se6astian told me that all the cameras which were shipped were RGB ones

it was about sagnikbasu95's question about sobel

is it better to let the sensor filter or do it aferwards?

i mean RGB and monochrome thing, not sobel

for example x-trans sensors have problems to get the color right, as each layer slightly shifts the color of light when it passes through

then you will not know what color triggered what sensel value

and the filter is arranged in a bayer pattern

or how is it done usually for monochrome versions?

monochrome sensors have no bayer pattern

both color and monochrome CMV12k are identical

they will both produce a 4096x3072 field of sensel data with 8/10/12 bit depth

for the color version, the light is filtered according to the bayer pattern of the color filter _before_ it hits the sensel

this way, the sensel data, again 8/10/12 bit of 'lightness' will represent different colors, depending on the filter pattern

and there is no way to get color information from a monochrome sensor

he still needs some simple bi/linear interpolation for his filter beforehand

not me, i'm not a student at gsoc, was about sobel, as he needs all 3 channels, but they have holes because of missing information of neighbor pixels

but what about missing spots in the channels?

there is nothing missing if you look at each channel independently

this would incvolve very coarse interpolation or not?

how can it be? sensor delivers information for each channel, every channel have every second pixel missing, green channel has shift in each line a bit

there are two green channels and when you look at e.g. the 'red' channel it will have only a quarter of the sensel of the entire sensor, but they will be evenly spaced and thus give you a perfectly fine 2048x1536 image

same is tru for the blue and both green channels, except that each channel is shifted by 'half' a pixel

it's not about what I want, it's how you can interpret the data

post-processing what?

it is unlikely you want to run a sobel filter on data used for recording

is it not the same stream in the camera?

and usually not to 'record' strange looking images

well, now you know :)

off for now ... bbl

off to bed

nn