#apertus IRC Channel Logs

hi

morning folks!

good day

congrats on shipping the first beta guys!

was more a "handing over"

no guns involved *G*

:p

currently it takes a few days per unit, but we are in the process of speeding it up

and usually one more to assemble everything and do the final checks

changes always happen, the good thing is that most of them are in software

I mean in hardware specifically.

Have you already started collecting phase 2 and 3 payments from the folks in the first batch?

sebastian has the details

for example, the lens mount looks quite fragile to me (any Rebel camera is much sturdier), and I'm afraid those who will pay 3000 EUR for an early beta will be disappointed

alexML, What external recorder are you using?

So limited to like a few seconds of video then?

alexML, slacker! :)

hopefully I'll be able to compile some MJPEG codec on the FPGA and record internally

I wanted to program a trap focus, to be able to take pictures outside in "headless" mode (no buttons, no monitor), but that's already an advanced topic

but I would have had to hold the battery in one hand, the beta in another, and... I would still need an extra hand to turn the focus ring

and electrical/electronical issues to me directly

@transfer via ethernet: you can get it down to 2-3 seconds if you transfer the entire buffer

you are currently reordering pixels on the ARM processor?

the code rearranging that data is rather simple and generic (read inefficient)

s/pixels/sensels/

would make sense for the FPGA to pack things directly as raw12

because we need the 2x2 format for the full HD hdmi out

but there is a lot of room to improve the snap performance by clever rewrite of the tool

which makes higher framerates almost impossible

it's only DDR3 memory with 1066 MT/s

unlikely, yes

but we can do row/column based corrections

full frame operations are left for post production

what's a dark frame?

a frame which is mostly dark, because it was taken in the dark :)

indeed

assuming that it can be interpolated with a linear function, you get two terms, a constant offset and a factor

there is a very interesting method (that I have yet to try): using hot pixels to measure the dark current (the second term from the dark frame)

forgive my ignorance... y=m+xb? so you use the two frames (from known illumination) to find the m and b? Then you apply this to every future frame to eliminate the fixed pattern noise?

this removes the fixed part of the noise, but this sensor also have a dynamic pattern noise, which is harder to fix

in the dark frames, the second term changes usually with exposure, but also with temperature and probably other things (that's why the hot pixel idea makes a lot of sense to me)

i.e. from the sensor, that is

tx

but I'll compute one that can be applied directly

they look a little fishy to me

so that means 4096 possible values

I do the internal processing on 16-bit, that's why I used larger values, but subtract 1024 and divide by 8 to get values compatible with 12-bit data

this is the dark frame format I use for raw2dng

then we end up with 66 different values

well, then please upload a frame (12bit depth) which can be directly subtracted

it actually does make sense to use more bits for internal processing (I'll prepare some examples later if you don't believe me)

that's it

convert darkframe-x1.pgm -fx "(p-1024/65536)/8" -depth 12 darkframe-x1-12.pgm

in any case, it looks like it can be compressed with e.g. arithmetic coding down to a fraction of the original size

well, what I would do is to multiply the input image by 8, subtract the dark frame as I sent you, add a bit of random noise (which will actually turn into useful detail), and then perform the division by 8

so if done properly, we can assume that the image compresses 1:4 or more

yeah, that would work

which will likely reduce the amount of data further

and this usually doesn't depend on both, row and column

the stdev of the dark frame reduces to half after subtracting mean column values