06-24-2019 10:23 AM
Hi there,
I wrote a program to sum the outputs of a 128x128 pixel CCD camera in an array, then write out the aggregate to a .csv file. When I checked the program, I found that the output became wrong when too many acquisitions were summed (i.e. total in output file does not tally with sum of individual pixel data). I have been told it might be a buffer issue.
Is saving into an array the best way to store pixel data (integers about 2000-8000)?
Does LabView have a hard limit on the size of the buffer for an array? Is it really possible to store a 128x128 array of integers with value 1.79E308?
Thank you very much for your inputs.
06-24-2019 10:48 AM - edited 06-24-2019 10:53 AM
The largest integer datatype is U64, which gets you nowhere near 1.79E308.
Can you explain what you are actually doing? What is the native datatype of a single frame and how many acquisitions do you sum?
This is all simple math and can be analyzed from first principles for a singe scalar. Basically, every doubling of the number of scans added requires an additional bit in the integer (or floating point mantissa).
Can you show us some simplified code. Do you have coercion dots? What is the datatype of a singe frame element? What is the datatype of the array accumulating the sum.
06-24-2019 11:18 AM
Thank you for working through this with me. I saw that a double precision floating point number gives a Maximum positive number of 1.79e+308
im taking one image every second and summing them all up. My boss seems to think I can take millions of images without problem but I encounter problems way before that.
i am not sure what the native datatype is but they look to be 4-digit unsigned integers, and can be output as .asc using the camera’s native program.
Code coming up!!
06-24-2019 11:46 AM - edited 06-24-2019 11:50 AM
If it is 4 hex digits (nibbles), it is U16, with a max of about 65535. Use U32 for the sum and you'll be safe for a long time, but not millions, depending on how many bits are actually used (e.g. is the camera 8, 12, of 16 bits, for example). 😄 There is always U64.
06-24-2019 11:49 AM
Hi Altenbach!! How are you?? Glad to see you're still going strong!! You helped create this program (problems initializing array) 5 years ago!!! O_O Code attached. Thank you so much!
06-24-2019 11:59 AM - edited 06-24-2019 12:00 PM
I see a couple of problems, but nothing that would cause the problem you observe. Can you attach a typical file?
(Some problems: %d is not a floating point format, path operations seem dangerous (better to use strip/build path instead of doing things on strings alone). sequence structure does nothing useful, hidden and backwards wires. There are tools to split the filename and extension).