Thanks for addressing my GitHub questions. I think unit tests to check the new/preferred style of linearity is handled correctly is the main thing still needed. I'm still interested in an answer for my Q2 above, and will feel better if you do a quick isrTask "integration test" run in gen2 and gen3 on some real data before hitting merge.

As a result of me looking into the existing linearization tests in ip_isr (and being unhappy with them), I've added a new tests/test_linearize.py, and added a new ticket (DM-28816) to go back and put whatever tests are missing from this new file in, and to strip out the one-type files.

Other cameras currently store all the information necessary for the linearity correction in the cameraGeom.  The gen3 conversion allows this to be moved to an external calibration, which can then be certified and tracked.  It also wraps up the LookupTable that DECam uses.

Can you point to a gen2 repo that should work?  The data in the testdata_decam package looks like it's been faked entirely.

I have run ap_verify.py --dataset CI-HiTS2015 --gen2 using both w_2021_06 and this ticket branch, and both seem to generate calexp files that are pixel-by-pixel identical (outputs in /project/czw/DM-23985/gen2repo-retest and gen2repo-ticket).  The new linearizer tests in ip_isr now correctly test all linearizer types for round-tripping through both FITS and yaml formats, so the curated calibration pathway through obs_decam_data should not cause any problems.

I've also run a quick no-{bias, dark, flat} gen3 test that confirms (mostly to myself since I hadn't tested in more than a week) that the linearizers are ingested correctly into a gen3 repo and are used.

Thank you for this and for the new test. I think this is done but for docstrings (see one lingering comment in obs_decam PR plus a couple missing test docstrings) and, if possible, reducing code duplication in the test you wrote (again see the PR).

Thanks for adding the tests - assuming Jenkins is still happy, I am too