00:39 | Bertl | off to bed now ... have a good one everyone!
| |
06:14 | sb0 | left the channel | |
06:30 | sb0 | joined the channel | |
06:30 | niemand | joined the channel | |
06:39 | niemand | left the channel | |
08:36 | Bertl | morning folks!
| |
08:38 | sasha_c | joined the channel | |
08:46 | Bertl | evening sasha_c!
| |
08:49 | sasha_c | evening Bertl.
| |
08:50 | 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
| |
08:51 | Bertl | he shows up every now and then and we have a chat
| |
08:52 | sasha_c | Thanks, I'll try contacting him via email
| |
08:52 | Bertl | yes, that is definitely faster
| |
08:53 | sasha_c | Hey, it's very exciting to think about the proposed plans for the beta
| |
08:54 | sasha_c | Most of the work you've already done could be reimplemented into this, no?
| |
08:54 | Bertl | yes, indeed
| |
08:57 | sasha_c | Amazing
| |
09:32 | se6astian | joined the channel | |
09:38 | se6astian | good morning
| |
10:00 | sasha_c | left the channel | |
10:12 | sasha_c | joined the channel | |
10:41 | Bertl | hey se6astian! how's going?
| |
10:44 | se6astian | good, testing rcn profiles already
| |
10:44 | se6astian | looking good
| |
10:48 | Bertl | testing with my paper-roll-contraption, I've seen that at roughly 30% gray you seem to get the best results
| |
10:48 | Bertl | the problem is to get all channels to one even illumination peak
| |
10:48 | se6astian | lowering black sun protection seems to slightly improve noise, but it requires a recalibration of rcn
| |
10:48 | se6astian | I see
| |
10:49 | se6astian | maybe a LUT like the sawtooth can aid visually?
| |
10:49 | Bertl | yes, definitely, but I wasn't able to get even illumination here without the contraption
| |
10:50 | se6astian | can you take some photographs of the "thing" :)
| |
10:50 | Bertl | I will try, but it doesn't look very intersting
| |
10:51 | Bertl | it is basically a carton board roll like those in the middle of a toilet paper roll
| |
10:51 | Bertl | with a diffusor made out of a special slide foil
| |
10:51 | Bertl | at roughly 2-3cm from the sensor
| |
10:52 | Bertl | and a small board with an RGB (I tried individual red green blue leds as well) led, which is controlled via the pmod port
| |
10:52 | se6astian | I see
| |
10:53 | Bertl | the led has a wider angle (120°) and illuminates the diffusor, which refracts the light into the micro lenses of the sensor
| |
10:53 | se6astian | I just checked my histogram and was surprised that my green1 and green2 "bumps" are not on top of each other
| |
10:53 | se6astian | is that a potential sideeffect of the RCN?
| |
10:53 | Bertl | yes, of course
| |
10:53 | Bertl | if you adjust it with uneven lighting in the red/blue
| |
10:54 | Bertl | the green will be 'corrected' apart
| |
10:54 | se6astian | I see
| |
10:54 | se6astian | that could be used as a good indicator of the profile results
| |
11:03 | se6astian | would a good profile result in fully alligned bumps?
| |
11:05 | Bertl | if the illumination is even, yes
| |
11:05 | Bertl | i.e. even illumination -> gauss curves at the same location
| |
11:05 | Bertl | the RCN then narrows the peaks
| |
11:05 | se6astian | I see
| |
11:05 | Bertl | i.e. they get higher and less wide in the slope
| |
11:06 | se6astian | can I clear the current rcn profile with loading /dev/null with pmem -B 0x60000000 -m W0x60300000+0x8000/W ?
| |
11:06 | se6astian | aka pmem -B 0x60000000 -m W0x60300000+0x8000/W < /dev/null
| |
11:08 | Bertl | pmem -B 0x60000000 -m Z0x60300000+0x8000
| |
11:10 | se6astian | danke
| |
11:10 | Bertl | you're welcome!
| |
11:15 | se6astian | added to wiki: https://wiki.apertus.org/index.php?title=Axiom_Alpha_Software#Row.2FColoumn_Noise_Correction
| |
11:17 | se6astian | hmm, seems running "pmem -B 0x60000000 -m Z0x60300000+0x8000" just crashed my camera
| |
11:17 | sasha_c | left the channel | |
11:17 | se6astian | I did turn off image acquisition beforehand but left the histogram open (which runs snaps on its own afaik)
| |
11:18 | Bertl | shouldn't have any effect
| |
11:19 | Bertl | hmm, but obviously it has
| |
11:19 | Bertl | i.e. I can reproduce it here
| |
11:20 | Bertl | will investigate
| |
11:21 | Bertl | ah, yes, bug in pmem, sec
| |
11:22 | se6astian | after reboot I noticed that my green bumps also down line up without any rcn profile
| |
11:22 | se6astian | I just checked the offsets but they are equal
| |
11:22 | se6astian | also the matrix is fine
| |
11:22 | se6astian | maybe the channels (numbers changed)?
| |
11:22 | Bertl | how much do they differ?
| |
11:23 | Bertl | channel numbers only change when you flip or do not flip
| |
11:23 | se6astian | screenshot, one sec
| |
11:24 | se6astian | https://cloud.gerade.org/public.php?service=gallery&t=88644302ffde4f6e5659627a3c8bbf32&path=//Axiom#88644302ffde4f6e5659627a3c8bbf32/Axiom/alpha/histogram02.jpg
| |
11:25 | se6astian | image flipping is set to 2 = flip in Y (recommended)
| |
11:25 | Bertl | okay, that is way off, i.e. your channels are wrong
| |
11:25 | Bertl | the blue and red look like the greens
| |
11:25 | Bertl | most likely the first green is the blue and the second the red
| |
11:26 | se6astian | if I set flipping to off = 0 it seems to be correct again
| |
11:26 | se6astian | in the histogram
| |
11:26 | Bertl | so you do not account for the flipping then :)
| |
11:26 | se6astian | not yet
| |
11:27 | se6astian | I assume flipping was set to 0 by default in the beginning? (when I created the histogram code)
| |
11:28 | Bertl | probably, back in the early days :)
| |
11:28 | se6astian | ok :)
| |
11:36 | Bertl | btw, the cmv_hist3 now supports the -C option
| |
11:36 | Bertl | which allows you to specify a percentage of the width/height which will get sampled
| |
11:37 | Bertl | e.g. -C50 will only sample the center 1/4th of the entire image
| |
11:39 | se6astian | nice, parameter is percent of height/width in center?
| |
11:39 | Bertl | yes, default is 100
| |
11:43 | se6astian | great
| |
11:43 | se6astian | new pmem on 13thfloor?
| |
11:45 | Bertl | still working on it
| |
11:45 | Bertl | it seems to be a problem with the glibc not with my code
| |
11:45 | se6astian | ah ok
| |
11:46 | Bertl | or maybe not ...
| |
11:51 | Bertl | okay, I guess I fixed it so far
| |
11:52 | Bertl | checking now
| |
11:52 | se6astian | 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
| |
11:55 | Bertl | strange things happen here too
| |
11:56 | philippej | joined the channel | |
11:56 | Bertl | maybe the xilinx tools built a bad image ...
| |
12:04 | se6astian | I also seem to have solid color areas in over/under expsoure areas after rcn calibration
| |
12:05 | se6astian | I did enable clipping though
| |
12:10 | Bertl | let me rebuild the image, just to make sure
| |
12:12 | Bertl | pmem has been updated, to clear the rcn you probably want to use ./cmv_rcn3 -z
| |
12:13 | Bertl | you can do it with pmem though, but the command is:
| |
12:13 | Bertl | pmem -B 0x60300000 -m F0x60300000+0x8000=0/W
| |
12:13 | Bertl | i.e. zero does not work, as it uses undefined access sizes
| |
12:16 | se6astian | ok
| |
12:23 | se6astian | updated wiki
| |
12:28 | philippej | left the channel | |
12:39 | Bertl | okay, bitstream has been updated, also wmem_conf.sh changed
| |
12:41 | Bertl | btw, how do you enable the rcn clip?
| |
12:43 | se6astian | fil_reg 11 0xFC31F000
| |
12:43 | Bertl | okay, that's fine :)
| |
12:44 | Bertl | ah I see, the upper limit clip doesn't work as expected
| |
12:52 | sasha_c | joined the channel | |
13:00 | se6astian | PLR GUI ready: https://twitter.com/ApertusOSCinema/status/444109187711107072
| |
13:00 | Bertl | PLR stands for?
| |
13:02 | se6astian | piecewise linear response
| |
13:03 | Bertl | ah, nice
| |
13:24 | se6astian1 | joined the channel | |
13:25 | se6astian | left the channel | |
14:06 | troy_s | left the channel | |
14:08 | troy_s | joined the channel | |
14:09 | sasha_c | left the channel | |
14:22 | troy_s | greets all
| |
14:23 | troy_s | se6astian1: You made progress on the >70% RGB values!?!
| |
14:25 | danieel | now we know what caused the delay of BM cameras :)
| |
14:25 | Bertl | I think we are making good progress
| |
14:25 | troy_s | Bertl: Fantastic.
| |
14:25 | Bertl | I build a contraption which allows to measure the sensor without the illumination problem
| |
14:25 | troy_s | Bertl: I can pry a little time as soon as you think you have it on the handle.
| |
14:26 | troy_s | Bertl: The >70% woes?
| |
14:26 | Bertl | I'm currently fixing a few minor bugs in the image/rcn pipeline
| |
14:26 | troy_s | Bertl: Were there some there that were revealed in our tests?
| |
14:26 | Bertl | well, yes, we have a linearization LUT now, and the contraption allows me to evenly illuminate the sensor with selected colors
| |
14:27 | Bertl | so testing the linear range is rather simple
| |
14:27 | troy_s | Bertl: If se6astian1 desperately wants a matrix, we can use the existing 4.5 shaper + matrix we have.
| |
14:28 | troy_s | Bertl: You built a bellows?
| |
14:29 | Bertl | well, kind of .. it is a simple tube (paper) with a diffusor in the middle between the sensor and a very precisely controlled led illumination
| |
14:30 | troy_s | Bertl: Any tests that further your hypothesis?
| |
14:30 | troy_s | Bertl: (that >70 RGB the values are junk?)
| |
14:30 | Bertl | the leds are synchronized with the frame request trigger
| |
14:31 | Bertl | so I can control how much light hits the sensor per channel
| |
14:31 | troy_s | Bertl: Ah.
| |
14:31 | troy_s | Bertl: And this allows you to calibrate the response?
| |
14:31 | Bertl | yes, as I know what I expect and what I get from the sensor
| |
14:32 | danieel | so you get a linearization lut - but is it stable? exposure time / temperature wise
| |
14:33 | Bertl | time will tell :)
| |
14:33 | troy_s | danieel: The sensor is _mostly_ (68%?) linear as expected.
| |
14:33 | troy_s | danieel: It is the >70% RGB values that are causing the worst fits that cannot be shaped out.
| |
14:33 | troy_s | (the floor is uniform)
| |
15:22 | Bertl | se6astian1: okay, there is definitely another bug in the rcn code, have to simulate this and see where it goes wrong
| |
15:38 | se6astian1 | ok, thanks!
| |
15:39 | rainer_vie | joined the channel | |
15:43 | rainer_vie | \o/
| |
15:43 | Bertl | hey, how's going?
| |
15:45 | rainer_vie | thanks fine... yourself?
| |
15:45 | Bertl | fine so far, on the bug hunt atm :)
| |
15:46 | se6astian1 | Hi rainer_vie, I just invited you to the axiom-dev mailing list
| |
15:46 | rainer_vie | oh great...
| |
15:47 | rainer_vie | debugging is sometimes a nice work and sometimes it can be pain in the a...
| |
15:47 | rainer_vie | tomorrow i have the first chat with departure funding
| |
15:48 | rainer_vie | hope to get a meeting with them in a week or so
| |
15:48 | rainer_vie | till then i need to make a small presentation
| |
15:50 | se6astian1 | for the media copying/viewing vault?
| |
15:50 | rainer_vie | btw I finished a first version of my Clipfinder Program http://dcs.co.at/pics/Clipfinder.jpg
| |
15:50 | rainer_vie | yes... I want to couple it with openCine
| |
15:51 | rainer_vie | Malte had a good point....
| |
15:52 | rainer_vie | one tiny board with an lcd which copy/hashes only
| |
15:52 | rainer_vie | and a bigger one which is scaleable
| |
15:53 | rainer_vie | the bigger one should then have also the openCIne on it
| |
15:54 | rainer_vie | on the HP of openCine it is very good described what it should can... so then there should be a Hardware
| |
15:54 | rainer_vie | which is portable and rugged solid
| |
15:56 | se6astian1 | sounds good
| |
15:57 | rainer_vie | I hope that the guy at departure thinks that also... :)
| |
15:58 | se6astian1 | 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?
| |
15:59 | rainer_vie | yeah thats some gremium which makes the decision... the good thing with departure is, that they found 50%... so I will calculate with the double to get whats needed :)
| |
16:01 | rainer_vie | bertl what do you think will it take on manpower to develop openCine in a basic version???
| |
16:02 | rainer_vie | or sebastian...
| |
16:04 | Bertl | rainer_vie: no idea
| |
16:15 | se6astian1 | hard to say
| |
16:16 | se6astian1 | actually most of the software already exists
| |
16:16 | se6astian1 | and just needs to be "glued" together :)
| |
16:16 | se6astian1 | so for getting DNG realtime playback its probably very little work/time if you find someone who knows what he is doing
| |
16:17 | se6astian1 | the more you dig into color grading then the more complex it will get
| |
16:18 | rainer_vie | the first version should have only settings for debayer
| |
16:18 | rainer_vie | a next version could have then a primary grade option I think
| |
16:18 | rainer_vie | displaying in realtime waveform etc. will also take time I think
| |
16:19 | rainer_vie | do you know shotcut ?
| |
16:23 | rainer_vie | it has a primary color correction already inside... and there are various open vfx projects I found which are dealing with that...
| |
16:32 | se6astian1 | I did not try it yet
| |
16:32 | se6astian1 | but since these are all open source tools, thats the glueing together I mean
| |
16:34 | rainer_vie | sure...
| |
16:55 | troy_s | left the channel | |
16:56 | rainer_vie | left the channel | |
16:57 | troy_s | joined the channel | |
16:57 | rainer_vie | joined the channel | |
17:04 | se6astian1 | after some testing it appears that the histogram seems to be crashing the camera mostly
| |
17:05 | se6astian1 | histogram plus automatic image acquisation at the same time maybe
| |
17:07 | Bertl | do you trigger a snap in the histogramm acquisition?
| |
17:07 | Bertl | if so, try leaving the -s out
| |
17:08 | Bertl | IIRC, the hist code probably needs an update
| |
17:08 | se6astian1 | I removed the -s option as soon as the automatic acquisition was implemented
| |
17:09 | se6astian1 | yes crashed again when I had the histogram page openend and started automatic acuqisition
| |
17:09 | se6astian1 | ok time for cooking dinner then :)
| |
17:10 | Bertl | and crash means?
| |
17:20 | se6astian1 | ssh stops responding, webserver stps responding, FPGA seems to continue operation
| |
17:20 | se6astian1 | so a CPU crash I presume
| |
17:20 | se6astian1 | *stops
| |
17:22 | Bertl | okay, that sounds more like a stall in the AXI bus then
| |
17:23 | Bertl | could you try to send a magic-sysrq when this happens again via the serial console?
| |
17:26 | se6astian1 | sure, how do I dod that?
| |
17:27 | Bertl | really depends on your serial console terminal app
| |
17:27 | Bertl | http://en.wikipedia.org/wiki/Magic_SysRq_key
| |
17:28 | Bertl | with minicom, it is CTRL-A Z F
| |
17:29 | se6astian1 | I see, I will look into it
| |
17:30 | Bertl | i.e. with a typical terminal emulator, it's just sendig a break character
| |
17:31 | Bertl | (followed by e.g. 'h')
| |
17:31 | se6astian1 | I am using putty
| |
17:33 | Bertl | for the serial console?
| |
17:49 | se6astian1 | yes
| |
17:49 | Bertl | well, no idea then, maybe check the help?
| |
17:49 | se6astian1 | will do
| |
17:49 | Bertl | (look for sending a break character)
| |
17:54 | se6astian1 | found it
| |
17:54 | se6astian1 | [ 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)
| |
17:55 | Bertl | yep, looks good
| |
17:55 | Bertl | try this when it 'crashes'
| |
17:55 | se6astian1 | ok
| |
17:56 | Bertl | btw, new bitstream and tools shortly
| |
17:56 | se6astian1 | great
| |
17:56 | se6astian1 | crashed, does not accept any input anymore
| |
17:57 | Bertl | yeah, then it is probably the AXI splitter
| |
17:57 | se6astian1 | ok
| |
17:57 | Bertl | try to avoid writing/reading from more than one register at a time
| |
17:58 | Bertl | mikkael is already looking into it, AFAIC
| |
18:02 | se6astian1 | thanks
| |
18:07 | Bertl | okay, bitstream updated, rcn3 as well
| |
18:07 | Bertl | there should be no clipping issues anymore, but the rcn data has changed
| |
18:08 | Bertl | i.e. you need to recreate a profile, but the rcn3 tool should do a good job now
| |
18:08 | se6astian1 | thanks
| |
18:08 | se6astian1 | will try
| |
18:14 | se6astian1 | but I do need to enable clipping still before right?
| |
18:19 | Bertl | before what?
| |
18:20 | Bertl | well, you need to enable clipping if you want the pipeline to clip :)
| |
18:22 | rainer_vie | bertl your bayer pattern is 4 pixel ?
| |
18:22 | Bertl | yes, RG/GB
| |
18:22 | rainer_vie | dcraw can't decode with my command line
| |
18:23 | Bertl | se6astian1: new rcn3 tool, which can now take several samples
| |
18:23 | Bertl | i.e. just specify -N 3 or -N 5 (it will average the measurements)
| |
18:23 | Bertl | rainer_vie: I didn't find a way to actually feed the data into dcraw back then
| |
18:24 | Bertl | it seemed to me, that it doesn't handle 'raw' data :)
| |
18:24 | rainer_vie | with what do you debayer the raw stills ?
| |
18:24 | Bertl | imagemagick
| |
18:25 | rainer_vie | ohhh
| |
18:25 | Bertl | https://wiki.apertus.org/index.php?title=Axiom_Alpha_Software#Simple_debayer_with_ImageMagick:
| |
18:25 | se6astian1 | ah nice, I just ran a test with clipping enabled and a single sample
| |
18:25 | niemand | joined the channel | |
18:25 | Bertl | wb niemand!
| |
18:26 | niemand | hi Bertl
| |
18:27 | se6astian1 | single snap works good, a bit dark now without daylight so might not be optimal from exposure level pov
| |
18:27 | se6astian1 | will test with some more light and multiple snaps now
| |
18:29 | rainer_vie | Bertl, Imagemagick says it doesn't know the -clone
| |
18:29 | Bertl | what version?
| |
18:30 | rainer_vie | 1.3.16
| |
18:31 | Bertl | hmm, maybe you want to update, 6.7.5 here :)
| |
18:31 | rainer_vie | I installed it with apt-get so its a very old version
| |
18:32 | Bertl | no, it's an ancient version :)
| |
18:33 | Bertl | but the 1.3.16 version looks like a replacement
| |
18:33 | Bertl | i.e. maybe a supposed to be compatible package?
| |
18:34 | Bertl | yeah, that's graphicsmagic
| |
18:34 | Bertl | a branch/fork from imagemagick 5.5.2 (2002)
| |
18:36 | Bertl | but you might ask the graphicsmagic maintainers how to achieve similar (if possible)
| |
18:36 | rainer_vie | right I'm compiling the actual version
| |
18:37 | Bertl | there should be a package in debian/ubuntu I guess
| |
18:37 | niemand | rainer_vie: s/actual/current/
| |
18:37 | Bertl | anything between 6.8 and 7.6 should do
| |
18:38 | niemand | or 'latest'. but actual is 'tatsächlich' :P
| |
18:40 | se6astian1 | just ran rcn with N 5
| |
18:40 | se6astian1 | very interesting results
| |
18:40 | Bertl | did you update the tool?
| |
18:40 | Bertl | if everything is black, then no :)
| |
18:40 | se6astian1 | I did update
| |
18:41 | Bertl | 2f3792f25ce3ace3706a4473ace372e6 cmv_rcn3
| |
18:41 | se6astian1 | FPN is so heavily reduced that its not even ah you updated it again ;)
| |
18:41 | se6astian1 | I have an 20 minute old version then
| |
18:41 | Bertl | ancient!
| |
18:41 | Bertl | :)
| |
18:42 | se6astian1 | the results are still interesting, with N5 the FPN is reduced so strongly that its not even really visible anymore when I boost the contrast to the max
| |
18:42 | se6astian1 | but I noticed that it also does auto white balance at the same time ;)
| |
18:42 | Bertl | wait for the actual results :)
| |
18:42 | se6astian1 | before the wall had a yellowish/red tint from the tungsten light
| |
18:42 | se6astian1 | after the profiling it was pure white :)
| |
18:43 | Bertl | yes, as I said, you want to get even illumination over all channels
| |
18:43 | Bertl | (before you run rcn3)
| |
18:43 | se6astian1 | so I need to adjust the matrix ?
| |
18:43 | Bertl | matrix is not involved
| |
18:43 | Bertl | i.e. it is in the output pipeline
| |
18:43 | se6astian1 | I have no daylight anymore now
| |
18:44 | se6astian1 | how can I get evenly exposed channels....
| |
18:44 | Bertl | no idea, but for now you probably have to live with unwanted white balance :)
| |
18:44 | se6astian1 | ok :)
| |
18:45 | se6astian1 | the command to save the FPN profile changed as well didnt it?
| |
18:45 | se6astian1 | pmem complains about wrong parameters with the command on the wiki
| |
18:46 | Bertl | what's the command on the wiki?
| |
18:46 | se6astian1 | ah wait
| |
18:46 | se6astian1 | my bad
| |
18:46 | se6astian1 | putty edited the command unintentionally
| |
18:46 | Bertl | tsts
| |
18:47 | se6astian1 | updating again now :)
| |
18:47 | se6astian1 | you compile and upload faster than I can download and update my camera
| |
18:47 | se6astian1 | :D
| |
18:48 | se6astian1 | is the source of those cmv_* tools on github already btw?
| |
18:48 | rainer_vie | sebastian you need a 6k HMI in your livingroom
| |
18:49 | rainer_vie | then its good illuminated
| |
18:49 | se6astian1 | and well heated :)
| |
18:49 | Bertl | nope, haven't cleaned up the tools yet
| |
18:49 | se6astian1 | ok
| |
18:56 | se6astian1 | the very latest version of the rcn tool does not do whitebalance changes anymore
| |
18:56 | Bertl | it will do it implicitely but very subtle
| |
18:57 | Bertl | i.e. differences in brightness across the paired row/col channels will cause the tool to try to compensate
| |
18:57 | se6astian1 | and the pattern is a bit more visible again ... :)
| |
18:57 | se6astian1 | maybe because I changed the lighting source now
| |
18:57 | se6astian1 | maybe best if I retry this with sunlight
| |
18:58 | Bertl | also be careful, the rcn cannot help with over/under exposure
| |
18:58 | Bertl | i.e. if you have a perfectly corrected 50% gray image
| |
18:58 | Bertl | and then you switch to white (overexposed) the colum/row noise will be visible again
| |
18:59 | Bertl | you can compensate for this with the LUTs before the RCN correction
| |
19:00 | Bertl | I think I will shift the range by 2 bits there, so that you can go over and under the expected values by a factor of 4
| |
19:03 | rainer_vie | all libraries in /usr/local/lib but when calling convert it does'nt find libMagickWand-6.Q16.so.2
| |
19:03 | Bertl | probably your library path is not configured to include /usr/local/lib
| |
19:03 | Bertl | what distro are you running?
| |
19:04 | rainer_vie | ubuntu 13.10
| |
19:04 | rainer_vie | I could copy all them from usr/local/lib to usr/lib
| |
19:04 | Bertl | https://launchpad.net/ubuntu/saucy/+package/imagemagick
| |
19:04 | Bertl | why not just install the imagemagick package?
| |
19:05 | rainer_vie | it is 6.7 not 6.8
| |
19:06 | Bertl | okay, so give it a try then :)
| |
19:06 | Bertl | btw, here is a walk through how to build a newer package
| |
19:06 | Bertl | http://namhuy.net/1730/install-imagemagick-6-8-linux-mint-ubuntu.html
| |
19:07 | rainer_vie | kk copied all from /usr/local/lib to /usr/lib now it works
| |
19:07 | Bertl | ouch, okay :)
| |
19:08 | rainer_vie | great... but the debayer takes time....
| |
19:09 | Bertl | it's a lot of data and probably depends on the available memory
| |
19:10 | rainer_vie | sure
| |
19:12 | rainer_vie | is the sensor 4:3 ? aspect is 1,333
| |
19:12 | Bertl | yes
| |
19:13 | rainer_vie | oh nice, so we can use anamorphic lenses as well
| |
19:13 | rainer_vie | for 16:9 you scale the image or read a window?
| |
19:14 | rainer_vie | ahhh
| |
19:14 | rainer_vie | forget it
| |
19:16 | rainer_vie | I meant do you read always the hole sensor array or a window if you need 16:9.
| |
19:16 | Bertl | there is a simple way to define vertical regions
| |
19:16 | Bertl | i.e. stripes, which get transferred
| |
19:17 | Bertl | se6astian1: which reminds me, that we should test this feature
| |
19:18 | Bertl | (as it will increase the framerate or possible exposure values)
| |
19:19 | rainer_vie | ^ ^ in most cases we shoot 16:9... as conform to the DCI spec a 1:1,9 window will be also interresting
| |
19:19 | Bertl | 1:1.9?
| |
19:20 | rainer_vie | in digital cinemas the projectors have three formats:
| |
19:20 | se6astian1 | yes, will do soon
| |
19:20 | rainer_vie | full, flat and scope
| |
19:20 | Bertl | rainer_vie: sounds strange, that would be 1600x3072?
| |
19:21 | niemand | left the channel | |
19:22 | rainer_vie | 2048x1080 or 4096x2160 is the full format
| |
19:23 | niemand | joined the channel | |
19:23 | Bertl | ah, that's 1.9 then (or 1.9:1)
| |
19:23 | rainer_vie | 1998x1080 or 3996x2160 is flat (Academy 1:1,85)
| |
19:24 | Bertl | why are you switching H and V (i.e. inverting the fraction?)
| |
19:25 | rainer_vie | right 1,9:1 or 1,85:1 or 2,39:1
| |
19:26 | rainer_vie | so thats the worldwide aspect ratios in cinema
| |
19:26 | Bertl | yeah, no problem with any of those I guess
| |
19:26 | rainer_vie | 1,85:1 and widescreen 2,39:1 is common
| |
19:27 | rainer_vie | also very common is to use the hole sensor with 1,33 : 1 and scale it then to widescreen
| |
19:27 | rainer_vie | with anamorphic lenses
| |
19:28 | Bertl | yes, I hear about this practice
| |
19:29 | rainer_vie | but it is not very often used in europe it is more a hollywood style ;)
| |
19:31 | Bertl | I've heard it gives a specific 'look'
| |
19:31 | Bertl | not that I've ever actively noticed to be honest :)
| |
19:32 | Bertl | se6astian1: new bitstream and rcn3 tool, also new linear_conf.sh and setup.sh defaults
| |
19:32 | rainer_vie | yes, but the newer anamorphotic lenses are better corrected, so they made filters for the anamorphic lens flare... this horizontal flares... weired thingsd
| |
19:33 | Bertl | se6astian1: they allow now to stretch the 'linear space' about a factor of 4 over the resulting range, thus allowing for proper clipping on over and under exposure (i.e. to white and black)
| |
19:34 | Bertl | you can easily play with the feature by using linear_conf.sh 0.30 (for example)
| |
19:34 | Bertl | 0.25 is default, second argument is an offset
| |
19:34 | Bertl | I will make the 0.25 = 1.0 by scaling the input value when we see that 2 bit is a good choice
| |
19:35 | Bertl | rainer_vie: yeah, I can imagine that flare effects look slightly different
| |
19:36 | Bertl | so, let's find the linear range now :)
| |
19:36 | rainer_vie | ok... so I will play with my listobjects in my python project
| |
19:37 | rainer_vie | that will get funny after three glasses of red wine
| |
19:37 | sb0 | left the channel | |
19:37 | niemand | left the channel | |
19:38 | Bertl | :)
| |
19:39 | sb0 | joined the channel | |
19:40 | sasha_c | joined the channel | |
19:42 | Bertl | morning sasha_c!
| |
19:43 | sasha_c | morning Bertl (even though it's 9:43pm in Vienna, hehe)
| |
19:44 | Bertl | https://github.com/apertus-open-source-cinema/alpha-software/blob/master/cmv_hdmi2/registers.txt
| |
19:45 | Bertl | it isn't complete yet, but it describes the first two register blocks :)
| |
19:45 | sasha_c | 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.
| |
19:45 | Bertl | I'll try to complete it in the next few hours
| |
19:46 | Bertl | it would be nice to find a somewhat appealing table format for the wiki
| |
19:47 | Bertl | similar to what I did here: https://wiki.apertus.org/index.php?title=ZedBoard
| |
19:48 | Bertl | you might want to look at the CMV12k datasheet, the format used there is not uncommon and I think somewhat easy to read
| |
19:48 | sasha_c | I see. And I'll add this under the CMV12000 page: https://wiki.apertus.org/index.php?title=CMV12000
| |
19:48 | Bertl | no, make a new one
| |
19:48 | sasha_c | ok
| |
19:48 | Bertl | the CMV12k registers are only a small part
| |
19:58 | sasha_c | I've been able to dig up Reference:CMV12000-datasheet-v6 from my inbox, but this is dated from 2012. Is there a more recent data sheet?
| |
20:02 | Bertl | yes, there is on github, but it hasn't changed much layout wise
| |
20:03 | Bertl | so for having a reference how registers might be documented in a table it should suffice
| |
20:03 | sasha_c | cool, thanks
| |
20:04 | Bertl | for the actual register values (we will transcribe them sooner or later to the wiki as well) I'd say we wait till we know more about the sensor
| |
20:04 | sasha_c | ok
| |
20:04 | Bertl | so primary focus is on the registers we created/provide
| |
20:31 | sasha_c | Is this suitable: https://wiki.apertus.org/index.php?title=CMV12000_to_HDMI_registers
| |
20:31 | sasha_c | (for a start)
| |
20:33 | Bertl | hmm, well, the table might work for the actual registers
| |
20:34 | Bertl | but you are currently listing the register blocks
| |
20:34 | Bertl | (so the heading is misleading)
| |
20:34 | sasha_c | I'll change the heading to "CMV12000 Register Blocks" then?
| |
20:35 | Bertl | i.e. the xxxxx means that there are addresses where the 'x' are
| |
20:35 | Bertl | I'd suggest to reduce this specific table to only two columns
| |
20:35 | Bertl | the address and the description
| |
20:35 | Bertl | default values do not make much sense, and we have no real name for the blocks
| |
20:36 | Bertl | https://wiki.apertus.org/index.php?title=Axiom_Alpha_Software#Register_Memory_Space
| |
20:36 | Bertl | maybe this helps to get an idea what I'm talking about
| |
20:37 | sasha_c | yes, it does. Just made the changes to the wiki. How does it look now then?
| |
20:38 | Bertl | reduce the heading to 'Address' and 'Description' and we're fine
| |
20:39 | Bertl | note that the 4 column table you had is fine for the actual registers
| |
20:39 | sasha_c | ok, nice
| |
20:42 | Bertl | http://www.analog.com/static/imported-files/eval_boards/ADV7511_Programming_Guide.pdf
| |
20:42 | Bertl | check out the register tables there, they have some nice/usable ideas as well
| |
20:42 | Bertl | I'm not sure the RW/RO column makes much sense in retrospect, because we have clearly divided ranges
| |
20:43 | Bertl | i.e. either a block is read/write or read only or split somewhere
| |
20:44 | Bertl | 0x60000000 - 0x60100018 all read only
| |
20:44 | Bertl | 0x60100000 - 0x60100018 all read only
| |
20:44 | Bertl | I mean
| |
20:44 | sasha_c | ok, I think I understand this
| |
20:44 | Bertl | 0x60100100 - 0x6010013C all read/write
| |
20:45 | Bertl | the bitmasks presented in the adv7511 datasheet might be useful
| |
20:45 | Bertl | i.e. the ***110**** style
| |
20:45 | Bertl | if it can be visualized properly
| |
20:46 | Bertl | but it is in no way necessary
| |
20:56 | troy_s | rainer_vie: Shotcut is a joke for grading.
| |
20:56 | troy_s | rainer_vie: The larger issue with grading is intra application transfer: CDL, LUT formats, etc. etc.
| |
20:59 | troy_s | Bertl se6astian1 Does it mean we get new daylight charts?
| |
20:59 | troy_s | (or any chart)
| |
20:59 | troy_s | :)
| |
20:59 | rainer_vie | sure... I pointed that out, because it has a grading function... we definitely have an other aproach
| |
20:59 | Bertl | troy_s: yes, I'd say so, just needs some daylight I guess :)
| |
21:00 | troy_s | Bertl: Woop!
| |
21:00 | troy_s | Bertl: Good progress?
| |
21:00 | Bertl | well, I have one strange issue left with the linearization
| |
21:01 | Bertl | but I think it actually is a problem with the dsp block I'm using
| |
21:01 | Bertl | so should be sorted out soon
| |
21:01 | rainer_vie | final raw format will be DNG right ?
| |
21:02 | Bertl | maybe, maybe not
| |
21:02 | rainer_vie | what could it be else?
| |
21:03 | Bertl | raw frames, raw streams for example
| |
21:03 | Bertl | our very personal switch byte 7 with byt 23 format?
| |
21:04 | Bertl | *byte
| |
21:04 | Bertl | I don't know, I haven't looked into possible container formats yet
| |
21:04 | Bertl | troy_s: btw, we have a new .raw12 format :)
| |
21:07 | rainer_vie | DNG is currently a common format which is supported by a lot of applications out there
| |
21:11 | rainer_vie | 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/
| |
21:13 | Bertl | okay?
| |
21:14 | rainer_vie | regarding troy... it would be cool to make luts for color space conversions for REC709, DCI XYZ etc....
| |
21:15 | Bertl | I think the matrix is better suited for this purpose
| |
21:16 | rainer_vie | you mean on the camera or later on ?
| |
21:17 | Bertl | doesn't matter, it should be a linear transform, no?
| |
21:19 | Bertl | what I mean is, no LUT required for linear color space transformations
| |
21:24 | rainer_vie | so you get the 12 bit from the sensor and convert it to 16 bit and debayer it... the final picture is a linear 16 bit image right?
| |
21:24 | Bertl | no, we currently do not debayer it at all
| |
21:24 | Bertl | the sensor pipeline does FPN correction and scaling of the linear range
| |
21:25 | rainer_vie | yes but for the video outputs (HDMI and SDI) and later on on the raw conversion it's debayered
| |
21:26 | Bertl | the hdmi pipeline uses the RG/GB values from each bayer block to apply a color transformation, gamma LUT, possible overlay and sensds the data as RGB 242 to the encoder
| |
21:31 | rainer_vie | ok... so the picture which is displayed on the hdmi interface will be the same as debayered currently for example with imagemagick
| |
21:31 | Bertl | very similar, yes
| |
21:31 | Bertl | the hdmi encoder does some interpolation as well
| |
21:31 | rainer_vie | sure
| |
21:32 | Bertl | and we still have to configure YCrCb to test if it improves the image
| |
21:32 | rainer_vie | component signal will be needed for SDI anyway
| |
21:33 | rainer_vie | 10 bit 4:2:2 YCbCr would be great
| |
21:34 | rainer_vie | will it be possible to give out progressive scan and psf ?
| |
21:34 | rainer_vie | switchable
| |
21:34 | Bertl | well, SDI doesn't require YCbCr per se, but the conversion is already implemented, so not a big deal
| |
21:35 | rainer_vie | yeah... but most of the external SDI equipment will work fine with component signal
| |
21:36 | Bertl | yes, I'm sure we will open a whole new can of worms with SDI like we did with HDMI and existing equippment :)
| |
21:36 | rainer_vie | :) I'm sure you will get this working
| |
21:37 | Bertl | but nothing I consider a real problem there, it mostly will be a lot of work to figure out what this or that equippment wants/needs/expects
| |
21:37 | Bertl | of course, open interfaces will be supported sooner than proprietary variations
| |
21:39 | rainer_vie | yes thats a big point... only think that on the interfaces like SDI you have standard framerates
| |
21:42 | se6astian1 | time for bed
| |
21:42 | se6astian1 | good night!
| |
21:42 | rainer_vie | bb sleep well
| |
21:43 | se6astian1 | left the channel | |
21:45 | rainer_vie | so a maximum of 60fps is possible I think on SDI currently
| |
21:48 | rainer_vie | couch time... wish you all the best!
| |
21:48 | rainer_vie | bb
| |
21:48 | Bertl | cya
| |
21:48 | rainer_vie | :)
| |
21:48 | rainer_vie | left the channel | |
22:08 | intracube | joined the channel | |
22:37 | ApertusWeb8 | joined the channel | |
22:37 | ApertusWeb8 | changed nick to: eadmund
| |
22:38 | eadmund | yo!
| |
22:38 | Bertl | wb eadmund!
| |
22:38 | sasha_c_ | joined the channel | |
22:39 | 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.
| |
22:40 | eadmund | I will know in a few days what Cruse decides to use as an initial dev system to figure out this stuff.
| |
22:40 | eadmund | eg. Zedboard or Microzed or a Xilinx SDK.
| |
22:41 | eadmund | btw, Trenz in Germany have a really nice SOM: http://www.trenz-electronic.de/de/produkte/fpga-boards/trenz-electronic/trenz-electronic-te0720-zynq.html
| |
22:41 | troy_s | left the channel | |
22:42 | Bertl | unfortunately proprietary as many others
| |
22:43 | eadmund | ah. you mean the design is proprietary, or the chips are proprietary?
| |
22:43 | sasha_c_ | Bertl, can you let me know if this wiki for the CMV12000 register blocks is suitable: https://wiki.apertus.org/index.php?title=CMV12000_Register_Blocks
| |
22:43 | eadmund | or the tools?
| |
22:43 | Bertl | well, we won't get around the chips, but the schematic and layout is not known for those modules
| |
22:44 | Bertl | so using those would make us 'depend' on this specific manufacturer
| |
22:44 | Bertl | (not speaking of the many issues you can have with such designs)
| |
22:44 | eadmund | you mean you want a *documented* design
| |
22:45 | Bertl | precisely
| |
22:45 | Bertl | sasha_c_: looks good, except for the default values
| |
22:45 | eadmund | me too :)
| |
22:45 | Bertl | sasha_c_: which are currently in the 'Bits' column
| |
22:45 | troy_s | joined the channel | |
22:45 | sasha_c | left the channel | |
22:45 | sasha_c_ | changed nick to: sasha_c
| |
22:46 | sasha_c | Can I simply rename the column from 'bits' to 'default values'?
| |
22:46 | Bertl | no, you combined two columns there
| |
22:46 | sasha_c | Ah, I see
| |
22:46 | Bertl | the Bits e.g. [3:2] and the default e.g. 0x0
| |
22:47 | sasha_c | ok, fixing now
| |
22:47 | sasha_c | thanks :)
| |
22:47 | Bertl | thank you for helping!
| |
22:47 | sasha_c | Anytime man
| |
22:47 | Bertl | btw, if you manage to get some even/odd light gray/dark gray alternating background it would probably enhance readablility significantly
| |
22:48 | sasha_c | ok
| |
22:49 | Bertl | eadmund: so the zedboard, microzed and even zybo have at least well documented schematics
| |
22:49 | Bertl | but of course, a design with public layouts would be even better
| |
22:50 | Bertl | (the zedboard layouts are public as well, btw)
| |
22:51 | eadmund | yes.
| |
22:52 | eadmund | 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?
| |
22:52 | Bertl | yes
| |
22:53 | eadmund | well, congratulations.
| |
22:53 | Bertl | thanks!
| |
22:54 | eadmund | so, everything is out of my hand now. I am shifting to looking for cheap tools and a hackable Rigol :)
| |
22:56 | eadmund | what are you guys up to? you could rig up an led to help with linearising the sesnor.
| |
22:56 | Bertl | already done :)
| |
22:56 | eadmund | what did you do?
| |
22:57 | Bertl | I built a contraption out of a paper tube, some master film and an RGB LED
| |
22:57 | eadmund | and youflash theled?
| |
22:58 | Bertl | the foil is used as diffusor and the LED is controlled by the FPGA
| |
22:58 | Bertl | i.e. it is locked to the frame request and can be precisely timed
| |
22:58 | eadmund | neat!
| |
22:58 | Bertl | yeah, works like a charm!
| |
22:59 | eadmund | for color calibration leds are not that useful btw
| |
22:59 | Bertl | I have no intention to use them for color calibration
|