New Color Jpeg operator

  • Hello,


    I am testing New Color Jpeg Operator.

    Is it possible to build with Design Colock 170MHz in VCL?

    The Build does not succeed with design clock 170 MHz in our environment.


    Here is environment.

    -. ISE 14.7

    -. VA 3.2

    -. Test example : \examples\Processing\Advanced\JPEG\mE5-MA-VCL\JPEG_SingleFullAreaBayer.va




    So I tested with Desing clolck 125MHz.

    The build was sucess and we can get jpeg(include header) image in microDisply.

    In the next step, we created jpeg viewer using "Jpeglib Turbo" for fast Jpeg decording.


    Camera : Basler acA2040-180kc

    -. 8tps 82MHz 2048 x 2048 , 150fps



    Image size : 1024 x 1024

    Result(before decording in microDisplay) : 295fps (quality 50%)

    Result(after decording in our program) : about 280fps (quality 50%)


    Image size : 2048 x 1024

    Result(before decording in microDisplay) : 295fps (quality 50%)

    Result(after decording in our program) : about 145fps (quality 50%)


    Image size : 2048 x 2048

    Result(before decording in microDisplay) : 150fps (quality 50%)

    Result(after decording in program) : about 72fps (quality 50%)



    Visual Applts is not performance related, but is there a recommended decording library for increase decording speed?


    Thanks.

  • Hello Sangrae_Kim


    Thank you for testing the JPEG and thank you for the feedback.


    For all microEnable 5 marathon frame grabbers we recommend to use XILINX Vivado instead of ISE. The build time is much faster than with ISE and you get successful builds with Vivado where you will have timing errors with ISE. Vivado is free except for the marathon VCLx frame grabber.


    With Vivado you should not get a timing error for JPEG_SingleFullAreaBayer.va with 170 MHz. However, if you use 160MHz or 125 MHz the implementation will still work but is a little slower.


    Concerning your question about JPEG decoding in the PC:

    The decoding speed depends on

    - does the decoder use CPU or GPU

    - is the decoder optimized for restart intervals within the JPEG files

    - are you decoding multiple files simultaniously in multiple CPU cores or one after each other?

    - if you write the files to HDD and reload for decoding the HDD speed might be the limiting factor.


    There exists many articles in the internet for benchmarking of JPEG decoders. I heard that the mangolibrary uses a very good decoder, but have never testet it.

    So for example this article: https://t0rakka.silvrback.com/jpeg-decoding-benchmark


    So at this moment I don't have a recommendation for the decoding. But it is good to collect some reviews in the forum.


    Johannes


    Johannes Trein
    Group Leader R&D
    frame grabber

    Basler AG




  • Hello Sangrae


    may I know which decoder you are using for GPU decoding? This is also very interesting for me.


    Johannes


    Johannes Trein
    Group Leader R&D
    frame grabber

    Basler AG



  • Hello Johannes,


    I tested nvJPEG library.

    The result is after decoding on the GPU. (50 % jpeg compression)

    ** Test Result : 2048 x 2048 = 150fps , 2048 x 1024 = 295fps
    For the information,

    The nvJPEG image buffer consists of each RGB channel.

    So we need to merge each channel in CPU side again for 24bit image.

    I don't have enough experience with GPU processing and multi core processing .

    Step 1 : FPGA(encoding) Got Full speed (2048 x 2048 = 150fps)

    Step 2: GPU(decoding) Got Full speed (2048 x 2048 = 150fps)

    ** Without copying memory from GPU to host

    Step 3: Copy image data of each channel from GPU to HOST memory. ( decreased frame rate)

    ** Just copy Red channel only ( 2048 x2048 = 140fps) copy Green&Blue channel (decrease frame rate more)

    Step 4: RGB Color merge

    This is the test result so far.

    I need more analysis of Step 3 & 4 for increase speed.

    Thanks.