S_1 Posted May 20, 2015 Report Posted May 20, 2015 Hei, I am using Microsft Visual studio 2010 for the dll. I have created an image in labview which is then sent to the dll in order to extract the rgb values. I was hoping to get the arrays of red, blue and green with the data representation from 0-255 (U8). But instead, I got a weird problem on the linker. Sometimes it compiles okey, sometimes not. I was wondering that I'm doing something wrong with the image variables (color:purple), because you can handle it like array of pixels or like handles which are in the end structures. So, which method should I use? Till now I used it like array of pixels. Also this I do not understand. Each pixel of the bitmap is big 32 bits or 4bytes: 1 byte for green, 1 for red, 1 for blue and what is porpuse for the other byte? Becuase in my dll I saved every byte in a different variable, in total 4 variables, and then send ti back to labwiew. When the dll functioned, I got only value form zero to one. Thanks for the help and any comments are appreciated Quote
JKSH Posted May 21, 2015 Report Posted May 21, 2015 Hi, I got a weird problem on the linker. Sometimes it compiles okey, sometimes not. Pay attention to the error messages that you get. They will provide clues for you to find out what's wrong. I was wondering that I'm doing something wrong with the image variables (color:purple), because you can handle it like array of pixels or like handles which are in the end structures. So, which method should I use? Show us your LabVIEW code. Also this I do not understand. Each pixel of the bitmap is big 32 bits or 4bytes: 1 byte for green, 1 for red, 1 for blue and what is porpuse for the other byte? Becuase in my dll I saved every byte in a different variable, in total 4 variables, and then send ti back to labwiew. When the dll functioned, I got only value form zero to one. First of all, you must know that 32-bit CPUs always reads in multiples of 4 bytes. See this article: http://www.ibm.com/developerworks/library/pa-dalign/ So, even if the 4th byte is unused, it is most efficient for it to let each pixel occupy 4 bytes. If each pixel occupies 3 bytes only, then you will get poor performance for read/write operations. But anyway, the 4th byte is commonly used to store the alpha channel (transparency). Quote
ShaunR Posted May 21, 2015 Report Posted May 21, 2015 (edited) First of all, you must know that 32-bit CPUs always reads in multiples of 4 bytes. See this article: http://www.ibm.com/developerworks/library/pa-dalign/ TIL: Mung is a real word created in 1958 and not a made up word we used to use at my school. Edited May 21, 2015 by ShaunR 1 Quote
S_1 Posted May 21, 2015 Author Report Posted May 21, 2015 Hei, Pay attention to the error messages that you get. They will provide clues for you to find out what's wrong. The thing is like this. The first time I compile, everything is fine. I run the dll in labwiev I get an error 1097 at Function node that the memory is corrupted. Then if I want to make some changes in dll, then this error pops-out. error LNK1201: check for insufficient disk space, invalid path, or insufficient privilage. What I do, is simple delete file .pdb and compiled it again which is then okay. If I run the Labview again then the vicious cycle returns (error 1097). It feels like I am leaking memory, but If I would the bitmap of my picture is small (220 pixels) and this shouldn't be a problem, right? Show us your LabVIEW code. np, attached the labview code and dll. But anyway, the 4th byte is commonly used to store the alpha channel (transparency). Okey good to know. Image_Dll.vi Quote
ensegre Posted May 21, 2015 Report Posted May 21, 2015 (edited) with highest probability: The thing is like this. The first time I compile, everything is fine. I run the dll in labwiev I get an error 1097 at Function node that the memory is corrupted. you're somehow passing wrongly sized data to your function. Very common mistake to go through. Then if I want to make some changes in dll, then this error pops-out. error LNK1201: check for insufficient disk space, invalid path, or insufficient privilage. the linker cannot write a new dll, because LV is still locking the file. IIRC it is sufficient to close all VIs containing CLN to the dll to release it. Edited May 21, 2015 by ensegre Quote
JKSH Posted May 22, 2015 Report Posted May 22, 2015 I run the dll in labwiev I get an error 1097 at Function node that the memory is corrupted. There are 2 major problems: You did not allocate any memory for PixArray, so your C code is writing into memory that belongs to someone else. That's why your memory got corrupted. You treated that the IMAQ Image LabVIEW wire as a raw array of integers in C. That's the wrong data structure. Anyway, why not just use IMAQ ImageToArray.vi? It feels like I am leaking memory, but If I would the bitmap of my picture is small (220 pixels) and this shouldn't be a problem, right? I wouldn't say that. Always try to understand why you are having memory problems. If you ignore it, you might one day find that your important data got destroyed. Quote
S_1 Posted June 8, 2015 Author Report Posted June 8, 2015 hei, I have found a VI that gives me the pointer to the image and with that I can easily manipulate the image. I am posting the code if somebody would maybe need it. cheers out RGB_dll.vi Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.