Jalok: You're correct in the Neutral Gray slider direction - my faulty memory showing. A setting of 0 maps the output to be colorimetrically more neutral while 100 preserves the paper color. This is the opposite operation of MonacoProfilier's Neutral Gray slider.
You are also right in that the Neutral Gray slider affects the Perceptual intent of RGB profiles as well as CMYK. For example, i1Profiler RGB profiles built for a paper with a white b-value of -9.6 (113% reflectance in blue) produce different output values for the same RGB input depending on the setting of the Neutral Gray slider. The difference is subtle for most papers - as with most of the i1Profiler options a 100 point scale is silly. It is not doing the same thing as PMP's optical brightener correction. There is more of an overall color cast rather than compensating for the optical brighteners. The effect is the same as Monaco's Neutral Gray slider or PMP's Paper Colored Gray vs. Neutral Gray option. Both of those options, like the NG slider in i1Profiler, could produce visually curious results on some paper stocks. None of the adjustments are a substitute for OBA compensation.
We licensed a number of algorithms to a certain large software vendor whose operating system-level color management efforts died quietly. We're considering releasing parts of our codebase either as open-source or simple utilities. Selling applications entails providing tech support. That's a losing proposition for products with such a limited market..
Our OBC module might be a good candidate for a standalone tool. It dials in variable corrections based on the measurements. It triggers off both the absolute level of blue tint seen (i.e. b-value of paper white) as well as the shape of the remission curve in the 400-480 nm region. Basically, if enough of a hump is seen, OBA's are present. How much the curve is flattened out depends on both the magnitude and steepness of the spike in blues. Our code is limited, for now, to CGATS files. Supporting X-Rite's mxf files would either take using X-Rite's SDK (and the associated licensing nightmares) or hacking together a customized XML parser.
An alternative, for an industrious person, would be to extract Argyll's OBC code into a standalone utility. It would take adding CGATS file support at a minimum and, perhaps, i1Profiler's mxf file format. We extracted instrument control routines from Argyll for our own use, but aside from a cursory look through the code, I have not looked at it in detail. Even an overview, however, showed that Graeme's code structure of elaborate pointer type-casting to kinda-sorta emulate object-oriented programming in straight C makes matters more difficult for reuse.