imaq C byte alignment

[tn42]

Hello,

I am using a linear CCD camera which enables 8, 10 and 12 bits acquisition. The camera is currently set to 12 bits, and I am retrieving the data from a C program, compiled against imaq.lib, with the functions defined in niimaq.h.

However, I can't figure out exactly how the data is encoded in the output array. The call is to imgGrab(Sid, &ImaqBuffer, TRUE), where ImaqBuffer is Int8 *, and therefore the 2048 pixels of the camera are encoded in a 4096 times 8 bits array.

Now I was assuming that the 12 bits are encoded such that ImaqBuffer[2*i] corresponds to the MSBs, and ImaqBuffer[2*i+1] to the LSBs, and therefore (((ImaqBuffer[2*i] << 😎 | ((ImaqBuffer[2*i+1])) ) >> 4) & 0xFFF would represent the actual pixel value.

But all values retrieved this way are multiple of 4, which means that either I'm doing it wrong, or the output is only 8 bits.

I haven't found this information in the docs, but perhaps I got a bit lost in it.... so any help would be greatly appreciated.

Thanks,

[BruceAmmons]

Try treating the value as a 16 bit value to begin with.  Get rid of the shift on the LSB and the and with 0xFFF.  Take a look at those values and you will be able to figure out how it work.  I would expect 8 bits of data in the LSB and 4 in the MSB, which is the opposite of how you did it.

Bruce

[tn42]

---

@BruceAmmons wrote:

Try treating the value as a 16 bit value to begin with.  Get rid of the shift on the LSB and the and with 0xFFF.  Take a look at those values and you will be able to figure out how it work.  I would expect 8 bits of data in the LSB and 4 in the MSB, which is the opposite of how you did it.

Bruce

---

Thanks for your answer.

I get apparently good values by using only a 8 bits shift of the MSB followed by a OR on the LSB with (ImaqBuffer[2*i] << 😎 | ImaqBuffer[2*i+1].

However, I systematically get overflows when too much power reaches the camera (signal is returning to 0). But I hardly see why the numbers don't fit on these two 8 bits registers (the camera is supposed to support 10 and 12 bits per pixels). Any clue?

[BruceAmmons]

I don't quite understand.  It sounds like you are getting good values most of the time.

What do you mean "too much power reaches the camera"?  Are you talking about the power supply for the camera?  Are you talking about too much light?  It just doesn't make sense.

Maybe you need to swap the high and low bytes?  Very hard to diagnose without pictures or data.

Bruce

[tn42]

---

@BruceAmmons wrote:

I don't quite understand.  It sounds like you are getting good values most of the time.

What do you mean "too much power reaches the camera"?  Are you talking about the power supply for the camera?  Are you talking about too much light?  It just doesn't make sense.

Maybe you need to swap the high and low bytes?  Very hard to diagnose without pictures or data.

Bruce

---

Hello,

Sorry for the unclear comment. I meant "optical power".

You were right, the low and high bytes had to be swapped, and the following works: (ImaqBuffer[2*i+1] << 😎 | (ImaqBuffer[2*i] & 0xFF)

Not too sure why the & 0xFF is required here, though.

Thank you,

[BlueCheese]

Like Bruce's original suggestion, why bother with bytes at all? Why not allocate or cast the pointer as an array of 16-bit integers instead so you don't need to do any of this manipulation? It is certainly going to be slower your way.