Advanced Features

Error handling, memory, and how PyHDRL sits on PyCPL I/O.

Errors

When an HDRL or CPL C call sets a CPL error, PyHDRL raises a subclass of hdrl.core.Error (same CPL_ERROR_* codes as PyCPL, under the hdrl.core namespace). Catch hdrl.core.Error for any translated library error, or a specific subclass for one code. The code-to-exception table is in the API Reference (Errors).

Python-side argument checks can still raise built-in TypeError or ValueError. Those are not subclasses of hdrl.core.Error.

Memory

Process memory use is known to be high (Known Issues). On top of that, hdrl.func.Flat.compute consumes its input ImageList the way hdrl_flat_compute does in C: the list contents are undefined afterwards. Call imglist.duplicate() (or build a new list) if the frames are still needed.

Fringe correction updates the fringe imagelist in place. Computation of the master fringe does not.

Numpy and FITS

PyHDRL does not implement FITS I/O. Use PyCPL:

  • cpl.core.Image.load / save, then hdrl.core.Image(data, error)

  • cpl.core.Image(numpy_array) as in Getting Started

  • cpl.core.Table, cpl.core.PropertyList, cpl.drs.WCS where an algorithm needs them (catalogue, resample, barycentric EOP table)

Debug module

hdrl.debug exists to check that PyCPL objects survive the type casters. It is not a recipe API. Its generated entries appear under the API Reference only for people who maintain the bindings.

Troubleshooting imports

If import hdrl fails after a source build:

  • HDRLDIR and CPLDIR must point at the same CPL that built HDRL, PyCPL and PyHDRL.

  • The HDRL shared library must exist (libhdrl.so on Linux, libhdrl.dylib on macOS). That requires configure --enable-standalone.

  • Put $HDRLDIR/lib64 or $HDRLDIR/lib (and the matching CPL path) on LD_LIBRARY_PATH (Linux) or DYLD_LIBRARY_PATH (macOS) before starting Python. A new shell does not keep those variables.