Lossless encoding on FPGA

  • Hello,

    Recently days, many customers are interested in saving all acquired images. Traceability is famous application but some customers want to save image for deep learning training.

    After saving image, there are two types way how to use images.

    1. Human check images

    2. PC inspect images

    1st case, lossy image is no problem. 2nd case, most customer don't hope lossy image because some parameters like threshold are different. DL training case is also. Because raw images are passed to DL core directly. If lossy images are used for training, it will be reason of low accuracy. So customer hope lossless compression needed.

    Do you have any solution?

  • Hello Saito-san,

    Thank you for your question concerning compression.

    We have a JPEG compressor within VA that is lossy and will introduce compression artefacts.

    For lossless compression we do not have a direct operator.

    Things like run-length encoding is possible based on VA operators, but for real images including noise the efficiency / compression factor is limited.

    A run length encoding of the MSBs could be a straight forward way that reduces the amount of required memory a little.

    But that is proprietary and pretty application specific.

    Our runtime supports very secure mechanisms to use the host memory as transfer target for the real images and gives the compression approach to the host system CPU/GPU. But I am pretty sure that you would like to perform such a compression within the FPGA and implement it in VA.

    In case you have a white-paper on a simple lossless compression I will have a look into it and let you know if VA operators can be used to assemble such an approach.

    The only operator in VA that may help is: PackBitsRLE

    I am sorry, that I do not have a nice example on this.

    Best regards,


  • Hello Björn-san,

    thank you very much for your answer. I got your points. As you said, sometimes, RLE is not effective.

    >In case you have a white-paper on a simple lossless compression I will have a look into it and let you know if VA operators can be used to assemble such an approach.

    Thank you very much for your kind suggestion. But currently I don't have specific projects. However, we got many leads about compression in the last ITE show in Japan. At that moment, many customer hoped lossless compression to start evaluation. So I asked.

    Ryo Saito

  • Dear Johannes-san,

    thank you very much for your question.

    Yes, I think I can progress some projects with Compression Beyond. It receive our attention. Actually, we have some ace2 projects with this feature. I'm sure CameraLink and CXP customer also interested this feature.

    Ryo Saito

  • Hello Björn-san,

    please let me ask you additional question about RLE. As you told me, there is PackBitsRLE operator. It might be good for some customers. I might could suggest it but images is 16 bit.

    My question is following two;

    1. Following sample is not PackBitsRLE, correct?

    C:\Program Files\SiliconSoftware\VisualApplets_3.2\Examples\Processing\Advanced\RunLengthEncoder\RunLengthEncoder.va

    2. It is possible to use 2 PackBitsRLE operator for 16bit image, I think.

    But this is proto type operator, if customer hope to use current generation board and next generation board as well, it might be impossible, correct?

    Ryo Saito

  • Hello Saito-san,

    An option for compression would be RLE compression for grouped bit-planes.

    For example the MSB's normally show lower amount of changes and can get compressed for efficient, while lower bits show higher amount/frequency of changes. From that point of view 16bit data can get compressed. That would end up in a proprietary kind of format.

    1.) I doubt that the mentioned example shows pure PackBits compression.

    2.) In case the PackBits operator would not be supported by future or more modern grabbers (details is unknown to me) you can requild it on the basis of existing low-level operators. I am pretty sure that is a feasible option. So 1.) is a good starting point for that.