Dear Grubbier,

I looked into your design:

Quote from Grubbier

does not go above about 1.5Khz

(1.5 kHz) * 4096 * (8 bit) = 6.14400 MB / s

I would expect a higher bandwidth for your design...

Your design is using parallelism = 1 around the memory operators.

That will limit the bandwidth there to 62.5 MPixel/s.

You are using 2 memories for the same operation.

That can be combined to 1 memory.
Or you combine both in parallel to double the bandwidth.

Best regards

Dear Grubbier,

Thank you for the positive response.

Quote from Grubbier

The compilation on VD1-CL is successful but the acquisition frequency does not go above about 1.5Khz.

I wanted to know if these HDR algorithms involve a frequency limitation.

Also, if it were possible, I would like to know if a version in FULL Camera link mode can be implemented

The mE4-VD1-CL is due to its "age" pretty limited in its ressources.

Especially the DMA transfer can handle only up to 200 MB/s while the amount of memory operators is limited to only 2 of 128 MB each!

In case the overall output bandwidth and especially the memory bandwidth is within the spec of mE4-VD1-CL you can go for CL FULL (or do you mean DECA). But I really doubt that the memory bandwidth requirements of the HDR approach is getting well served by the *VD1*.

All later and especially more current platforms (recommending mE5-MA-VCL) have much more ressources:

4 x memory, higher DMA rates...

Best regards

Dear Johannes,

Normally there is a timebase related to each HDR image in the sequence.

Quote from Johannes Trein

(shift = 21)

Adopting the real used time base would have the same effect.

pasted-from-clipboard.png

Calculation is mentioned in the comments (within screenshot above) and can be changed in Image1/Image2 H-Box in Const:

pasted-from-clipboard.png

Best regards

Hi Johannes,

Quote from Johannes Trein

Operator RamLUT can be used instead of CoefficientBuffer

Yes, the RAMlut is a good alternative.

Quote from Compo

Can someone provide me with a small working example?

Do you have some C code for this fast approach?

Best regards

Dear Christoph,

The CoefficientBuffer is fine, but in case you have the Debug-License for VA try ImageInjector as used in C code shown above.

Best regards

Dear Christoph,

Some additional details on return code check:

#ifndef SISO_HELPER
#define SISO_HELPER

/// definition of helper macros
#define __STR2__(x) #x
#define __STR1__(x) __STR2__(x)

/// useful for a pragma message/logging for conditions raised at compile time
// this indicates the file where something may be strange
#define __LOC__ __FILE__ "("__STR1__(__LINE__)") : warning/info SISO: "

/// the function checkReturn could be implemented without macro using std::source_location
#pragma message(__LOC__ "Please change this to std::source_location with C++20") // https://en.cppreference.com/w/cpp/utility/source_location

/// dangerous but simple helper macro for return code interpretation of SGC function, named Sgc_* and derived from SisoGeniCam
#define SGC_CHECK(x) { \
                        int r = (x); \
                        if (r < SGC_OK) \
                        { \
                            checkReturn(r, std::string(__FILE__), __LINE__, std::string(#x), true); \
                        } \
                     }

/// dangerous but simple helper macro for return code interpretation of FG function, named Fg_* and derived from FrameGrabber
#define FG_CHECK(x) { \
                        int r = (x); \
                        if (r < FG_OK) \
                        { \
                            checkReturn(r, std::string(__FILE__), __LINE__, std::string(#x), false); \
                        } \
                    }

/// dangerous but simple helper macro for return(incl. return) code interpretation of FG function, named Fg_* and derived from FrameGrabber
#define FG_RETURN(x) checkReturn((x), std::string(__FILE__), __LINE__, std::string(#x), false)

/// dangerous but simple helper macro for return(incl. return) code interpretation of SGC function, named Sgc_* and derived from SisoGeniCam
#define SGC_RETURN(x) checkReturn((x), std::string(__FILE__), __LINE__, std::string(#x), true)

#endif // SISO_HELPER

Related function in context:

int checkReturn(int ReturnCode, std::string call_file, unsigned int call_line, std::string call_func, bool sgc)
{
    if (ReturnCode < (sgc ? SGC_OK : FG_OK))
    {
#pragma message(__LOC__ "Please change this to std::source_location with C++20") // https://en.cppreference.com/w/cpp/utility/source_location
        // std::cout << "(checkReturn " << __FILE__ << ":" << __LINE__ << " reporting)"<< std::endl;
        std::cout << "triggered in " << call_file << ": line" << call_line << std::endl << " called function: " << call_func << std::endl << " >> ";
#ifndef NOCAMERA
        std::cout << (sgc ? "GenICam" : "Runtime") << " Error[" << ReturnCode << "]:" << (sgc ? Sgc_getErrorDescription(ReturnCode) : getErrorDescription(ReturnCode)) << std::endl;;
#else
        std::cout << (sgc ? "GenICam(NOT EXPECTED)" : "Runtime") << " Error[" << ReturnCode << "]:" << getErrorDescription(ReturnCode) << std::endl;;
#endif
    }
    return ReturnCode;
}

Best regards

Dear Chroistoph,

Uploading the images and writing the images to disc by C++ functions is the standard way of doing this.

You can use the CoefficientBuffer for this , as you already do, or use the ImageInjetor from the Debugging library.

    /*============ ImageInjector : Inject ============== */
    int Device1_Process0_Source_Inject_Mode_Id = Fg_getParameterIdByName(fg, "Device1_Process0_Source_Inject_Mode");
    FG_CHECK(Device1_Process0_Source_Inject_Mode_Id);

    unsigned int Device1_Process0_Source_Inject_Mode;
    Device1_Process0_Source_Inject_Mode = InjectMode::Inject;
    FG_CHECK(Fg_setParameterWithType(fg, Device1_Process0_Source_Inject_Mode_Id, Device1_Process0_Source_Inject_Mode, 0));
...
    // ---------------------------------------------------------------------------
    // Frame Grabber: Grab images
    // ---------------------------------------------------------------------------
    int Device1_Process0_Source_Inject_ReadyForInjection_Id = Fg_getParameterIdByName(fg, "Device1_Process0_Source_Inject_ReadyForInjection");
    FG_CHECK(Device1_Process0_Source_Inject_ReadyForInjection_Id);

    unsigned int ReadyForInjection = -1;

    int Device1_Process0_Source_Inject_ImageFile_Id = Fg_getParameterIdByName(fg, "Device1_Process0_Source_Inject_ImageFile");
    FG_CHECK(Device1_Process0_Source_Inject_ImageFile_Id);

    const char * Inject_ImageFileName = "unset";

    int Device1_Process0_Source_Inject_InjectFromFile_Id = Fg_getParameterIdByName(fg, "Device1_Process0_Source_Inject_InjectFromFile");
    FG_CHECK(Device1_Process0_Source_Inject_InjectFromFile_Id);
...
// within the acquisition loop, sorry for using fprintf :-)
...
    fprintf(stderr, "Waiting for Injection ready ..");
        do {
            FG_CHECK(Fg_getParameterWithType(fg, Device1_Process0_Source_Inject_ReadyForInjection_Id, &ReadyForInjection, 0));
            fprintf(stderr, ".");
        } while (ReadyForInjection != InjectReady::yes);
        fprintf(stderr, "OK\n");
        auto fn = filename.string();
        Inject_ImageFileName = fn.c_str();
        fprintf(stderr, "Uploading %s ", Inject_ImageFileName);
        FG_CHECK(Fg_setParameterWithType(fg, Device1_Process0_Source_Inject_ImageFile_Id, Inject_ImageFileName, 0));
        fprintf(stderr, "...", Inject_ImageFileName);
        int Device1_Process0_Source_Inject_InjectFromFile = InjectReady::yes;
        FG_CHECK(Fg_setParameterWithType(fg, Device1_Process0_Source_Inject_InjectFromFile_Id, Device1_Process0_Source_Inject_InjectFromFile, 0));
        fprintf(stderr, " OK\n");

        fprintf(stderr, "Sending ... ", Inject_ImageFileName);
        Device1_Process0_Source_RUN_Mode = SetSignalStatus::Pulse;
        FG_CHECK(Fg_setParameterWithType(fg, Device1_Process0_Source_RUN_Mode_Id, Device1_Process0_Source_RUN_Mode, 0));
        fprintf(stderr, "OK\n");

        int timeout_secs = 1; // because of file upload and start requiring time
        frameNo0 = Fg_getLastPicNumberBlockingEx(fg, frameNo0 + 1, 0, timeout_secs, pmem0);

        void *iPtr0 = Fg_getImagePtrEx(fg, frameNo0, 0, pmem0);

        // save file nicely, suing openCV function for save. SiSo IO will work similar
        cv::Mat result(height0, width0, CV_8UC1, iPtr0);
        auto targetFilename = filename.filename();
        auto targetPath = filename.parent_path().string() + "/Runtime/";
        auto target = targetPath + targetFilename.string();
        cv::imwrite(target, result);

I hope the above code snippets are ok...

Best regards

Dear Danna,

As far as I understand this thread can be closed now, but please let me know?

For different topics you can start a new thread of course.

Best regards

Dear Danna,

Quote from Danna

And,I want to know if I can obtain the maximum gray value of image and save it?

You can use FrameMax for this.

Below sketch extracts the frame maximum:

pasted-from-clipboard.png

The folowing probe shows the Maximum as saved in the last pixel of the input image:

pasted-from-clipboard.png

This VA-Design MaxPixelValueSaveStatus.va was used to produce the above output.

Best regards

Dear Danna,

perfect.

Quote from Danna

I merge a data stream and get rid of one RAM,

and my VA is working as expected for now.

Best regards,

Björn

Dear Danna,

I pinned this thread now into the forum entry, so that maybe additional people from the community start to support us or you to go into the direction of solution.

Best regards

Dear Danna,

To go into this make a simple sketch of the data flow structure in order to understand where the data needs to be stored. You can understand the Tx/Rx link as a connected link so using memory on one or the other side is same behaviour.

Best regards

Dear Danna,

You can merge the data of both loops into a single Buffer.

Using a FIFO is not an option for full images due to limited amount of FPGA ressources.

When you merge both streams you need only a single Rx/TxImageLink-Channel.

This single stream will utilize a single memory=RAM module.

Quote from Danna

Am I right?

Merge the data that runs in a circle to a single link into a single memory.

Best regards

Dear Danna,

Simply look into the documentation of the MergePixel, it is a really easy to understand o-type operator.

The bits of two streams get a single pixel. Two 8bit values become a 16 bit pixel, where the upper input represents the LSBs and lower inputs are MSBs...

Best regards

Dear Danna,

The RAM for the camera should be there...

But there is a solution.
I look into your design and see that there is a Buffer inside the loop that can be used for two cases.

Quote from Danna

I think maybe I can only get rid of the ImageBuffer after Camera?

The data processing network is a O-type network, so you can merge all the data that is running in circle into a single buffer.
You need a memory per loop image context, but both images can share the same RAM module.

Additionally you can get rid of the sequence in memory by using a sum and a fixed division, it would reduce precision, but maybe that is ok.

For sharing memory you can use: MergePixel to align both result image pixels and Cast Bitwidth and shift right, to extract it after the memory.

Best regards

Dear Danna,

On each current VA platform, mE5-MA-VCL in your case, there are only 4 RAM modules available that can be used by Memory Operators like ImageBuffer etc.

Quote from Danna

the 5th RAM index,

In the ressource overview in VA you can see 5 RAM modules being requested, while there are only 4:

pasted-from-clipboard.png

So you need to get rid of 1 of these.

Best regards

Dear Danna,

Here we have a strange issue.

Quote from Danna

I need to use the ImageBuffer handle each frame one by one,

You would like to use a 5th RAM index while there are only 4. You need to remove a single RAM to get down to 4 RAMs to make this work. Difficult to see from the UI.

Best regards

Dear SWe,

Quote from previous

TOP 10 (ordered by personal impression of importance, high = 1 ... low = 10)
Label Image with correspondance to object feature structure

From my point of view a label image related to the corresponding object (found by 1D or 2D Blob-Analysis) would be a drastic benefit to the VA functionality in general, since it would enable additional investigations and feature extractions.

Please have a look into this powerfull approach and especially into the citations section.

For further reading; if access given: >>

Dear Danna,

After a first look into your design and finding some small indicators I got a good clue on what is going wrong.
The next steps from my side will be finding a better understanding and imlementing some corrections.

Best regards

Quote from B.Ru

So as soon as I find some time I will look into it and let you know.