03:55 | Bertl_oO | off to bed now ... have a good one everyone!
| |
03:55 | Bertl_oO | changed nick to: Bertl_zZ
| |
07:39 | Spirit532 | left the channel | |
07:39 | Spirit532 | joined the channel | |
10:49 | Bertl_zZ | changed nick to: Bertl_oO
| |
17:41 | vup | se6astian: the axiom_snap snapshots are taken without locking the buffers, right?
| |
18:37 | se6astian | Yes
| |
18:38 | se6astian | Should i change that in the capture Script?
| |
18:48 | vup | Yeah that is probably a good idea
| |
18:49 | vup | right now some of them look like the buffer was overwritten while the snap script ran
| |
19:21 | se6astian | will do
| |
19:21 | se6astian | did you see anything else in the capture script that you would change/add?
| |
19:23 | vup | looks fine from the steps taken
| |
19:23 | vup | i guess a snap before capturing the average frame would be interesting
| |
19:23 | vup | (or atleast a register dump)
| |
19:24 | vup | for example to estimate any temperature changes over the capturing of the average frame
| |
19:25 | vup | I also looked at the memory consumption again and am really not sure what the problem there could be, the memory consumption for me (when using RawDirectoryReader as source) is definitely not dependent on the `--n` of `Average` and I can do 10000 frames easily
| |
19:25 | vup | all in all, the frames look all reasonable
| |
19:25 | vup | ill have to look into the dark columns a bit more
| |
19:26 | vup | for these, capturing a non averaged stack would be pretty interesting
| |
19:26 | vup | I think 256 frames of one specific exposure time should be enough for now
| |
19:26 | vup | Oh also, with which framerate was this captured?
| |
19:27 | vup | Ah also I think having a script that combines the whole process of setting up the camera and then capturing the frames would be handy
| |
19:28 | vup | Oh a maybe 32 frame stack of a long exposure time (100ms+) would be pretty interesting
| |
19:28 | vup | I guess of a "normal" motive to compare aswell
| |
19:29 | vup | Finally having a lot more exposure steps would be very interesting
| |
19:30 | vup | There certainly seems to be a relationship between the darkframe and the exposure time, but its pretty ehm noisy curently
| |
19:30 | vup | https://files.niemo.de/darkframe_deviation_hist.png
| |
19:31 | se6astian | capturing a non averaged stack would be pretty interesting <- with 256 frames for one exposure?
| |
19:31 | vup | yeah
| |
19:31 | se6astian | noted
| |
19:31 | se6astian | this is now being captured with 50 FPS, so 25 real frames
| |
19:31 | se6astian | per second
| |
19:31 | vup | right
| |
19:31 | vup | so 20ms is already in the region that previously caused problems with the hdmi raw setup because its slows down the actual framerate, right?
| |
19:32 | se6astian | I cant go higher with the exposure time than what I provided with the latest uploads as then the recorder cant find A+B pairs anymore
| |
19:32 | vup | Hmm
| |
19:32 | vup | I wonder why
| |
19:33 | se6astian | I was about to add the ssh lines that set up the camera to the capture script
| |
19:33 | se6astian | but then the problem again that I need to check every time if axiom_start had already been run before on the camera
| |
19:34 | se6astian | and also waiting for the command to finish before doing anything else...
| |
19:34 | se6astian | so I left that to be done manually for now
| |
19:34 | vup | well
| |
19:34 | vup | I thought maybe a script that you basically run after the camera has just been booted
| |
19:34 | se6astian | yes I created that one
| |
19:35 | se6astian | https://pastebin.com/W6irhmz0
| |
19:36 | vup | right
| |
19:36 | vup | having one that combines this with one that calls the other script for the different exposures would be handy
| |
19:37 | vup | so one can simply with one call get comparable darkframes from other betas
| |
19:37 | se6astian | I can capture the "32 frame stack of a long exposure time (100ms+)" with axiom_snaps
| |
19:37 | se6astian | a lot more exposure steps <- how many and what range would you like?
| |
19:38 | se6astian | so 20ms is already in the region that previously caused problems with the hdmi raw setup because its slows down the actual framerate, right? <- yes
| |
19:39 | vup | se6astian: I added a `--debug` flag to the DualFrameRawDecoder, capturing the output of the recorder with that flag active `--debug=true` for a exposure time that causes problems would be interesting
| |
19:39 | se6astian | noted
| |
19:39 | vup | se6astian: right the 32 frame stack of a long exposure time would be to check if the recorder actually does the "right" thing
| |
19:39 | vup | but if it doesn't work, that doesn't help
| |
19:40 | vup | As for which exposure range and the number of steps, about 100 steps from 0 to the upper limit of what one would actually use would be interesting
| |
19:40 | vup | And then maybe 10 or 20 steps from there to maybe 100ms?
| |
19:40 | vup | Also maybe some super long ones?
| |
19:41 | vup | Whats the current limit?
| |
19:41 | se6astian | good question :)
| |
19:42 | se6astian | lets ask herbert about the longer exposures, but I assume its an issue with sequencer and output generator not being independent currently
| |
19:42 | se6astian | but Bertl will work on changing that soon
| |
19:43 | vup | right, maybe we can find something that works in the meantime aswell, so getting a log of the DualFrameRawDecoder with `--debug=true` would be handy for that
| |
19:43 | se6astian | ok
| |
19:44 | se6astian | on another front: I visited manfred today and we successfully were able to laser cut the plastic sheets I took from a DVD case
| |
19:44 | se6astian | https://cloud.apertus.org/index.php/apps/gallery/s/aroXPrykksDCnwk#IMG_20220212_184353.jpg
| |
19:44 | se6astian | this will alow us to build a frame for the ZIF sockets to prevent wrong insertion
| |
19:47 | vup | hmm maybe I am calculating this completely wrong, but if we keep reg85 at 130, exposure times of 100 secods should be possible?
| |
19:47 | vup | thats pretty neat
| |
19:47 | se6astian | thanks :)
| |
19:48 | vup | (I get a lower bound of ~105.5 seconds, but this is ignoring the FOT, so actually a bit longer)
| |
19:48 | se6astian | I will try long exposure times
| |
19:48 | vup | (*the actual maximum should be a bit longer)
| |
19:49 | se6astian | so about longer exposure times with snap
| |
19:49 | se6astian | do they help you currently or only if they come through the recorder?
| |
19:50 | vup | nice re ZIF frames
| |
19:50 | vup | se6astian: they help aswell, but capturing 256 for 10 different exposure times sounds really slow
| |
19:51 | vup | But its also not that interesting atm, so if you have limited time, using than for capturing flatfields instead of long exposure darkframes would be a lot more interseting :)
| |
19:51 | se6astian | yes but 32 would be doable for one exposure time...
| |
19:51 | se6astian | right
| |
19:51 | vup | right, 32 for one exposure time is probably super interesting
| |
19:51 | vup | especially if it is a exposure time few people are likely to use
| |
19:52 | se6astian | noted
| |
22:57 | Bertl_oO | long exposures should not be a problem at all, but you will get a number of identical HDMI frames (alternating between A and B)
| |
22:57 | Bertl_oO | i.e. the HDMI sequencer does not advance when the exposure is still going on
|