Potential IMAQ Multiply Bug - if multiply by certain integer constants, it intermittently doesn't work, with no error

[Ploetner]

I'm running LabVIEW 2016 32-bit with Vision Development Module 2016.  I've noticed some weird behavior when using IMAQ Multiply, when I multiply an 8-bit color plane by a constant.  The constant is a 64-bit double by default, and intermittently, when I multiply by 1.00 or 2.00 or 3.00 or 4.00, sometimes it seems to not do the multiply, but if I multiply by 3.99 or 4.01, it works just fine.  It's as if certain integer constants are intermittently being treated differently than if I do +/- a small amount.  For 1.0, sometimes I was ending up with a blank image, whereas if I did 0.99 or 1.01, it worked just fine.  I also had better luck if I change the constant from a double (64-bit) to a float (32-bit).  I could not find any other posts describing this behavior.  I most often see it at higher multipliers, such as 5.0.

For example code, I'm able to see the issue in this example code here, if I change the representation of the R G B gains to show trailing Zeros, and change representation to be Double from Single (I've also attached the file):

https://forums.ni.com/t5/Example-Programs/IMAQ-RGB-Hue-and-Color-Manipulation/ta-p/3501899

Attached are screenshots of the blue color plane with a multiplier of 4.9, which looks fine.  Then here it is with a multiplier of 5.0, which appears darker (it's treating it like a multiplier of 4.0, even though it should be 5.0).  And finally, here it is with a multiplier of 5.1, which again is correct.  So here we have 5.0 being treated as something that's darker, around 4.0.  I've also included a 4.0 multiplier and that is the same intensity as the bad 5.0 multiplier.

This behavior seems intermittent, and does not show up nearly as often, or at all, with single precision.  But the IMAQ Multiply has 64-bit Double as the data type for the constant, so not sure why that would be an issue.  I have not tried rebooting or restarting LabVIEW yet, but this should not happen.  I also don't see any errors out from any of the subVIs when debugging.

[Bob_Schor]

I regret to say that I could not duplicate your findings.  I used one of the RGB Sample Images that ship with Windows (I'm partial to "Desert") and multiplying simply changed the brightness, as it should have.  I didn't see any particular "corner cases" as I went past integer values.

You do realize, I suppose, that you are dealing with 8-bit color planes that "max out" at 256, so if you multiply by large enough numbers, the image will just go to white.  The reason for having the multiplier be a float, I suspect, is both for grey-scale images (where the values can be Sgls) or for subtle tweaks (1.03, almost the same as 1.00, for example).

Bob Schor

P.S. -- I'm testing with LabVIEW 2016.

[rolfk]

I can't reproduce it either in LabVIEW 2016 but you realize this has absolutely nothing to do with IMAQ? The slider and the digital display are the same numeric control but just two different views of the value that control holds. For some reasons the visual logarithmic scale does not agree with the numeric value in the digital display on your system. Might be a glitch in the slider control with logarithmic scales in LabVIEW 2012, or something more related to your computer.

Try to enter the actual number you want in the digital display and see what happens.

[Ploetner]

All of my testing was directly entering the number in the digital display, I never used the sliders.  I also reproduced this on a completely different VI that I made from scratch, without any sliders.

Here's a screenshot of that different VI, where I type in the constant, or click the up/down arrows on it.  I was able to reproduce it where 2.99 works, but 3.00 is treated as if it was 2.00, but then when I re-type 2.00, it's treated as if it's 1.0... so it's as if it's treating certain integers as minus 1 from what they should be.  I can also sometimes see 1.0 be treated as 0.0 so it's an all black image.  So either LabVIEW's numeric control is behaving badly, and passing bad values to the IMAQ subVIs, or IMAQ is not treating those numbers correctly.  I worry that if I can't get this reliably working with controls, will these same issues be present when I start programatically passing in values to these subVIs.  And again, when I change it to a single precision floating point, it seems to do much better and not have the issue, so I'm quite confused.

[rolfk]

You need to realize that the control behaving in such a way has almost certainly nothing to do with IMAQ Vision. The control is an object that handles its user input in a certain way to create from that a value and to do so there are various constraints that you can configure in the control in terms of minimum and maximum range and the interval as well as if a value outside that range should be coerced or ignored. Where that value goes to when the diagram comes to read it is irrelevant. That could be an IMAQ function or something completely different.

For some reasons the control on your computer behaves the way you describe and that can have a lot of reasons but should be totally independent on if you use IMAQ Vision or not. So the further cause to determine what is going on is to isolate the behaviour to a VI that is a simple as possible without any use of external libraries at all. Once you have that you can post it and we can run tests. It could be a corruption in your VI, that for some magic fixup improvements in newer LabVIEW versions is automagically fixed so when we try it in another LabVIEW version than yours, it simply works. It could be also a corruption in your LabVIEW installation that could be fixed by repairing/reinstalling LabVIEW. Or you could have ghosts in your computer that want to play tricks with you :-).

But without some systematic fault investigation we will never find out, and that starts at your side with doing some work to isolate the issue to an as simple as possible test VI.