Posts by B.Ru

    Here in a screenshot sequence...


    1) Design with connected Probe "Sequence" of interest:


    pasted-from-clipboard.png


    2) Go to Simulation dialog, enter required amount of N processing cycles and press start to proceed:


    pasted-from-clipboard.png


    3) Close simulation dialog and switch into the probe-ciew by double-click onto it:


    pasted-from-clipboard.png


    4) Click onto an image within the "Sequence Viewer" at the bottom and press Ctrl+A:


    pasted-from-clipboard.png


    5) Press right mouse button within "Sequence Viewer" and select "Save" to Save all images...

    The selected name will get a counting image number N extention in format "filename%5d", N.


    Best regards,

    Hi Oliver and Jesse,


    It was a pleasure to discuss the VA design approach with both of you.

    One additional hint:

    • In case the ImageBufferMultiROI(dyn) is not flexible enough to generate additional kinds of overlapping image regions you could potentially use the FrameBufferRandomRead operator for it. One trade-off is the limitation to a single image to image relationship in between of the input and the output, but it generally enables an additional left right shift including overlap.

    One application would be auto-follow of a certain region of image.


    Best regards,

    Hi Jesse Lin,


    Thank you for your feedback.

    And I try to use other methods to remove unwanted frames ,but the buffer will overflow. Camera line rate = 10k Hz.


    Please give me some advice.


    Based on your input the line width is 8k = 8192 pixels per line and you can see a FillLevel at a linerate of 10 kHz of 75%.
    A certain FillLevel is OK, but we need to look into it based on the resulting/required bandwidth.
    One possible bottle-neck is the parallelism within the links, and especially:

    • Memory Interface
    • DMA performance

    The CXP camera interface is focussing up to 2 GB/s:


    pasted-from-clipboard.png


    Since you nearly double the bandwidth due to the overlap, please consider to use a higher(up to double) paralleism in the links.


    The DMA will accept a connection of up to 16x 8 bit = theoretical 2 GB/s, practically it will be limited to 1800 MB/s.
    The memory interface can handle up to 11.2 GB/s (shared between all RAM-modules) and read/write access will add up.


    When I look into your design I would recommend the approach below to generate an overlap on basis of a single RAM:


    pasted-from-clipboard.png

    That would save RAM modules/FPGA ressources and you do not need to write the same data twice...

    Related VA design: LineScan_OverlappingAreaImages.va


    Based on the ROI settings within BufferX2 you can reduce the overlapping part easily...
    I have seen that you use a more complex approach on when to overlap, but that is something you can adopt into this design.
    Just consider using DynamicROI operator if you require a more dynamic approach into the above functionality.
    ImageBufferMultiROIdyn would be a second valid candidate.
    Enjoy.


    Best regards,

    Hi Jesse,

    Please be aware that a following image is required to run the second (lower) channel of "module26".

    Taken from:

    https://docs.baslerweb.com/liv…nization.InsertImage.html


    "The operator InsertImage multiplexes a number of n input links I[0] .. I[n-1] into the output link O. Thus the operator outputs the input images of all inputs in sequential order at O.

    The operator forwards the input images to the output one after the other. First, input link I[0] is processed, next link I[1]. After link I[n-1] the operator starts with the next image at I[0] again etc. The operator waits until an image at a currently selected input is present. Therefore it is not possible to skip inputs."...


    Best regards,

    Björn

    Hi,


    you can find the solution for removing unwanted deadlock as a screenshot below and design here: mE5MA_VCL_Overlap_fixBRudde.va

    pasted-from-clipboard.png


    Since InsertImage will only forward on a single channel, the others are in wait (blocked, inhibit, stop, ...) state and require buffering, cause by all channels being sourced by the same M-Type: "Sync" in here.
    So the RAM1 needs to be in fron of module 13.
    Please be aware that a following image is required to run the second (lower) channel of "module26".


    Best regards,
    Björn

    Hi Kevin,

    2) Can a speed up be achieved by splitting up an image into several ImageBufferMultiROIs?

    using multiple parallel RAMs would cause a potential speed-up. Please be aware that a shared memory concept would behave differently on the VA platforms there are. Additionally the speed-up could be achieved by overlapping regions.
    If you like we can focus on this topic during a conceptual coaching... Feel free to contact me for this.


    Best regards,

    Hi Kevin,


    Concerning your question:

    1) If the image would be split up in tiles, and each branch should compute a different tile the input for the remove image can either be obtained by a LUT like now - or by a modulo count with the divisor set 5 followed by an Is_NotEqual, e.g.:


    What would be best practice?

    I personally would prefer the LUT, because this would enable a decision on each single image within a sequence length being controlled by the LUT content per branch. An Is_"Condition" would be selective for the conditions complexity.
    In general: LUT in static condition would be the cheapest option for shorter sequences; and would enable a more dynamic approach with low ressource consumption.

    Best regards,

    Dear Kevin,


    The amount of RAM modules is limited to 4 on all platforms.

    When I looked at the simplified VA design, there is an option of using a single RAM module representing the requested functionality:
    Use a single RAM module in front of the splitting branch sending all required ROIs, one after the other.

    Within in each output link of the branch you can use RemoveImage, to select the requested images.
    To keep the bandwidht and memory available as high as above you can go for a duplication of this approach.

    Please let me know of there are additional questions.


    Sketch of intended and recommended solution, file attached Multi_Simple_Rois.va:


    pasted-from-clipboard.png


    Best regards,

    Hello,


    It is not possible to get an object area in sub-pixel precision. Area is always returned in unit pixels, because a single pixel is part of an object or not, since the VA blob analysis is working on binary images.


    Concerning sub-pixel precision and blob analysis it is normally about:

    The object's center of gravity (COG) position is getting returned by not nomalized sub-pixel precision,
    which means you have to divide the COG x & y components by the area to get sub-pixel precision.
    Simply add fixed point precision bits to the required division.


    Best regards,

    Hello Johannes,

    But it is very likely that you get a timing error. Moreover the operator can only be used with parallelism of four which makes it very inefficient at the share memory concept.

    While it may be possible to instanciate the ImageSequence operator by copy/paste into a shared memory platform design, please avoid this and use the alternative on the basis of FrameBufferRandomRead.

    @Lothar: Please use the approach I send to you by BDX.

    Best regards,

    Hi Theo,


    The ImageSequence operator does not exist for platforms using shared memory.

    Image Sequence operator wihtin a CXP board.

    But the simple workaround is using the FrameBufferRandomRead(FBRR) Operator:

    • AppendImage : Glue all images for sequence together and put it into FBRR
    • CreateBlankImage : Address FBRR with the expected output; Pixel By Pixel, Line By Line

    After FBRR you can Use SplitKernel/MergeKernel/ParallelUP/ImageFIFO to meet the expected bandwidth again.

    How to get bandwidth at paralleism = 1?

    Hide the input parallelism in a kernel-environment to meet the target memory depth.

    For a mE5-MA-VCX-QP the memory depth is 512 bit = 64 * 8 bit value:
    to get highest performance use the complete memory depth.


    In case of questions do not hesitate to contact me.


    Best regards,

    floating numbers in VA

    The following details will help you to implement floating point into the software interface:

    ParameterTranslation:


    https://docs.baslerweb.com/liv…FloatParamTranslator.html
    Formula Syntax: Mathematical Operations
    The syntax complies to the GenICam API standard in version 2.0. The allowed formula elements are identical to the formula elements defined in the GenICam standard:
    Basic operations:
    () brackets
    + - * / addition, subtraction, multiplication, division
    % remainder
    ** power
    & | ^ ~ bitwise: and / or / xor / not
    <> = > < <= >= logical relations: not equal / equal / greater / less / less or equal / greater or equal
    && || logical and / logical or
    << >> shift left / shift right
    Basic operations Conditional operator
    <condition> ? <true_expr> : <false_expr>
    Example: ${target.Value} = (${this.Value} > 0) ? 1 : 0;
    Functions:
    SGN(x) return sign of x. Returns +1 for positive argument and -1 for negative argument
    NEG(x) swap sign of x
    ABS(x) return absolute value of x
    SQRT(x) return square root of x
    TRUNC(x) truncate x, which means returning the nearest integral value that is not larger in magnitude than x
    FLOOR(x) Round downward, returning the largest integral value that is not greater than x
    CEIL(x) Round upward, returning the smallest integral value that is not less than x
    ROUND(x,precision) round x to the number of decimal fractional digits given by precision, with halfway cases rounded away from zero
    SIN(x) return sine of an angle of x radians
    COS(x) return cosine of an angle of x radians
    TAN(x) return the tangent of an angle of x radians
    ASIN(x) return the principal value of the arc sine of x, expressed in radians
    ACOS(x) return the principal value of the arc cosine of x, expressed in radians
    ATAN(x) return the principal value of the arc tangent of x, expressed in radians
    EXP(x) return the base-e exponential function of x, which is e raised to the power x: ex
    LN(x) return the natural logarithm of x The natural logarithm is the base-e logarithm: the inverse of the natural exponential function (exp).
    LG(x) return the common (base-10) logarithm of x
    E() return Euler's number, 2.7182818284590451
    PI() return circle constant, 3.1415926535897931
    Functions Example: ${target.Value} = NEG(${this.Value})
    Access to Parameter Properties
    The formulas can not only incorporate the values of parameters, but also specific properties of parameters, such as minimal value, maximal value, or step size:
    ${PathToModule/Module.ParamName.From} or ${PathToModule/Module.ParamName.Min}: minimal valid value of parameter PathToModule/Module.ParamName.
    ${PathToModule/Module.ParamName.To} or ${ PathToModule/Module.ParamName.Max}: maximum valid value of parameter PathToModule/Module.ParamName.
    ${PathToModule/Module.ParamName.Inc}: Increment (step size) between two valid values of parameter PathToModule/Module.ParamName.
    ${PathToModule/Module.ParamName.Enum("EnumName")}: Integer value of enumeration name EnumName.


    Best regards,

    Dear Kevin,


    Thank you for your precise question.
    There is one kind of valid float values you can use: ParameterTranslations...

    In VA native(FPGA) processing you will need to use fixed point arithmetics.

    I am fairly new to VA and was wondering how to work with floating constants that I need in my computation.


    Below you can find a simple example into fixed point arithmetics:


    pasted-from-clipboard.png


    The ShiftLeft will give you precision (here 10 bit) and I recommend RND to reduce to lower precision.
    ShiftLeft by 10 bit will give you a resolution of 10bit = 1024 steps in between two integer values.
    When you require more, use more bits...

    Best regards,

    Dear MichKul,


    Based on the previous modifications of S.We I added a valid list handling in case of empty object list, and reduced the kept object to a single one for comparison.
    Area and COG X Y differences are send to the DMA now.


    Enjoy ;-)
    Blob_meIV-CL_modSWe_BRudde.va <- Register is not set to Frame-Mode (that is the mistake)

    Version in the post below is fixed ...

    Best regards,