#apertus IRC Channel Logs

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

good day

morning folks!

morning :)

nice, did you try those on camera yet?

nice, wasn't sure I implemented all the math operators needed :P

well hdr adds 2 kneepoint exposure times so I just copied the formulas from the normal exposure time

you also have two voltage levels

for vtfl2 it says: Bit [6] = 0/1: Enable/Disable DAC

why would anyone want to disable the DAC?

or could also be for external voltages?

the CMV12000 datasheet only has 2 occurances for "DAC" and thats exactly in the description of the VTFL registers for PLR HDR

well its probably also the only DACs in the sensor

se6astian: not a lot changed from last week, was quite busy

right

great

anything to share vup?

small recorder GUI improvements, wiki improvements, webui additions

ordered a powerbank with PD support, does not work with lattepanda still

designed a preliminary recorder enclosure and 3d printed on friday

thats it from my side

nope nothing really new from my side

sorry was afk for a sec

ah cool, can you give some insight?

there are two basic (interacting) things that are missing still from the implementation: 1. support for multiple outputs

(for example imagine having a hdmi source and then two outputs, one for live preview and one for saving to disk)

another topic we have been thinking about for the next iteration is tiling / cache blocking to overcome memory bandwidth limits we are now running into pretty easily. If anybody has any thoughts or inputs on that they would be much appreciated

thats it for now

sounds great!

ok then, MEETING CONCLUDED, many thanks everyone for pushing this project forward, small steps and big ones to "brag about" :)

as always: my pleasure

Hello

Ah hello it is working

yeah, was just distracted :)

I've started getting familiar with the code for raw2dng, got it compiled on macOS, but there seems to be issues related to 32 bit, so I've only maaged to run it on my linux laptop. I have not yet managed to get a correct DNG conversion yet. Am I right in thinking I'd need to use frame-merge and raw2dng to achieve DNG frames from the HDMI data?

but we also have snapshot raw12s

you might neeed to use the --swap-lines parameter with raw2dng for those

as in an older camera firmware version we had a bug that swapped even and odd lines when saving stills

The DNG files seem to be all orange and crazy

Not sure what was going wrong

if the colors are wrong but the general image does not look distorted then its likely a bayer order issue

even/odd lines swapping also changes bayer order and leads to wrong colors

https://wiki.apertus.org/index.php/Raw2dng#Further_Notes

its all pink then

which files did you try to convert in particular?

right

Understood

as its easy to accidentally merge B of one frame and A from the next frame

the framecounter corner marker helps there

this script shows frame counter, etc

I deprecated the *.bgr extenson though and switched to *.frame now with recordings

because its no bgr anymore

but only for newly recorded clips :)

Ah I see.

Then I should figure out why this doesn't work on 64 bit.

might be a simple fix

I suspect it might be due to the 32 bit pointer in the middle of the raw_info structure. I tried allowing a 64 bit pointer, but the code crashes.

The makefile always compiles the code to 32 bit

It sets the 32 bit flag unless already compiling on 32 bit arm I think

Yeah the issue with macOS is no more 32 bit support.

But for now I will just use my laptop with linux

right

I updated https://docs.google.com/document/d/1ERt7XjSjaa7GC1EGPR6PFvjFwDJYQMQKQPc4xy9CwBk/edit# already accordingly

*samples

the output from frame-merge should not be different

Ah ok

off for dinner now

and I dont really see why the mlvapp code wouldnt work on the camera