IMAQ Cast Image changes border size

[Yuri33]

I have an image that I wish to convolve using a relatively large kernel (15x1 and 1x15).  The original image is U8 and has the default border size of 3.  I create a new image space using IMAQ Create with a border size of 7 and the SGL image type.  I then use IMAQ Cast Image to take the data from the original image and convert it to SGL for convolution.  However, in this conversion, the border size of the SGL image changes from 7 to 3.

I know that IMAQ copy takes all the original information from the image source (including border size) and copies it to the image destination.  However, there is no such documentation stating that IMAQ Cast Image also copies the border size of the image source.  Does this mean that every time I use IMAQ Cast Image I need to then call IMAQ ImageBorderSize to change it to the size I need?  If this is the case, this represents a rather inefficient use of memory space, especially if the image casting operation needs to be performed many times.  I had originally allocated memory for an image with a large border, but now that border space is deallocated and reallocated every time I want to cast an image and convolve it.

Is there any way to avoid this undocumented border size change?

[BullDozier]

Hey Ajay,

Thanks for contacting us with your problem.  I have done some research into this and found out that on my computer, the cast image VI does not change the border width.  I composed a VI that should work with any version of LabVIEW newer than 8.0 that illustrates this point.  Could you run this VI and confirm for me that it doesn't change the border size on your computer as well?  I understand that your VI is probably much more complex than this one, but we can use the behavior of this VI as a starting point for our troubleshooting.

Good luck and I hope this helps you out.  Reply back here if the same behavior is observed on my VI as well.

Take Care,

[Yuri33]

Evan--

Thanks for your help in advance.  I did try your program, and it did indeed work, which is confusing to me. 

I have a stripped down version of my program which illustrates the problem.  Attached is a .LLB file (bordertest.llb) which contains the your original VI ("Border Test 1.vi") and my stripped down example VI ("Border Test 2.vi").  In Border Test 2, I open an image file, and then pass it to a VI ("Image Gradient.vi"), as well as a reference to a complex image.  In the Image Gradient VI, I use IMAQ Cast Image to cast the source reference to a temporary image reference created by another VI ("Image Manager (Temporary Image).vi").  This temporary image has the appropriate border size for processing the subsequent convolutions with kernels created by another VI ("Kernel Global.vi").  However, I get an error (-1074396072, Invalid image border), when I try to perform the first convolution using the defaults.  If you try Border Test 2 with the default inputs, you will see this error.  However, if you specifiy a small window size in the "Filt" control (e.g., 5) instead of the default (-1, which tells my program to automatically calculate a relatively large window), you get no error.  Additionally, you can check the "Border Size Before" and "Border Size After" indicators in Image Gradient.vi.  They show that the border size did change to that of the source image.

I have another version of Image Gradient.vi (not in the attached LLB) that adds a IMAQ ImageBorderSize operation after the IMAQ Cast operation to set the image border back to the appropriate size.  This seems to solve the problem, but represents a loss of efficency and speed becuase of the additional memory allocation\deallocation that has to occur every time this VI is called.  In my program, Image Gradient.vi is part of a set of functions which are used for real-time analysis of acquired images, so speed is important to me.

The attached LLB is in LV8.2.  Please let me know if you need another version.

Message Edited by Yuri33 on 10-26-2007 07:49 PM

[BullDozier]

Hey Ajay,

I looked at the files in your llb that you attached and I was able to confirm that I get the same error.  I am going to explore this VI deeper and try to determine where and why we are getting an error here.  I will let you know what I find.  In the meantime, I am glad that you have found a workaround for this problem.

Thanks for getting back to me with such a detailed description of your problem!

Take Care,

[Yuri33]

Thanks in advance.  I had one thought that might be leading to the problem, but I don't know if there's any way to test it without ruining the functionality.

I created the Image Manager VIs because I hated have to declare a whole buch of image references in the beginning of the program and then wire them through various subVIs for intermediate processing.  Instead, I created "Image Manager (Temporary Image).vi" so that I could drop that in any subVI I wanted in order to declare temporary image space.  The VI was designed to create an appropriately typed and bordered image reference (on first call), and then simply return that reference (via uninitialized shift register) on subsequent calls.  Becuase I wanted to drop this as a plug-in replacement for image references, I made the VI re-entrant, so each call would create it's own temporary image space.  Additionally, for bookkeeping purposes, the first call (which generated the reference) would call a common LV2 global so that I could call a cleanup routine at the end of the program and destroy all those temporary image references.

Perhaps the border resize issue is related to the re-entrant and\or LV2 global nature of the Image Manager VIs.

[BullDozier]

Hey Yuri,

From digging a little deeper into your program,  I have found a possible problem in your temporary image subvi.  Although I cannot open this vi to edit (I can only load a temporary image of it),  it appears that the last stage of logic where you set the border size in this subvi, you are actually not writing the border size for a true case.  When you don't write this, it is either being written to 3 instead of what the control says, or it isn't being written at all, either of which could possibly cause this error you are seeing.

Could you take a look at this and confirm that your logic is correct.  It appears as though this is the problem though.  I hope this helps you out!

Take Care,

[Yuri33]

I think my logic here is correct.  I've attached a picture showing the block diagram with all relevant cases shown.  The cases not shown represent simple pass-throughs:



My VI takes the larger of 3 or the input border size, and then compares it to the border size of the temporary image.  If they are different, and if the input border size was greater than 0, then the VI proceeds to the True case.  In the True case, IMAQ ImageBorderSize is wired with True to put it into the "Set" case, and and the Image Border In is wired with the new border size (the larger of the input border size and 3).

In this manner, I can wire a new border size at any time, or I can leave it unwired (or wire in a negative value) to leave the border size unchanged.  Am I missing something in my logic?

Message Edited by Yuri33 on 11-01-2007 03:54 AM

[BullDozier]

Hey Yuri,

I guess what I meant by check your logic was that since you are feeding it the larger of 3 or an input border size, and on the other side, the border is 3 when it should be 6 or 7, I just wanted to make sure that the right value was being passed into the create border VI.  For some reason I cannot edit or run the image manager subvi in highlight execution mode.  If you take off the constant 3 value, is the resized value still 3?  That's what I was wondering.

I hope this clarifies my statement I made earlier.  Let me know how it turns out. Have a great weekend!

Take Care,

[Yuri33]

Attached is the same diagram with execution highlighting turned on.  I believe the correct border value (6) is being sent in:






Message Edited by Yuri33 on 11-04-2007 03:24 AM

[BullDozier]

Hey Yuri,

I am looking into what is causing this border size change.  Since running "Border test 1.vi" doesn't exhibit the border changing problem, I believe the problem could be localized to the code in "Border Test 2.vi"  I am researching this and will let you know as soon as i find something.

Thanks,