#apertus IRC Channel Logs

morning folks!

evening sasha_c!

Does Gabe come on here often? I'm interested in asking him more about what he plans to de re: his plans for building medium format digital back for photography

Thanks, I'll try contacting him via email

Hey, it's very exciting to think about the proposed plans for the beta

yes, indeed

hey se6astian! how's going?

looking good

the problem is to get all channels to one even illumination peak

I see

yes, definitely, but I wasn't able to get even illumination here without the contraption

I will try, but it doesn't look very intersting

with a diffusor made out of a special slide foil

and a small board with an RGB (I tried individual red green blue leds as well) led, which is controlled via the pmod port

the led has a wider angle (120°) and illuminates the diffusor, which refracts the light into the micro lenses of the sensor

is that a potential sideeffect of the RCN?

if you adjust it with uneven lighting in the red/blue

I see

would a good profile result in fully alligned bumps?

i.e. even illumination -> gauss curves at the same location

I see

can I clear the current rcn profile with loading /dev/null with pmem -B 0x60000000 -m W0x60300000+0x8000/W ?

pmem -B 0x60000000 -m Z0x60300000+0x8000

you're welcome!

hmm, seems running "pmem -B 0x60000000 -m Z0x60300000+0x8000" just crashed my camera

I did turn off image acquisition beforehand but left the histogram open (which runs snaps on its own afaik)

hmm, but obviously it has

will investigate

after reboot I noticed that my green bumps also down line up without any rcn profile

also the matrix is fine

how much do they differ?

screenshot, one sec

image flipping is set to 2 = flip in Y (recommended)

the blue and red look like the greens

if I set flipping to off = 0 it seems to be correct again

so you do not account for the flipping then :)

I assume flipping was set to 0 by default in the beginning? (when I created the histogram code)

ok :)

which allows you to specify a percentage of the width/height which will get sampled

nice, parameter is percent of height/width in center?

great

still working on it

ah ok

okay, I guess I fixed it so far

my camera seems to crash a lot today, I first thought it might be a loose connection, but I am not convinced of that anymore

I also seem to have solid color areas in over/under expsoure areas after rcn calibration

let me rebuild the image, just to make sure

you can do it with pmem though, but the command is:

i.e. zero does not work, as it uses undefined access sizes

updated wiki

okay, bitstream has been updated, also wmem_conf.sh changed

fil_reg 11 0xFC31F000

ah I see, the upper limit clip doesn't work as expected

PLR GUI ready: https://twitter.com/ApertusOSCinema/status/444109187711107072

piecewise linear response

se6astian1: You made progress on the >70% RGB values!?!

I think we are making good progress

I build a contraption which allows to measure the sensor without the illumination problem

Bertl: The >70% woes?

Bertl: Were there some there that were revealed in our tests?

so testing the linear range is rather simple

Bertl: You built a bellows?

Bertl: Any tests that further your hypothesis?

the leds are synchronized with the frame request trigger

Bertl: Ah.

yes, as I know what I expect and what I get from the sensor

time will tell :)

danieel: It is the >70% RGB values that are causing the worst fits that cannot be shaped out.

se6astian1: okay, there is definitely another bug in the rcn code, have to simulate this and see where it goes wrong

hey, how's going?

fine so far, on the bug hunt atm :)

oh great...

tomorrow i have the first chat with departure funding

till then i need to make a small presentation

btw I finished a first version of my Clipfinder Program http://dcs.co.at/pics/Clipfinder.jpg

Malte had a good point....

and a bigger one which is scaleable

on the HP of openCine it is very good described what it should can... so then there should be a Hardware

sounds good

well they are just responsible for the administrative part of the grant and while they have experience with previous calls they are not involved when it comes to making a decision isnt it?

bertl what do you think will it take on manpower to develop openCine in a basic version???

rainer_vie: no idea

actually most of the software already exists

so for getting DNG realtime playback its probably very little work/time if you find someone who knows what he is doing

the first version should have only settings for debayer

displaying in realtime waveform etc. will also take time I think

it has a primary color correction already inside... and there are various open vfx projects I found which are dealing with that...

but since these are all open source tools, thats the glueing together I mean

after some testing it appears that the histogram seems to be crashing the camera mostly

do you trigger a snap in the histogramm acquisition?

IIRC, the hist code probably needs an update

yes crashed again when I had the histogram page openend and started automatic acuqisition

and crash means?

so a CPU crash I presume

okay, that sounds more like a stall in the AXI bus then

sure, how do I dod that?

http://en.wikipedia.org/wiki/Magic_SysRq_key

I see, I will look into it

(followed by e.g. 'h')

for the serial console?

well, no idea then, maybe check the help?

(look for sending a break character)

[ 94.241855] SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w)

try this when it 'crashes'

btw, new bitstream and tools shortly

crashed, does not accept any input anymore

ok

mikkael is already looking into it, AFAIC

okay, bitstream updated, rcn3 as well

i.e. you need to recreate a profile, but the rcn3 tool should do a good job now

will try

before what?

bertl your bayer pattern is 4 pixel ?

dcraw can't decode with my command line

i.e. just specify -N 3 or -N 5 (it will average the measurements)

it seemed to me, that it doesn't handle 'raw' data :)

imagemagick

https://wiki.apertus.org/index.php?title=Axiom_Alpha_Software#Simple_debayer_with_ImageMagick:

hi Bertl

will test with some more light and multiple snaps now

what version?

hmm, maybe you want to update, 6.7.5 here :)

no, it's an ancient version :)

i.e. maybe a supposed to be compatible package?

a branch/fork from imagemagick 5.5.2 (2002)

right I'm compiling the actual version

rainer_vie: s/actual/current/

or 'latest'. but actual is 'tatsächlich' :P

very interesting results

if everything is black, then no :)

2f3792f25ce3ace3706a4473ace372e6 cmv_rcn3

I have an 20 minute old version then

:)

but I noticed that it also does auto white balance at the same time ;)

before the wall had a yellowish/red tint from the tungsten light

yes, as I said, you want to get even illumination over all channels

so I need to adjust the matrix ?

i.e. it is in the output pipeline

how can I get evenly exposed channels....

ok :)

pmem complains about wrong parameters with the command on the wiki

ah wait

putty edited the command unintentionally

updating again now :)

:D

sebastian you need a 6k HMI in your livingroom

and well heated :)

ok

it will do it implicitely but very subtle

and the pattern is a bit more visible again ... :)

maybe best if I retry this with sunlight

i.e. if you have a perfectly corrected 50% gray image

you can compensate for this with the LUTs before the RCN correction

all libraries in /usr/local/lib but when calling convert it does'nt find libMagickWand-6.Q16.so.2

what distro are you running?

I could copy all them from usr/local/lib to usr/lib

why not just install the imagemagick package?

okay, so give it a try then :)

http://namhuy.net/1730/install-imagemagick-6-8-linux-mint-ubuntu.html

ouch, okay :)

it's a lot of data and probably depends on the available memory

is the sensor 4:3 ? aspect is 1,333

oh nice, so we can use anamorphic lenses as well

ahhh

I meant do you read always the hole sensor array or a window if you need 16:9.

i.e. stripes, which get transferred

(as it will increase the framerate or possible exposure values)

1:1.9?

yes, will do soon

rainer_vie: sounds strange, that would be 1600x3072?

2048x1080 or 4096x2160 is the full format

ah, that's 1.9 then (or 1.9:1)

why are you switching H and V (i.e. inverting the fraction?)

so thats the worldwide aspect ratios in cinema

1,85:1 and widescreen 2,39:1 is common

with anamorphic lenses

but it is not very often used in europe it is more a hollywood style ;)

not that I've ever actively noticed to be honest :)

yes, but the newer anamorphotic lenses are better corrected, so they made filters for the anamorphic lens flare... this horizontal flares... weired thingsd

you can easily play with the feature by using linear_conf.sh 0.30 (for example)

I will make the 0.25 = 1.0 by scaling the input value when we see that 2 bit is a good choice

so, let's find the linear range now :)

that will get funny after three glasses of red wine

morning sasha_c!

https://github.com/apertus-open-source-cinema/alpha-software/blob/master/cmv_hdmi2/registers.txt

You read my mind. I have the day off from work today, so I can get started on adding those details to the wiki that you requested.

it would be nice to find a somewhat appealing table format for the wiki

you might want to look at the CMV12k datasheet, the format used there is not uncommon and I think somewhat easy to read

no, make a new one

the CMV12k registers are only a small part

yes, there is on github, but it hasn't changed much layout wise

cool, thanks

ok

Is this suitable: https://wiki.apertus.org/index.php?title=CMV12000_to_HDMI_registers

hmm, well, the table might work for the actual registers

(so the heading is misleading)

i.e. the xxxxx means that there are addresses where the 'x' are

the address and the description

https://wiki.apertus.org/index.php?title=Axiom_Alpha_Software#Register_Memory_Space

yes, it does. Just made the changes to the wiki. How does it look now then?

note that the 4 column table you had is fine for the actual registers

http://www.analog.com/static/imported-files/eval_boards/ADV7511_Programming_Guide.pdf

I'm not sure the RW/RO column makes much sense in retrospect, because we have clearly divided ranges

0x60000000 - 0x60100018 all read only

I mean

0x60100100 - 0x6010013C all read/write

i.e. the ***110**** style

but it is in no way necessary

rainer_vie: The larger issue with grading is intra application transfer: CDL, LUT formats, etc. etc.

(or any chart)

sure... I pointed that out, because it has a grading function... we definitely have an other aproach

Bertl: Woop!

well, I have one strange issue left with the linearization

so should be sorted out soon

maybe, maybe not

raw frames, raw streams for example

*byte

troy_s: btw, we have a new .raw12 format :)

ARRI for example made an online LUT generator for their LOG-C format: http://www.arri.com/camera/digital_cameras/tools/lut_generator/lut_generator/

regarding troy... it would be cool to make luts for color space conversions for REC709, DCI XYZ etc....

you mean on the camera or later on ?

what I mean is, no LUT required for linear color space transformations

no, we currently do not debayer it at all

yes but for the video outputs (HDMI and SDI) and later on on the raw conversion it's debayered

ok... so the picture which is displayed on the hdmi interface will be the same as debayered currently for example with imagemagick

the hdmi encoder does some interpolation as well

and we still have to configure YCrCb to test if it improves the image

10 bit 4:2:2 YCbCr would be great

switchable

yeah... but most of the external SDI equipment will work fine with component signal

:) I'm sure you will get this working

of course, open interfaces will be supported sooner than proprietary variations

time for bed

bb sleep well

so a maximum of 60fps is possible I think on SDI currently

bb

:)

wb eadmund!

good news: idea of making the next board for you is under discussion. but we will also probably want to get a replica of previous one running.

eg. Zedboard or Microzed or a Xilinx SDK.

ah. you mean the design is proprietary, or the chips are proprietary?

or the tools?

so using those would make us 'depend' on this specific manufacturer

you mean you want a *documented* design

sasha_c_: looks good, except for the default values

sasha_c_: which are currently in the 'Bits' column

Can I simply rename the column from 'bits' to 'default values'?

Ah, I see

ok, fixing now

thank you for helping!

btw, if you manage to get some even/odd light gray/dark gray alternating background it would probably enhance readablility significantly

eadmund: so the zedboard, microzed and even zybo have at least well documented schematics

(the zedboard layouts are public as well, btw)

frankly, I am more distrubed about the connectors/interfaces. The LPC VITA on the zedboard looks horrible. Did you do the design that connects to it?

well, congratulations.

so, everything is out of my hand now. I am shifting to looking for cheap tools and a hackable Rigol :)

already done :)

I built a contraption out of a paper tube, some master film and an RGB LED

the foil is used as diffusor and the LED is controlled by the FPGA

neat!

for color calibration leds are not that useful btw