11-24-2011 04:17 AM
Hi,
I'm currently working on a library where you can input some ROIs, some algorithms (the folder that contains them) and a table with information where and how to apply those algorithms and get back an image. Sort of like a very complex Vision Assistant thing.
Right now I need to make sure that the input and output images have the same type.
I do not know anything except that I (or the ppl working wtih the library) will input IMAQ images, usually RGB32 or Grayscale, and that the algorithms (which are dynamically loaded) should deliver the same type. Mine do, because I use arrays and bit-level operations,but I want to programmatically enforce this. And I want to use high-level IMAQ functions.
I've tried multiple variations of the code below (like creating new images, playing with src/dest..) , and they do not work.
But to be honest, I'm not too familiar with the image data types.
Can you help me?
Thanks,
Birgit
(I did not include the classes, so the wires are broken.)
11-28-2011 05:30 AM
Its not good idea to use type cast in this case. What you need is to have different imageprocessing for different types, so you will need case structure, which will be switched dependent from the type, something like that:
You may have different dynamically called VIs for handling each incoming type (then case structure should be in your root VI), or you can place case structure into dynamically called VI - this depends from the architecture.
Andrey.
11-28-2011 06:26 AM
Thanks for your solution.
The problem is that for my purposes, I need to use something like a cast or write one myself.
I have an input image. It's an IMAQ image. It is not known in advance what type it is.
The algorithm does something to that image. Maybe IMAQ algorithms (think threshold= RGB2binary), maybe something lowlevel. The developer might or might not make sure that the type stays the same. But because I use a (dynamically determined) chain of (dynamically called) algorithms, I need to ensure this property.
So what I'm going to do is to use 2 case structures, one for the original image, one for the resulting image, and implement all combinations.
Which is truly ugly - I was hoping for a high-level cast, but apparently this doesn't work.
12-02-2011 04:17 AM
Hi Birgit,
"Imaq Cast Image" is able to cast the IMAQ-Data-Types. Any different type would have to be handled low level, and
be implemented by you accordingly, let´s say as your own type cast function, which you best build into your own subVI.
kind regards
Marco Brauner NIG
12-02-2011 04:22 AM
I've done so, the problem with using cast is that it doesn't cast, for example binary level images into color images, the way that seems natural to me - aka take U8 binary, multiply with 255, put three(four) of them together, use as U32 color planes. I've written my own subvi now, but I'm sort of disappointed.
Thanks anyway,
Birgit
12-02-2011 05:34 AM
@b.ploetzeneder wrote:
I've done so, the problem with using cast is that it doesn't cast, for example binary level images into color images, the way that seems natural to me - aka take U8 binary, multiply with 255, put three(four) of them together, use as U32 color planes. I've written my own subvi now, but I'm sort of disappointed.
Birgit, you can't do it in that way. In some cases you will lost information (when casting I16 to U8, for example). The only right way - different algorithms for different types. For example, processing of U8 and RGB images is quite different. Do it in the same way as NI does - some IMAQ SubVIs are "universal" - for example, you have IMAQ Threshold which can handle U8, I16, U16, SGL. But if you will try to perform IMAQ Threshold for RGB, then you will get "Incompatible Image Type" error (therefore IMAQ Color Threshold is exists). Still not fully understand your final goals.
12-02-2011 05:56 AM
I can enforce input type with other developers, but, not output type. I'm aware of potential data loss.
Doesn't matter, I've written my library.
12-02-2011 06:31 AM
Just FYI, that's what I did:
This is the demo program of the library
This is how it looks for a dev:
(and yes, the error is not a shift register. I was changing things)
I used to strongly dislike how ROIs are handled by NI and now I have my own, stable and most importantly fast-to-play-around solution.
Thanks anyway.