#apertus IRC Channel Logs

alexML: I updated the firmware, in simulation it behaves exactly like the old one (when the GAIN LUTs are zero) but real world testing shows some weird clipping going on ... for now just disable the RCN clipping

where the 4 bits of ? are:

so in theory ?=F should be the desired setup, but for now it seems that ?=D is required

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/cmv_hdmi3_gain.bit

good evening

however, there is a strange overlay at startup (also present with the old firmware) that disappears after a few attempts to change fil_reg 11

"./mimg -a -o /opt/IMG/newsmoke.rgb16" runs an animation on the left side of the screen

correction: the behavior of that "?" does not depend only on its value, but also on its history of values

default: white screen; 0: blue screen with a small white line in the top-left corner; 1: no change; 2: the white line disappears;

changing to F => the rectangle disappears

any value after that (0-F) => no change (normal image)

also, forgot to mention: I wasn't able to change the gains

definitely doesn't happen here

./mimg -a -o /opt/IMG/overlay_04.rgb

05 makes it a bit thicker

yep, that's expected ... it is how the overlay looks

ah, you changed the meaning of the overlay to encode pixel offsets?

regarding overlay, everything should be as before with the new bitstream

show me what you get in a snap or see on HDMI, then I can tell

https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/overlay-issue.jpg

very interesting

overlay_05 just makes the border thicker

md5sum?

and the mimg tool?

653c33e76b5dabbeb40a4c400c61facd mimg

let me quickly upload my version just to verify

it might have changed in the meantime, so I do not consider that a problem right away, we should just check it

443840323893eb56171fb8b160ee9615 mimg

what the duck?

an use ./mimg

(after changing the permission for it to be executeable)

works now

okay, so I conclude that your mimg has some 'other' features

368bea2b37cdb85c290c5883e8d9b006 /opt/BERTL/mimg.c

(yep, md5 matches)

hm, maybe I screwed it up when trying to recompile cmv_snap3

let me figure out why the mimg.c is actually broken

the 'working' one is v1.6

and calling it multiple times mixes all the overlays

e.g. overlapping "AXIOM \Beta" and "AXIOM Overlay"

btw, looks like I've broken cmv_snap3.static when I've added the semaphore calls

found the answer: it must be -static -pthread (no idea why though): http://stackoverflow.com/questions/17928260/gcc-static-linking-error-for-lpthread

the gamma LUTs?

0x80300000, 0x80304000, 0x80308000, and 0x8030C000

correct

np

yep, it is used in gamma_conf.sh

btw, since you are here

currently they are not used in this mode

and here I have some figures showing what improvement they can give

short summary:

after subtracting black columns with a scaling factor, it goes down to 0.82

so, the info from those columns can be used to make the row noise 4 times smaller

that means, I think we should record this info somehow

what about averaging the 16 black columns (for each row), and outputting the result on one border column on the HDMI image?

the problem is, the black rows are not fetched for the HDMI output

so the data is not available in the output pipeline

you effectively crop the image, right?

it might be possible though, to average (or sum) the data on the arm cores and save it separately

so roughly over one megabyte per second

can you point me to a way to sync the arm code with the image capture? (interrupt or whatever)

and some address where I can write data to appear on the HDMI output?

once the buffer is on display, it is guaranteed not to change

it can be the overlay as well

and having the data shifted by one frame shouldn't be a big deal (since it's a video stream, after all)

let's say your code takes 500 lines to do the calculations

that would leave you about 2000 lines to construct and write an overlay for the bottom line

off to bed

ideally, the stuff that overflows should clip to white

well, clipping is per channel, i.e. it clips the channel to the maximum value

but please show we what you see and what you expect

https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/IMG_7312.jpg

what happens is that blue wraps back to 0

fil_reg 11 0xF?41F000 has no effect for any value of ?

fil_reg 11 0xFC?1F000

did I paste the wrong place? ... that would explain the overlay issue

12:11 < Bertl_oO> fil_reg 11 0xF?41F000

they are usually 0xFC, i.e. they leave out the lower 16 bits

but as I said, there is something wrong with the upper bound clipping on the new firmware

I can upload the source if you like play with that

*often

back to old firmware, but still the clipping flag doesn't seem to get enabled

note that this is for the RCN clipping

ah

perfect, works as expected now, thanks

Bertl: for mat4_conf.sh, can the offset be negative?

I get the same output as with ./mat4_conf.sh 0 0 0 0 0 0 0 14.0000 0 3.7500 3.7500 0 5.0000 0 0 0 0.1 0.1 0.1 0.1

(repeated 4 times)

so 16 is the same as 0, and 15 is -1

0.5 maps - very roughly - to about 200 12-bit DN

I suggest to use the mat4_conf.py instead

yep, looks like

500/4095 = 0.12, so 1.0 = 4095?

I have trouble finding mat4_conf.py (neither google "mat4_conf.py" nor "locate mat4_conf.py" can find it)

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/mat4_conf.py

np

yes and no, it should be compatible for 16/20 values

i.e. previously the order was B G2 G1 R now it is R G1 G2 B (as one would expect)

got it

ok, you may review the API: https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/set_wb.py

well, you can use mat4_conf.py rgain ggain bgain rblack gblack bblack

yes, but I want to set a full matrix in the end, not just gains

http://sebix.at/tmp/rgbhsv.py