| 01:07 | BogdanXor | joined the channel |
| 01:11 | BogdanXor | left the channel |
| 01:23 | g3gg0 | joined the channel |
| 02:07 | BogdanXor | joined the channel |
| 02:12 | BogdanXor | left the channel |
| 02:22 | Spirit532__ | left the channel |
| 03:08 | BogdanXor | joined the channel |
| 03:13 | BogdanXor | left the channel |
| 03:20 | illwieckz | left the channel |
| 03:21 | illwieckz | joined the channel |
| 03:51 | arpu | left the channel |
| 04:04 | arpu | joined the channel |
| 04:09 | BogdanXor | joined the channel |
| 04:14 | BogdanXor | left the channel |
| 04:34 | jucar | left the channel |
| 05:10 | BogdanXor | joined the channel |
| 05:14 | BogdanXor | left the channel |
| 06:11 | BogdanXor | joined the channel |
| 06:15 | BogdanXor | left the channel |
| 06:50 | g3gg0 | left the channel |
| 07:11 | BogdanXor | joined the channel |
| 07:16 | BogdanXor | left the channel |
| 07:18 | niemand | joined the channel |
| 07:35 | se6astian|away | changed nick to: se6astian
|
| 07:42 | illwieckz | left the channel |
| 07:43 | illwieckz | joined the channel |
| 08:06 | niemand | left the channel |
| 08:12 | BogdanXor | joined the channel |
| 08:17 | BogdanXor | left the channel |
| 08:30 | Alex_Chooks | joined the channel |
| 09:13 | BogdanXor | joined the channel |
| 09:18 | BogdanXor | left the channel |
| 09:23 | ItsMeLenny | joined the channel |
| 09:40 | se6astian | changed nick to: se6astian|away
|
| 10:04 | BogdanXor | joined the channel |
| 10:33 | niemand | joined the channel |
| 11:10 | Bertl_oO | 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
|
| 11:11 | Bertl_oO | fil_reg 11 0xF?41F000
|
| 11:11 | Bertl_oO | where the 4 bits of ? are:
|
| 11:11 | Bertl_oO | 8 ... enable gain, 4 ... enable offset, 2 enable clip high, 1 enable clip low
|
| 11:12 | Bertl_oO | so in theory ?=F should be the desired setup, but for now it seems that ?=D is required
|
| 11:15 | Bertl_oO | building final stream now, will upload in a few minutes
|
| 11:26 | Bertl_oO | http://vserver.13thfloor.at/Stuff/AXIOM/BETA/cmv_hdmi3_gain.bit
|
| 11:26 | Bertl_oO | off to bed now ... have a good one everyone!
|
| 11:26 | Bertl_oO | changed nick to: Bertl_zZ
|
| 11:33 | niemand | left the channel |
| 11:34 | kaiserlich | joined the channel |
| 13:14 | se6astian|away | changed nick to: se6astian
|
| 13:21 | Spirit532__ | joined the channel |
| 13:29 | ItsMeLenny | left the channel |
| 14:05 | niemand | joined the channel |
| 14:06 | niemand | alexML, we decided not to use the axiom today
|
| 14:56 | niemand | left the channel |
| 15:07 | kaiserlich | left the channel |
| 15:19 | niemand | joined the channel |
| 16:30 | toxitobi | joined the channel |
| 16:31 | toxitobi | good evening
|
| 16:35 | se6astian | hello!
|
| 16:43 | jucar | joined the channel |
| 16:54 | niemand | left the channel |
| 17:11 | niemand | joined the channel |
| 17:19 | kaiserlich | joined the channel |
| 17:25 | jucar | left the channel |
| 17:30 | niemand | left the channel |
| 17:43 | kaiserlich | left the channel |
| 17:53 | Spirit532 | joined the channel |
| 17:57 | Spirit532__ | left the channel |
| 19:28 | alexML | Bertl_zZ: the latest firmware gives correct image with any value for the "?"
|
| 19:29 | alexML | 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
|
| 19:30 | alexML | there is still a "ghost" of that overlay when running mimg commands
|
| 19:32 | alexML | "./mimg -a -o /opt/IMG/newsmoke.rgb16" runs an animation on the left side of the screen
|
| 19:32 | alexML | and, in the end, the overlay disappears
|
| 19:39 | alexML | correction: the behavior of that "?" does not depend only on its value, but also on its history of values
|
| 19:40 | alexML | e.g. setting it from 0 to F (trying each value) after reboot gives the following:
|
| 19:42 | alexML | default: white screen; 0: blue screen with a small white line in the top-left corner; 1: no change; 2: the white line disappears;
|
| 19:43 | alexML | 3...7: no change; 8: normal image; any value after that: no change (still normal image)
|
| 19:46 | DGMurdockIII | joined the channel |
| 19:46 | alexML | starting with D after reboot gives a white rectangle (thin line, not filled) over about 1/3 of the screen (left side)
|
| 19:47 | alexML | changing to F => the rectangle disappears
|
| 19:47 | alexML | back to D => the rectangle does not reappear
|
| 19:48 | alexML | any value after that (0-F) => no change (normal image)
|
| 19:48 | alexML | so, it's a state machine, not very easy to reverse engineer :P
|
| 20:00 | BogdanXor | left the channel |
| 20:04 | kaiserlich | joined the channel |
| 20:24 | Bertl_zZ | changed nick to: Bertl
|
| 20:24 | Bertl | back now ...
|
| 20:27 | alexML | also, forgot to mention: I wasn't able to change the gains
|
| 20:28 | alexML | (script linked yesterday)
|
| 20:28 | Bertl | definitely doesn't happen here
|
| 20:28 | alexML | do you remember which overlay is supposed to show the axiom beta logo?
|
| 20:29 | Bertl | ./mimg -a -o /opt/IMG/overlay_04.rgb
|
| 20:30 | alexML | this adds the white rectangle I've described earlier
|
| 20:31 | alexML | 05 makes it a bit thicker
|
| 20:31 | alexML | 03 makes it disappear
|
| 20:31 | Bertl | yep, that's expected ... it is how the overlay looks
|
| 20:31 | Bertl | but the data is not in the sensor data
|
| 20:32 | alexML | ah, you changed the meaning of the overlay to encode pixel offsets?
|
| 20:32 | Bertl | not yet
|
| 20:32 | Bertl | regarding overlay, everything should be as before with the new bitstream
|
| 20:33 | alexML | yes, the problem is also present with the old bitstream (cmv_hdmi3_60.bit)
|
| 20:33 | Bertl | show me what you get in a snap or see on HDMI, then I can tell
|
| 20:33 | alexML | hold a second
|
| 20:39 | alexML | https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/overlay-issue.jpg
|
| 20:39 | alexML | this is with overlay_04
|
| 20:39 | Bertl | very interesting
|
| 20:40 | Bertl | can you upload the .rgb for me?
|
| 20:40 | alexML | overlay_05 just makes the border thicker
|
| 20:40 | alexML | I didn't change it
|
| 20:40 | Bertl | md5sum?
|
| 20:40 | alexML | c47ddc7b7607ad0623c9bdf15fbfd2d2 /opt/IMG/overlay_04.rgb
|
| 20:40 | Bertl | and the mimg tool?
|
| 20:40 | alexML | 8547e3c3b7abd98094eddae7baa7c07e /opt/IMG/overlay_05.rgb
|
| 20:41 | alexML | 653c33e76b5dabbeb40a4c400c61facd mimg
|
| 20:41 | Bertl | that is definitely different from any I have
|
| 20:42 | Bertl | let me quickly upload my version just to verify
|
| 20:42 | alexML | this is the image you sent me a while ago to unbrick the beta
|
| 20:43 | Bertl | it might have changed in the meantime, so I do not consider that a problem right away, we should just check it
|
| 20:43 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/BETA/mimg
|
| 20:43 | Bertl | 443840323893eb56171fb8b160ee9615 mimg
|
| 20:44 | alexML | which: no mimg in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)
|
| 20:44 | alexML | what the duck?
|
| 20:45 | Bertl | logout and login again, bash caches
|
| 20:45 | Bertl | an use ./mimg
|
| 20:45 | Bertl | *and
|
| 20:45 | Bertl | (after changing the permission for it to be executeable)
|
| 20:46 | alexML | I used that before too (copied from kick_manual)
|
| 20:46 | alexML | works now
|
| 20:46 | alexML | got the axiom beta logo
|
| 20:46 | Bertl | okay, so I conclude that your mimg has some 'other' features
|
| 20:47 | Bertl | maybe check with /opt/BERTL/mimg.c
|
| 20:47 | alexML | 368bea2b37cdb85c290c5883e8d9b006 /opt/BERTL/mimg.c
|
| 20:48 | alexML | ** Version 1.8
|
| 20:48 | Bertl | (yep, md5 matches)
|
| 20:48 | Bertl | ah, but that one indeed shows your picture
|
| 20:49 | alexML | hm, maybe I screwed it up when trying to recompile cmv_snap3
|
| 20:49 | DGMurdockIII | left the channel |
| 20:50 | Bertl | let me figure out why the mimg.c is actually broken
|
| 20:51 | alexML | recompiled from /opt/BERTL (make clean; make) and ran that one
|
| 20:51 | Bertl | the 'working' one is v1.6
|
| 20:51 | alexML | result: the overlay is no longer transparent
|
| 20:51 | alexML | and calling it multiple times mixes all the overlays
|
| 20:51 | Bertl | yeah, avoid it for now, I'll figure out what got broken
|
| 20:51 | alexML | e.g. overlapping "AXIOM \Beta" and "AXIOM Overlay"
|
| 20:52 | alexML | but at least the overlay is full-screen
|
| 20:53 | alexML | btw, looks like I've broken cmv_snap3.static when I've added the semaphore calls
|
| 20:53 | alexML | for some reason, it can't link with -static -lpthread
|
| 20:55 | alexML | found the answer: it must be -static -pthread (no idea why though): http://stackoverflow.com/questions/17928260/gcc-static-linking-error-for-lpthread
|
| 20:56 | BogdanXor | joined the channel |
| 21:01 | BogdanXor | left the channel |
| 21:03 | alexML | anyway, do you mind reminding me of the address of the LUT entries? (after matrix)
|
| 21:03 | Bertl | the gamma LUTs?
|
| 21:03 | alexML | yes
|
| 21:04 | Bertl | 0x80300000, 0x80304000, 0x80308000, and 0x8030C000
|
| 21:04 | alexML | one for each output channel, after matrix?
|
| 21:04 | Bertl | correct
|
| 21:05 | alexML | thanks
|
| 21:05 | Bertl | np
|
| 21:06 | alexML | ah, found lut_conf3
|
| 21:07 | Bertl | yep, it is used in gamma_conf.sh
|
| 21:07 | alexML | right
|
| 21:07 | alexML | btw, since you are here
|
| 21:08 | alexML | talked with se6astian a bit about recording the black columns on the HDMI (for the experimental raw mode)
|
| 21:08 | alexML | currently they are not used in this mode
|
| 21:08 | Bertl | okay?
|
| 21:08 | alexML | and here I have some figures showing what improvement they can give
|
| 21:09 | alexML | https://wiki.apertus.org/index.php/Pattern_Noise#Tests_on_a_dark_frame
|
| 21:09 | alexML | short summary:
|
| 21:09 | alexML | after dark frame, row noise stdev is 1.33
|
| 21:10 | alexML | after subtracting black columns with a scaling factor, it goes down to 0.82
|
| 21:10 | alexML | if I do some more complex processing (including looking at green channel imbalance), I can bring it down to 0.31
|
| 21:11 | alexML | so, the info from those columns can be used to make the row noise 4 times smaller
|
| 21:11 | Bertl | sounds great
|
| 21:11 | alexML | that means, I think we should record this info somehow
|
| 21:11 | alexML | but also keep it simple on the FPGA side
|
| 21:12 | alexML | what about averaging the 16 black columns (for each row), and outputting the result on one border column on the HDMI image?
|
| 21:12 | Bertl | tricky
|
| 21:13 | Bertl | the problem is, the black rows are not fetched for the HDMI output
|
| 21:13 | Bertl | *columns
|
| 21:13 | Bertl | so the data is not available in the output pipeline
|
| 21:13 | alexML | hm
|
| 21:14 | alexML | you effectively crop the image, right?
|
| 21:14 | Bertl | yes, the output pipeline is an address generator, which selects a 4x1080p data frame (or 1080p 4 sensel area)
|
| 21:16 | Bertl | it might be possible though, to average (or sum) the data on the arm cores and save it separately
|
| 21:18 | Bertl | we are talking about 1.5 megabit of 'raw' data here per frame
|
| 21:18 | Bertl | so roughly over one megabyte per second
|
| 21:19 | Bertl | if summed/averaged, it will be reduced by roughly a factor of 16
|
| 21:19 | alexML | can you point me to a way to sync the arm code with the image capture? (interrupt or whatever)
|
| 21:20 | Bertl | the snap code waits for a buffer change and extracts the currently displayed frame address
|
| 21:20 | jucar | joined the channel |
| 21:20 | alexML | alright
|
| 21:21 | alexML | and some address where I can write data to appear on the HDMI output?
|
| 21:21 | Bertl | so the easiest way is to map all frame buffers and wait for a register to change
|
| 21:21 | Bertl | once the buffer is on display, it is guaranteed not to change
|
| 21:21 | Bertl | and it is also guaranteed to be complete at the moment
|
| 21:21 | alexML | it can be the overlay as well
|
| 21:22 | Bertl | yes, you can always write to the overlay
|
| 21:22 | alexML | and having the data shifted by one frame shouldn't be a big deal (since it's a video stream, after all)
|
| 21:22 | Bertl | if you are fast, you can even write the data on the same buffer
|
| 21:22 | Bertl | let's say your code takes 500 lines to do the calculations
|
| 21:23 | Bertl | and you have an uncertainty of 250 lines for the start
|
| 21:23 | Bertl | that would leave you about 2000 lines to construct and write an overlay for the bottom line
|
| 21:35 | Alex_Chooks | left the channel |
| 21:42 | se6astian | off to bed
|
| 21:42 | se6astian | gnight!
|
| 21:42 | se6astian | changed nick to: se6astian|away
|
| 21:57 | BogdanXor | joined the channel |
| 22:01 | BogdanXor | left the channel |
| 22:47 | alexML | Bertl: I have some trouble with clipping, for example: ./mat4_conf 0 0 0 0 0 0 0 2.8 0 0.7500 0.7500 0 1 0 0 0
|
| 22:48 | alexML | ideally, the stuff that overflows should clip to white
|
| 22:48 | alexML | instead, I get bright red and magenta patches (I can take a screenshot if you need)
|
| 22:49 | Bertl | well, clipping is per channel, i.e. it clips the channel to the maximum value
|
| 22:49 | Bertl | doesn't affect the other channels though
|
| 22:50 | Bertl | but please show we what you see and what you expect
|
| 22:56 | alexML | https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/IMG_7311.jpg
|
| 22:56 | alexML | https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/IMG_7312.jpg
|
| 22:57 | Bertl | that looks like the clipping is disabled
|
| 22:57 | alexML | what happens is that blue wraps back to 0
|
| 22:57 | alexML | ok, how to enable it?
|
| 22:57 | alexML | fil_reg 11 0xF?41F000 has no effect for any value of ?
|
| 22:57 | alexML | (see the state machine described above)
|
| 22:58 | Bertl | fil_reg 11 0xFC?1F000
|
| 22:58 | BogdanXor | joined the channel |
| 22:58 | Bertl | did I paste the wrong place? ... that would explain the overlay issue
|
| 22:59 | Bertl | bits 20-21 are the clipping, bits 22-23 the enable bits
|
| 22:59 | alexML | 12:11 < Bertl_oO> fil_reg 11 0xF?41F000
|
| 22:59 | Bertl | bits 24-31 are the write mask for bursting the image into memory
|
| 23:00 | Bertl | they are usually 0xFC, i.e. they leave out the lower 16 bits
|
| 23:01 | Bertl | (the overlay)
|
| 23:01 | Bertl | but as I said, there is something wrong with the upper bound clipping on the new firmware
|
| 23:02 | alexML | ok, let me roll back
|
| 23:02 | Bertl | I can upload the source if you like play with that
|
| 23:02 | Bertl | simulation says everything is fine and gives the expected results, but, as so ofen, this doesn't match reality
|
| 23:03 | Bertl | *often
|
| 23:03 | BogdanXor | left the channel |
| 23:05 | alexML | back to old firmware, but still the clipping flag doesn't seem to get enabled
|
| 23:05 | alexML | default value for fil_reg 11 is 0xFC31F000
|
| 23:05 | Bertl | note that this is for the RCN clipping
|
| 23:05 | Bertl | there is another clipping for the matrix
|
| 23:05 | alexML | ah
|
| 23:06 | Bertl | https://wiki.apertus.org/index.php/AXIOM_Beta_Software#Clipping
|
| 23:09 | alexML | perfect, works as expected now, thanks
|
| 23:09 | Bertl | you're welcome!
|
| 23:12 | kaiserlich | left the channel |
| 23:19 | toxitobi | left the channel |
| 23:20 | alexML | Bertl: for mat4_conf.sh, can the offset be negative?
|
| 23:21 | alexML | ./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
|
| 23:21 | alexML | 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
|
| 23:21 | alexML | but with 4 warnings: dc: stack empty
|
| 23:21 | alexML | (repeated 4 times)
|
| 23:24 | alexML | found out that it wraps at 16
|
| 23:24 | alexML | so 16 is the same as 0, and 15 is -1
|
| 23:24 | alexML | now I'm not sure what the units are
|
| 23:27 | alexML | 0.5 maps - very roughly - to about 200 12-bit DN
|
| 23:36 | alexML | wait, offset is applied after multiplication?
|
| 23:37 | Bertl | I suggest to use the mat4_conf.py instead
|
| 23:37 | Bertl | it handles negative values as well as 3x3 matrices
|
| 23:37 | alexML | yep, looks like
|
| 23:43 | alexML | so, at gain 1, 15.89 = -0.11 maps to about -500
|
| 23:43 | alexML | 500/4095 = 0.12, so 1.0 = 4095?
|
| 23:45 | Bertl | matrix or LUT?
|
| 23:45 | alexML | I have trouble finding mat4_conf.py (neither google "mat4_conf.py" nor "locate mat4_conf.py" can find it)
|
| 23:45 | alexML | matrix
|
| 23:47 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/BETA/mat4_conf.py
|
| 23:48 | alexML | gracias
|
| 23:48 | Bertl | np
|
| 23:49 | alexML | syntax is different?
|
| 23:50 | Bertl | yes and no, it should be compatible for 16/20 values
|
| 23:51 | Bertl | but the order is reversed
|
| 23:51 | Bertl | i.e. previously the order was B G2 G1 R now it is R G1 G2 B (as one would expect)
|
| 23:51 | Bertl | similar to R G B for the 3x3 case
|
| 23:52 | alexML | got it
|
| 23:52 | alexML | so I'm now able to apply the matrix with some arbitrary black level as origin
|
| 00:00 | BogdanXor | joined the channel |
| 00:04 | BogdanXor | left the channel |
| 00:12 | alexML | ok, you may review the API: https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/set_wb.py
|
| 00:13 | alexML | still WIP, but setting WB as RGB multipliers appears to work
|
| 00:14 | Bertl | well, you can use mat4_conf.py rgain ggain bgain rblack gblack bblack
|
| 00:14 | Bertl | it will do the mapping to the 4x4 matrix for you
|
| 00:15 | alexML | yes, but I want to set a full matrix in the end, not just gains
|
| 00:16 | Bertl | I also think you are probably better off importing the mat4_conf.py parts like niemand did with the HSL stuff
|
| 00:17 | Bertl | http://sebix.at/tmp/rgbhsv.py
|