So this came from the equation I believe is used in HESS, but with the naming changed:
relative = flat field (camera average divided by pixel value, when illuminated with uniform light source)
absolute = gain (mV per p.e.)
The naming was changed in an attempt to make this more explicit, but I agree I wasn't very successful...

I believe they are kept in separate values as they are updated on different timescales

After implementing #1463 and discussing with @watsonjj, we had the following idea for a simplification:

The DL1CameraCalibrationContainer has just one field for this amplitude correction factor, e.g. flatfielding.

This would contain the total necesseray corrections for an individual event, which would make the code in CameraCalibrator simple (just charge *= flatfielding) and avoid these confusingly named and differently applied relative / absolute factor / divisor.

The complexity would then be shifted where it actually belongs: filling the correct value for an event from different monitoring data.

Application is simple, calculating the correct calibration value is hard. So the complexity should be where it is conceptually.

Since in the CTAO data model, R1 data will already contain the absolute calibration and we will only need to apply a relative update computed from interleaved calibration events, we should really implement the above conclusion.

Since in the CTAO data model, R1 data will already contain the absolute calibration and we will only need to apply a relative update computed from interleaved calibration events, we should really implement the above conclusion.

Note that this is not 100% correct: in R1 calibration there will be a rough DC/PE factor applied, but it doesn't mean we will not correct that factor in the offline analysis with better calibration information.

The main reason these are separated is that they are really different things: one is a conversion factor from DC to PE, so the units are important there. It uses no inter-pixel information, only the position of the single-PE peak in the charge distribution. The flatfielding factor is something else: it corrects for residual differences between pixels, just to make doing things like Hillas parameterization easier (at the expense of losing some information about the pixel's gain factor). It should be a numer very close to 1.0 if the pixels are well-matched in the camera. However, there are reconstruction techniques that use only the PE/DC factor and need to know its value (e.g. Model++), and need to be able to "un-correct" the flatfielding.

So I would disagree with this issue partially (I agree the naming and one being multiplicative and the other a divisor is bad):
We need to know both factors separately, and for data quality, we also want to track how both change.

So I would disagree with this issue partially (I agree the naming and one being multiplicative and the other a divisor is bad):

Similar comment to my comment in the PR: this issue is about changing the field in the event data structure, not the monitoring data.

I think it is good to move the complexity of combining the different monitored quantities like gain and other relative pixel differences to the monitoring code that computes the correction for the current event and only have the result of that computation in the event data structure.