Closed bruno-f-cruz closed 1 year ago
This strategy should be validated and QC should be put in place on a session-based that checks the quality of the fit. Additionally, some filtering of flicker events might be needed if people are interacting with a second monitor while the render is running...
Partially implemented in #80. However, still needs to be used to actually log events
This ended up being implemented as part of the SoftwareEvent
class:
"softwareEvent": {
"type": "object",
"properties": {
"timestamp": {
"type": ["null", "number"],
"default": null
},
"timestampSource": {
"type": "string",
"enum": ["none", "harp", "render"],
"default": "none"
},
"frameIndex": {
"type": ["null", "integer"],
"minimum": 0
},
"frameTimestamp":{
"type": ["null", "number"],
"default": null
},
"name": {
"type": "string"
},
"data": {
"type": ["null", "object"],
"default": null
},
"dataType": {
"type": "string",
"enum": ["string", "number", "boolean", "object", "array", "null"],
"default": null
}
}
}
We can log every single frame that is rendered on the screen, however, this would prevent people from bringing the shader's window in and out of focus. Each time this happens a brief flicker is shown and we will lose synchrony at that point. To get around this problem, I suggest we toggle the quad randomly every 10-20 seconds.
The output file would then have the following columns:
In a second file, we will save the correspondence between the PhotodiodeSignal and the Frame in which we toggled the quad color.
Then, offline we can recover the correspondence between FrameTime and HarpTime (given by the photodiode pin) and come up with a correction model.
Additionally, each software event (e.g. task logic) that have a low priority should also be logged using both the render and harp times. I would suggest using the following timestamping pattern: