Testing, and some streamlining, of LUT calibration (& CLI)#36
Testing, and some streamlining, of LUT calibration (& CLI)#36JorisVincent wants to merge 15 commits into
Conversation
Linear input -> luminance relationship. Use linspace to define luminances, to be consistent with linearization routines.
Using parametric LUTs from `create_LUT`; `MockPhotometer`
No longer rely on the HRL filewriting, which needlessly coupled responsibilities.
Create LUTs more directly using `create_LUT`, where possible. Use more realistic scenarios
Uses a mock photometer and mock HRL, to test in the absence of real hardware.
essentially updating the tests in line with cadae73
There was a problem hiding this comment.
As written below, I like we include this, to be able to test the pipeline. But I'd do it with gamma values, not with LUT as input.
Then the tests can probe different gammas, noise levels (as you already do), and resolutions. I would find such a design cleaner.
What do you think @JorisVincent ? Is there a reason why to have lut as input?
|
|
||
| Parameters | ||
| ---------- | ||
| lut : array-like or callable |
There was a problem hiding this comment.
I like that we can introduce a mock photometer, so be able to test the whole pipeline. But I am not sure about this design decision, to have a LUT as input.
I think it is cleaner to have a gamma value as input (or 3 gamma values in the case of color), and a default range of luminances. Then the mock photometer calculates luminance using a standard gamma function.
I say this because conceptually, an LUT file is the result of the calibration pipeline, not the input. So it can be confusing what is the Photometer actually mocking
2 participants
Provides tests for the measurement routines, and with that the full calibration pipeline.
Mock functionality
To test measurement, provides a
MockPhotometerobject: corresponds to the fullPhotometer-class interface, but simulates measurements. It has acurrent_intensityattribute which should be set to the (gamma-corrected) intensity that would be on the screen. Then,MockPhotometeralso holds an LUT, andreadLuminancelooks up the luminance corresponding tocurrent_intensity. Optionally, it can also simulate 'measurement noise', with a seedable random generator, to provide more realistic measurements.To set the
current_intensity, a mock stimulus drawing function is also used in the tests of the measurement functions.Tests
This mock setup is used to test the
measure_lutfunction directly (test_measure.py), the whole calibration pipeline end-to-end (test_integration.py), and thehrl-util lut measureandlut verifycommands (test_cli.py).Additionally, the
MockPhotometeritself is unit-test (test_mockphotometer.py)Additional changes
hrl.luts.create_LUTto create synthetic LUTs; and so doesgenerate_test_data.py. This basically ensures there's one place where synthetic LUTs get defined.intensity_in, andintensity_outis gamma'd from there. Also that the linear relationship is done withnp.linspace, which ensure better float compatibilty with the MockPhotometer. This also required a corresponding fix in the tests forgamma_correct.measure_luthandles filewriting itself. Previously, this was done through thehrl.rflattribute andhrl.writeResultsLinefunction -- but that needlessly couples filewriting to the HRL object.measure_lutalso only checks if escape was pressed if there is aninputsdevice; so not in testing.measure_lutno longer calls.flip()-- this should be done by whatever function draws the calibration stimulus (admittedly, this is primarily to make the mock drawing function more straightforward)