InfraTec readout / diagnostics #33
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… frames in local storage & redis. Note: Might need to update the empirical conversion (deduced in lines 362-378 of scify.py) every once in a while to eliminate drift.
…ffling code hierarchy in the process
…stamps) that are usable for creating frame ids
….timezone and datetime.fromtimestamp instead
…ch have a list of their constituent frames' ids as id
… to establish a relation between camera time and Windows time. Camera time (an offset in ms) is defined relative to the time when the camera was powered on. The Windows time - corresponding to the moment in time when the camera was powered on - is estimated by subtracting this camera time from the Windows time upon which a frame was recorded. This is done for the first 100 frames. The minimum of the resulting 100 Windows timestamps is taken as the reference Windows time of camera boot up. For each next frame, the Windows time - upon which the frame was snapped by the camera - is estimated by adding the camera time to this reference Windows time of camera boot up. Problem: the camera and Windows clocks drift apart with time. Therefore, above strategy for estimating the Windows time upon which a camera frame was snapped becomes less accurate over time. Solution: Instead of establishing the relation between camera and Windows time when connecting to the camera, establish it each time a recording is started in the GUI.
…hed to timezone-aware method datetime.now(timezone.utc)
…n UTC timezone, with precision down to 0.001 ms (see load_image). Upon writing to redis, these timestamps are converted to unix timestamps and rounded to ms precision in the process (see redisclient.add_roi_values). Upon writing to the Windows machine local storage, the frames are labelled as timestamp.png, where the timestamp is CUT to ms precision (see process_frame). The problem: cutting and rounding are not the same thing. If the original timestamp was 12 00 00 000500, that is 500 microseconds past noon, then the frame will show up as '12 00 00 000.png' in local storage (cutting) but redis will have registered a unix time in ms that corresponds to 12 00 00 001 (rounding). Solution: Round the timestamp instead of cutting it upon writing to local storage.
…ategy for setting the camera window, based on whether you go from a small to a large frame or vice versa. I used area of the frame here to determine this, a criterion is not specified in the manual.
…ntrol, separate from GUI, is implemented
…. A numpy array starts at index 0 and not 1, who would have thought
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Code requires testing in the lab. Will merge myself when final.