#apertus IRC Channel Logs

troy_s: ad linking, sometimes the order of libraries is important

ad lut transformation, I think it is a good approach to have the LUT (3x3 + 3) implemented in C/C++ so that we can test it without actually requiring the prototype, and it should be as flexible as well (i.e. we can certainly load the LUTs from files)

for the OIIO I still think that a 'generic' raw importer/plugin would be the best way to go, it can start as version 0.1 with just support for the axiom raws, but it should be possible to extend it to more formats as we go

(we will soon switch form .raw16 to .raw12 to reduce the filesize

and maybe different heights as well (we might want to reduce the height to grab more frames)

morning!

hi gabe

Thanks for fixing the typo in the makefile

yes, it works great

good. I think the LUT is in a format hebert can use

but it should be tungesten

yes, we set it up together 2 days ago

I will capture a new set of IT8 images as exposurerow as troy suggested later today

nope

hmm, hard to say,

as we had them on the other sensor

btw we can capture up to 7 frames at full FPS

so if we reduce the number of read out lines to roughly a third (1080 lines) we can maybe store around 20 frames in FullHD

but for streaming over HDMI we don't need to store all those frames simultaneously right?

If you can get a sun lit / no sky IT8 (no glare) that would be excellent.

I have the kinoflo and color temperature meter here still though

se6astian: I need a new run of the noise5 with more light, maybe also point the camera at a white area

i.e. some kind of really really wide format, which would give about a second of footage

morning Bertl

thanks! appreciated!

both, FPN and the row noise as they are entangled

I see

the current setup is probably suboptimal (the register settings, but I haven't searched for the optimal setup yet and I want to see if that theory actually holds first)

for now, don't change anything, it's just a test

if you like, you can experiment with enhancing the FPN pattern over the row noise pattern

run a single frame through convert -normalize and look for uniformity across the whole image

you should also see the FPN emphasiszed and the dynamic row noise appearing 3-4 times over the whole image

Am I right that the best method to compare the row/FPN noise results is to use very short exposure times to reduce thermal noise influence and to use darkframes with closes lens cap to only see noise and no scene content?

I presume the strange character before the 's' is a µ i.e. you mean us?

yes, in theory we can get lower, but I don't think that it will be necessary/useful

so it really depends on what noise/offset/distortion we want to capture :)

one issue with using convert -normalize: wouldnt that hide any effects of lowered row noise when changing register as it will just scale up values higher?

i.e. if the FPN noise is very large, row noise will almost disappear

the readout itself happens with 32 channels @ 300Mhz (at the moment)

7.8ms for the entire band

yes, it will degrade a little, but that is probably not even measureable unless you have really really long readout times

66ms is wrong by me, it should be 1/150 (150fps) right?

yep, that's the readout time (roughly) regardless of the exposure time

i.e. the CMV12k sensor doesn't do anything relevant during FOT

agreed

Happy new year everyone !