magao-x / MagAOX

MagAOX/apps/shmimIntegrator/shmimIntegrator.hpp

Line 315 in 1875c1f

darkMonitorT::m_getExistingFirst = true;

Why is only darkMontitorT::m_getExistingFirst assigned a value of true here, and not dark2MontitorT::m_getExistingFirst or shmimMonitorT::m_getExistingFirst?

I understand if shmimMonitorT::getExistingFirst is not assigned here because it is going to wait for several to accumulate (integrate) anyway. But everywhere else darkMonitorT::... is used dark2MonitorT::... also shows up, except here.

There are other apps where this possible inconsistency appears.

m_getExistingFirst is a property of shmimMonitor class, and there its default is false (

MagAOX/libMagAOX/app/dev/shmimMonitor.hpp

Line 93 in 1875c1f

    
           bool m_getExistingFirst {false}; ///< If set to true by derivedT, any existing image will be grabbed and sent to processImage before waiting on the semaphore.

).

That is probably the correct default there b/c of the many possible use cases, usually driving control loops, where you want to wait for a fresh image.

Here we change the default to true b/c the dark is very often pre-existing (as a product of a different shmimIntegrator instance).

The dark2MonitorT::m_getExistingFirst probably could be true as a default here for the same logic, but this second dark was added for a turbulence simulation case that didn't work anyway, so it's never actually used that i remember.

This is a configurable property (via the call to shmimMonitor::loadConfig) anyway.

oh, it isn't actually configurable

Here we change the default to true b/c the dark is very often pre-existing (as a product of a different shmimIntegrator instance).

"very often?" what about when it isn't? maybe we should change it to be configurable?

I think it should be made configurable as a generale principle.

But for any given instance of this process (as setup by the config file, i.e. by specifying a dark shmim) the two cases are "there should be a dark to subtract" and the "there is no dark to subtract ever": If in the first case, if at startup there isn't a pre-existing dark yet, then nothing happens it's just handled as all 0s until a dark shows up. Then when the dark shows up it gets used.

put another way, if you specify a dark then the default assumption is that you want to use it if it is available. The "very often" means "most of the time, at process startup, the process that creates the dark was already running so the dark exists."

Inconsistent handling of dark and dark2 shmimMonitors