Here are the data structures with brief descriptions:

Cls_calib_dist_t
Cls_calib_real_focal_t
Cls_calib_tca_t
Cls_calib_vig_t
Cls_camera_t
Cls_db_match_t
Cls_db_t
Cls_eval_t	One lens resolved at one shooting configuration, as a flat block of scalars
Cls_knots_t	A lens correction the camera maker measured and wrote into the file, as knots
Cls_lens_t
Cls_modifier_t	A modifier: the lens resolved at one shooting configuration
Cls_tokens_t	A tokenised name, with everything the comparison needs precomputed
Cls_vendor_data_t	One image's embedded correction data: the type tag and the matching member. A plain value — embed it in an image struct, memcpy it, zero it for "none"
Cls_vendor_dng_t	A DNG's OpcodeList3 corrections, parsed. Fill it with ls_vendor_parse_dng_opcodelist3() — or by hand, if the consumer's DNG reader already decoded the opcodes itself
Cls_vendor_finetune_t	Per-axis strength blend, 1.0 = exactly as the maker measured. The vendors' own GUIs expose these as "fine-tune" sliders; a consumer that does not can simply pass NULL to ls_vendor_resolve(), which means all-1.0
Cls_vendor_fuji_t	Fujifilm maker-note tables, verbatim: explicit knot radii shared by the three corrections, percentage-domain coefficients
Cls_vendor_olympus_t	Olympus maker-note polynomials, verbatim. No vignetting: Olympus does not publish one, and no flag here can invent it
Cls_vendor_sony_t	Sony maker-note tables, verbatim: fixed-point int16 over `nc` evenly spaced radii, which the file leaves implicit. The fixed-point scales (1/16384 distortion, 1/2^21 CA, 1/8192 vignetting) are applied by ls_vendor_resolve(), never by the extractor
Cname_ctx_t
Cspline_t