Dear Björn,
I have installed Siso RT 5.6.074339. MicroDisplay and I am currently using the Marathon VCL Framegrabber.
microDisplay does not Show the Option "RGB36Bit"
By the way. This Format will then be "packed", right? So I will have to unpack it by Software.
If I do want to save CPU load I think RGB48 would be better. Of course as long I do not exeed the Maximum bandwidth.
best regars,
Theo
Thanks Björn,
that helps a lot. I will be able to try this tomorrow.
Have nice evening,
Theo
Hi Björn,
thanks for the input. Acutally (and I missed that in my first question) I want to transfer RGB 12 Bit (RGB36) and not grayscale. I am not sure if I did forget this in my post or if I did not have the information at that time.
However, I have made little test applet and can build it just fine (ouput is RGB 36 Bit with a parallism of two). As expected microDisplay does not support this pixel format (gray 12 bit and rgb 36 are not shown in the list).
regards,
Theo
Sounds good! Thanks a lot and have I nice Weekend!
Theo
Hi there,
I am currently thinking about a design for CXP-Cameras with 12 bit pixel format. The pixel will be handled as 12 bit value inside the VA but what happens in the DMA transfer? If I do understand the documentation of the operator DMAToPC correctly 12 bit is not allowed and therefore I would have to scale up to 16 bit.
Is this correct or do I have an option to use 12 bit and therefore reduce the needed bandwith? In my case this would be the difference between Ironman and Marathon.
regards,
Theo
Thanks Björn,
thats what I thought. I will implement the LUTs only as the customer is ok with dealing with that via software.
Regards,
Lothar
Hi there,
currently I am working with a customer who basically already solved some applications using microEnable IV AD4. Now he wants to switch to Marathon VCL with aditional functionallity, which is why we are planning to implement a VA for him.
Of course we want to give him as much look and feel as he is used to from the standard applet (MediumLineRGB) and while I was comparing our specification with the existing applet I came up with some "questionmarks".
The main question which popped up is how I can implement the LUT and "Processing" operator in an Applet so that the user (at best) does not feel a difference. What is the best way to do it? Can it be solved using VA?
best regards,
Theo
Good morning Johannes,
that sounds great. Take your time as I am currently not sure if I will have the opportunity to implement this application.
best regards,
Theo
Hi there,
I am currently thinking about a recording application for a CXP grabber which converts the input image directly into JPEG.
Using a CXP-Grabber datarates will be quite high so I thing the throughput will be challenging. According to the documentation I should be able to achieve approx. 300 MB / s on a Marathon VCX-QP using one JPEG-Encoder_Gray operator.
My idea would be to split the data stream and use a second or third operator to maximize this boundary to 600 or 900 MB / s. Please see a first draft attached (untested of course =) ). Is there a better option and what do you think would be the maximum possible badwidth?
I just noticed that the better way probably would be to split the image stream after the ImageBuffer_JPEG_Gray and not before. This would probably safe me a bunch of resources.
However, what do you think? 
best regards,
Theo
Hello Johannes,
thank you very much for the detailed answer. I do not really need a solution here as I think we will be fine with one of the workarounds.
Best regards,
Theo
Hi there,
I hope this question is in the correct part of this wonderful new forum. Please feel free to move it, if not.
How is it possible to reset my complete applet without reloading the board? E.g. deleting image data, reseting counters, etc.
I know that processes with an acquisition can be reseted by stopping and restarting the acquisition itself. This of course does not work with processes without an acquisition part (e.g. processes which are only ment for signals). The only other way I can think to solve this is step by step, reseting each operator by it's own reset input if available and think of an algorithm to reset the image data.
Is there a possibility which I did not think about?
regards,
Theo
