Matching memory image line alignments between IMAQ Images and non-IMAQ cameras—bytes and borders

[vekkuli]

---

@BlueCheese wrote:

The line alignment has nothing to do with the bitness. I think the Concepts Manual is likely out-of-date, as the alignment is neither 8-bytes anymore nor constant between different platforms. The various items that cause this alignment to be certain values include:

- Cache line alignment (64-bytes on x86/x64). This is critical to high-speed DMA transfer performance of framegrabbers as well as random access to different lines by the CPU. Also, if cache lines were shared between lines then it can  affect things like parallel processing if different CPUs are working on different lines.

- Vectorized instructions like SSE require larger alignment such as 16-bytes to get optimum performance. Forcing the lines to be aligned makes operations significantly faster than using unaligned instructions.

Eric

---

"Whoosh!", I say, but thank you very much for filling in. It's good to have at least a hunch of the reasoning behind all this.

[Enrico_Segre]

Passing by, indeed I have just found evidence of the aligment having changed from next multiple of 32 bytes to multiple of 64 somewhen between 2010 and now. I have old movies recorded with a custom streaming VI, which stores the original IMAQ linewidth; the application has been around in our lab for a while and been used on various platforms and versions of windows with either bitness (and likely DMA alignment choice). I become aware lately that some of our old files are not readable anymore the way we used to, because the original assumption that linewidth is always what IMAQ GetImagePixelPtr reports for an image of a given size, doesn't hold anymore.

Enrico

[BlueCheese]

There is an output on that VI (line pitch ?) that lets you see the actual alignment.

Eric

[Enrico_Segre]

In IMAQ GetImagePixelPtr.vi (LV2013sp-something, calling LV_GetImagePixelPtr_2() from nivissvc.*)? I don't see it. LineWidth does report the current padded length, but the point is that for given xres that value changed across versions of LV.

[BlueCheese]

---

@Enrico_Segre wrote:

In IMAQ GetImagePixelPtr.vi (LV2013sp-something, calling LV_GetImagePixelPtr_2() from nivissvc.*)? I don't see it. LineWidth does report the current padded length, but the point is that for given xres that value changed across versions of LV.

---

Ah, I misunderstood. You already identified the parameter that returns the padded lenght and noticed that this is subject to change. Unfortunately it was already subject to change from platform-to-platform and as you noted, version-to-version. It will of course also change if the user passes images with different border size than the default.

I'd recommend trying to make your code be more dynamic. If you store whole lines (including padding) in your streamed files, make sure you include the necessary information to re-assemble the data into whatever the current line size ends up being. Newer versions of the Vision libraries allow direct zero-copy access to the image data in array format via the External Data Value Reference (EDVR) VIs and thus would allow you to do failrly efficient line-by-line reading.

[Enrico_Segre]

---

@BlueCheese wrote:

---

I'd recommend trying to make your code be more dynamic. If you store whole lines (including padding) in your streamed files, make sure you include the necessary information to re-assemble the data into whatever the current line size ends up being.

---

Esssentially what I ended up doing, thanks. Except that data flow was from and to disk in my case, so instead of EDVR into memory I simply had to deal with plain sector-padded raw byte array write/reads, where in turn the line lenghts are padded for IMAQ's own efficiency.