An FPGA-Based LOCO-ANS Implementation for Lossless and Near-Lossless Image Compression Using High-Level Synthesis

Round 1

Reviewer 1 Report

The manuscript presents an HLS implementation for the LOCO-ANS algorithm.

Even though HLS does not allow to design of tailored hardware, the results are quite good.

The paper describes the research in-depth. However, there are some important details missing.

HLS synthesis heavily relies on pragmas and directives to implement efficient hardware. Information about the aforementioned (e.g. unroll and pipeline) should be added for every of the presented algorithmic blocks.

Author Response

Dear Editors and Reviewers,

We would like to thank the reviewers for their feedback. We have addressed all comments, modifying the article when necessary, and believe that as a result of this, the article has become much stronger and clearer. Additionally, we discuss below all criticism, suggestions, and responses, including how we have improved the paper. Reviewers' comments are in bold, and our responses are in plain text.

As a summary, the most significant changes are the following:

• We have restructured sections 4 and 5 to improve the presentation of the results and the evaluation of the results.
• We have included additional details of how the presented system performance was accomplished.
• We have improved the compression comparison by including other encoder configurations.
• We have improved the description of the error metric and included examples of compressed images.

We are uploading (a) our point-by-point response to the comments (below), (b)  a document showing the differences with the previous version of our manuscript, with insertions in blue and curly underlined, and deletions in red and struck through and (c) a clean updated manuscript (PDF main document).

 

With kind regards,

Tobías, Gustavo and Jorge

 

Response to reviewers comments

The manuscript presents an HLS implementation for the LOCO-ANS algorithm. Even though HLS does not allow to design of tailored hardware, the results are quite good. The paper describes the research in-depth. However, there are some important details missing. HLS synthesis heavily relies on pragmas and directives to implement efficient hardware. Information about the aforementioned (e.g. unroll and pipeline) should be added for every of the presented algorithmic blocks.

We thank the reviewer for the comments and suggestions. Taking them into account, we made the following changes to the article:

• Relevant pragmas were added to the “Pixel loop algorithm structure” algorithm.
• A new algorithm description was added to better explain the St Quantizer module.
• Throughout section 3.2 we improved the system description, adding the directives and some details of how the desired performance was accomplished.

We want to thank you very much for your review. Your comments have been very helpful to improve the quality of the paper.

Reviewer 2 Report

The manuscript is devoted on the evaluation of variations made in the high-level design of an image compressor. It could just as easily be on the FPGA design of the compressor as the title of the submitted text states. However, the technical design supplies necessary data but the evaluation addresses the underlying scientific question. Unfortunately, both aspects are not really dug out extensively. The technical design gives much data but reads as a status report. The high-level design creates the front from which an efficient mapping could rise up. Important supporting detail is referred to previous published documents. As a consequence, the paper cannot be understood without having the supporting documents at hand [227].

The proposed publication reads partly nicely and is properly written as part of a diary. The structuring of section 5 is remarkable. There is no 5.2.2 and on; therefore subsection 5.2 is not meaningful. Many of the literature references indicate the development milestones. Such disguised self-citations are generally seen as bad practice in publication and will consequently be punished in the citation values. There are good bibliographical reasons for not having abbreviations in the abstract, but few ones for having them. There are a number of language issues, few enough to list some examples here:

[76] “to fine-tune” cannot be used as “fined-tuned”

[550] “latter” means probably “later”

[556] “bottleneck” is not a verb

[573] “coder” is probably meant to be “coders”.

There are also some typos, such as [118] “Bernulli” and [307] “exist”. The legend to Table 5 is not clear. Do you mean “with reference to the critical path length” instead of “the critical observed”. It is nice to see a list of abbreviations added to the text. However, some of the listed abbreviations (such as FPGA) are superfluous, others (such as LOCO) should definitely appear. This is typical for the overall text, especially in section 5 where the authors refer to undocumented expert knowledge. For instance, they notice in [581] that “allowing for vertical tiles has a positive impact”. Also, in [596], the authors refrain from reporting but “stress that the comments are still applicable”. This makes it less readable to the average interested reader.

The discussions around the advantages of HDL-level design are rather imprecise. For instance [287]: though it is true that replacing a small amount of text lines is easier than a large amount, the difference is less apparent using computer-aids such as ‘cut-and-paste’. In subsection 5.3 the authors discuss further improvements as method for design improvements, which comes after the wagon: high-level design comes first, iterations come later. One may contemplate to turn this subsection combined with the conclusions to a single “results and discussion” part. In [532/33] it is remarked that there is “no clear way to compare”. Still, subsection 5.3.2 makes an ingenious attempt. By lack of structuring the actions in a bullet-list, it remains just a soup of thoughts and data and does not achieve the required clarity. Then, finally on line [634], it is simply stated that the “experimental results support the analysis”.

Measurements cannot be replaced by datasheet values in critical comparisons [406]. One of the reasons is that actual chip values differ between chips which makes a comparison dependent on selected parts [520]. This makes also that feature windows are regularly used in the specification of parts-to-be-bought. But for the offered evaluation, the relative ordering is much more important than the absolute values.

Overall, the question of high-level synthesis is rather on “how” and not on “whether”. Everybody has his preference and tells successful stories good behavioral algorithm and description languages. Occasionally, it has to be tuned for new field-programmable architectures but much of the work has already been done in the past. I suggest to take this part out and refocus the message, especially with reference to the title.

Further, the introduction should come with 1-liners on the research goal and the ideal is to close the text with reflections on how well the goal is achieved.

Author Response

Dear Editors and Reviewers,

We would like to thank the reviewers for their feedback. We have addressed all comments, modifying the article when necessary, and believe that as a result of this, the article has become much stronger and clearer. Additionally, we discuss below all criticism, suggestions, and responses, including how we have improved the paper. Reviewers' comments are in bold, and our responses are in plain text.

As a summary, the most significant changes are the following:

• We have restructured sections 4 and 5 to improve the presentation of the results and the evaluation of the results.
• We have included additional details of how the presented system performance was accomplished.
• We have improved the compression comparison by including other encoder configurations.
• We have improved the description of the error metric and included examples of compressed images.

We are uploading (a) our point-by-point response to the comments (below), (b)  a document showing the differences with the previous version of our manuscript, with insertions in blue and curly underlined, and deletions in red and struck through and (c) a clean updated manuscript (PDF main document).

 

With kind regards,

Tobías, Gustavo and Jorge

 

 

Response to reviewers comments

The manuscript is devoted on the evaluation of variations made in the high-level design of an image compressor. It could just as easily be on the FPGA design of the compressor as the title of the submitted text states. However, the technical design supplies necessary data but the evaluation addresses the underlying scientific question. Unfortunately, both aspects are not really dug out extensively. The technical design gives much data but reads as a status report. The high-level design creates the front from which an efficient mapping could rise up. 

Thanks for your comments. First, we would like to comment on what guided this work.

It has two main goals. One is to explain the hardware architecture we designed for the LOCO-ANS encoder. The other is to answer whether a hardware implementation of the proposed algorithm has something to offer to real-time video applications, in particular, and to highly constrained scenarios, in general (as raised in the CFP). We also have to take into account that the LOCO-ANS algorithm is based on JPEG-LS. We proposed changes to the standard algorithm, then naturally, in this work we try to evaluate the impact of these changes, in particular for hardware implementations. In the evaluation of the results, we do not only assess this matter but also compare different encoder configurations, and we analyze the encoder latency as a function of its parameters, which is a key indicator to implement this image compression algorithm in real-time applications.

Taking these comments into consideration, as well as your suggestions, we have added more details to the description of the design in order to better explain the key aspects of the architecture. Also, we have restructured sections 4 and 5 to provide a clearer evaluation.

 

Important supporting detail is referred to previous published documents. As a consequence, the paper cannot be understood without having the supporting documents at hand [227].

Given that this paper focuses on the hardware implementation, we refer to other previous publications for additional details the reader might be interested in, but we do not consider them fundamental to understand this article. Of course, as suggested by the phrase “we do not consider”, this has a subjective component. Taking your comment into account, we revised the article with the aim to make it more self-contained. In particular, regarding your reference (line 227 of the originally submitted manuscript), we added the HLS implementation of the corresponding module.

 

The proposed publication reads partly nicely and is properly written as part of a diary. The structuring of section 5 is remarkable. There is no 5.2.2 and on; therefore subsection 5.2 is not meaningful. 

The results and discussion sections were restructured taking these comments into consideration.

 

Many of the literature references indicate the development milestones. Such disguised self-citations are generally seen as bad practice in publication and will consequently be punished in the citation values. 

We would like to remark that there are only two references (out of 31) to publications written by any of the authors, and only one of them might be described as a development milestone. In that work, we presented the algorithm design and evaluation of LOCO-ANS, therefore we need to reference it as it is the prior work we rely on. We do not attempt to inflate citations of that previous work. We believe it is reasonable to reference previous works that align with the current one.

Probably, the fact that 4 of the implementations in table 4 corresponds to this work might create some confusion. These 4 implementations are the result of this work (and not previous ones) and thus, we include them in the comparison. In that same table, there is one reference to the LOCO-ANS software implementation, which is added to be able to clearly observe the impact of having this encoder in hardware with respect to a software implementation of the same algorithm.

There are good bibliographical reasons for not having abbreviations in the abstract, but few ones for having them.

Thanks for your comment. We have revised the abstract taking it into consideration.

 

 There are a number of language issues, few enough to list some examples here:

[76] “to fine-tune” cannot be used as “fined-tuned”

[550] “latter” means probably “later”

[556] “bottleneck” is not a verb

[573] “coder” is probably meant to be “coders”.

There are also some typos, such as [118] “Bernulli” and [307] “exist”. The legend to Table 5 is not clear. Do you mean “with reference to the critical path length” instead of “the critical observed”. 

We really appreciate these corrections. We have proofread the text looking for these and others we overlooked, and corrected them.

 

It is nice to see a list of abbreviations added to the text. However, some of the listed abbreviations (such as FPGA) are superfluous, others (such as LOCO) should definitely appear. 

Taking this comment into account, we have revised the list of abbreviations.

 

This is typical for the overall text, especially in section 5 where the authors refer to undocumented expert knowledge. For instance, they notice in [581] that “allowing for vertical tiles has a positive impact”. Also, in [596], the authors refrain from reporting but “stress that the comments are still applicable”. This makes it less readable to the average interested reader.

Taking your comment into account, we revised the article with the aim to remove these references or state them more clearly. Regarding the first one (line 581 of the original manuscript), we referred to a previous experiment that showed this effect, but now we include this information in the new “Compression trade-offs” section. 

Regarding the phrase “stress that the comments are still applicable”, we do not refer to any undocumented expert knowledge but to table 5, where Virtex 6 are reported for the fastest and slower speed grade. The implementation we take as a reference point does not report the speed grade, However, all the considerations mentioned regarding the superiority of Virtex 6 over Zynq 7020, are still applicable even if we consider the slowest Virtex 6.

We have rephrased the sentence with the aim to make it clearer.

 

The discussions around the advantages of HDL-level design are rather imprecise. For instance [287]: though it is true that replacing a small amount of text lines is easier than a large amount, the difference is less apparent using computer-aids such as ‘cut-and-paste’. 

The idea that we tried to convey here is that this is not just a matter of moving code around, but a whole redesign is needed in the case of HDL. After specializing the code to work only for lossless, a great part of the pipeline is restructured. In order to achieve this goal in HDL would be closer to designing a new module. Of course, a quick lossless only HDL implementation (taking the near-lossless version as a starting point) is possible, and area improvements would be obtained. However, without restructuring the pipeline, we do not expect the performance impact to be significant. 

We have modified this sentence with the aim to make the message clearer.

In subsection 5.3 the authors discuss further improvements as method for design improvements, which comes after the wagon: high-level design comes first, iterations come later. 

We do mention the existence of optimization in the near-lossless encoders comparison section.  We don’t do this assuming that the encoder could be improved, just because this is a first, high-level design. Furthermore, we do it because many optimizations have been identified and mentioned throughout the text.

Moreover, we mention it to remark that these good results come up comparing a new architecture against JPEG-LS architectures, which have been optimized for years.

 

One may contemplate to turn this subsection combined with the conclusions to a single “results and discussion” part. 

Thanks for the suggestion, but following MDPI directives and given the length of the discussion section, we have kept a separate section to summarize the conclusions.

 

In [532/33] it is remarked that there is “no clear way to compare”. Still, subsection 5.3.2 makes an ingenious attempt. By lack of structuring the actions in a bullet-list, it remains just a soup of thoughts and data and does not achieve the required clarity. 

Taking all these comments into consideration, we have restructured sections 4 and 5 to improve the clarity of the text. 

 

Then, finally on line [634], it is simply stated that the “experimental results support the analysis”.

The last sentence of the conclusion does state a result of our analysis, which is based on the experimental results. We do not see the issue with this, as the sentence fulfills the main objective of a conclusion.

 

Measurements cannot be replaced by datasheet values in critical comparisons [406]. One of the reasons is that actual chip values differ between chips which makes a comparison dependent on selected parts [520]. This makes also that feature windows are regularly used in the specification of parts-to-be-bought. But for the offered evaluation, the relative ordering is much more important than the absolute values.

In that comparison, we are comparing the throughput of the decorrelators and of the coders for each implementation. That is, taking the implementation results of a given configuration in a given chip, we compare the throughput of these two subsystems. 

We agree that relative values make more sense in this case, and that’s why we do compare in relative terms.

Taking this remark into account, we have added a comment to the sentence to clarify the comparison we are making there.

 

Overall, the question of high-level synthesis is rather on “how” and not on “whether”. Everybody has his preference and tells successful stories good behavioral algorithm and description languages. Occasionally, it has to be tuned for new field-programmable architectures but much of the work has already been done in the past. I suggest to take this part out and refocus the message, especially with reference to the title.

Further, the introduction should come with 1-liners on the research goal and the ideal is to close the text with reflections on how well the goal is achieved.

Thanks for your suggestions. Taking them into consideration, we have added more details to the presentation of the design in order to further transmit the key aspects of the architecture. We didn’t question whether we would be able to implement this system with high-level synthesis, and not even doing it efficiently (although as you mention, it is not always easy to find the “how”). However, in the literature and in our experience, we find that HLS still establishes a trade-off between development time and QoR (quality of results). This is particularly true for certain architectures that are harder to describe with a sequential language than with an RTL one. We have added a small change in the introduction aiming to clarify that we do not question whether it is possible to implement this using HLS, but we still state that it tends to imply a penalty.

Regarding the questions, these are just a formalization of what a new architecture design tries to answer. Some of these are: how does it compare to others? Or, what limits the performance of this architecture? Then, we see them aligned with the article title.

 

Thank you very much again for your review.  Your comments have been very encouraging and useful to improve the quality of the paper.

Reviewer 3 Report

This work describes a hardware implementation of the LOCO-ANS algorithm which advantageously compares with JPEG-LS hardware implementation. Hence, it could be a great tool for real-time video compression.  LOCO is probably a good name for such a crazy algorithm ^^

In general, the article sounds scientifically grounded and is well-presented, in the sense that the objectives of the work and the key take-overs are clearly stated. 

On the other hand, three aspects that could be improved are:

• The presentation of the data used for comparison. And if possible, to not limit the comparison to a single dataset.
• Along these lines, it would be nice to see an experimental validation of the MAX error (NEAR). Maybe something like the resemblance between the original image and the compressed image as a function of the error parameter, with one or two comprehensive snapshots.
• Finally, this error limit, although well explained in the article, is difficult to understand from a user perspective. Could the authors elaborate on what means to have a limit of 5, 10, or 25 errors for example?

Author Response

Dear Editors and Reviewers,

We would like to thank the reviewers for their feedback. We have addressed all comments, modifying the article when necessary, and believe that as a result of this, the article has become much stronger and clearer. Additionally, we discuss below all criticism, suggestions, and responses, including how we have improved the paper. Reviewers' comments are in bold, and our responses are in plain text.

As a summary, the most significant changes are the following:

• We have restructured sections 4 and 5 to improve the presentation of the results and the evaluation of the results.
• We have included additional details of how the presented system performance was accomplished.
• We have improved the compression comparison by including other encoder configurations.
• We have improved the description of the error metric and included examples of compressed images.

We are uploading (a) our point-by-point response to the comments (below), (b)  a document showing the differences with the previous version of our manuscript, with insertions in blue and curly underlined, and deletions in red and struck through and (c) a clean updated manuscript (PDF main document).

 

With kind regards,

Tobías, Gustavo and Jorge

 

Response to reviewers comments

The presentation of the data used for comparison. And if possible, to not limit the comparison to a single dataset.

Taking this comment into account, a new section devoted to the compression comparison was added with the aim to improve its presentation. 

In the previous work [1], where we presented the algorithm design and evaluation, we used two datasets to compare its performance against other relevant codecs.  The results were basically the same for both of them, however the Rawzor dataset is better known, and it is easier to access it. For these reasons, we chose to use the Rawzor dataset in this work.

 

Along these lines, it would be nice to see an experimental validation of the MAX error (NEAR). Maybe something like the resemblance between the original image and the compressed image as a function of the error parameter, with one or two comprehensive snapshots.

The maximum error is ensured by construction. However, we do verify the correctness in the tests to detect possible errors in the algorithm or its implementation.

Considering your suggestion, and taking also into account your previous comment, we added an appendix with two pictures coming from two datasets. Both of them are shown in their original version and after processing it with a NEAR (error tolerance) equal to  3.

 

Finally, this error limit, although well explained in the article, is difficult to understand from a user perspective. Could the authors elaborate on what means to have a limit of 5, 10, or 25 errors for example?

The error tolerance is not a limit on the number of pixels that have errors after decoding. For each pixel, the quantization used allows us to ensure that the absolute difference between the original value of the pixel and the decoded one is less or equal to NEAR. That is, abs( original_image(x,y) - decoded_image(x,y) ) ≤ NEAR, for all x and y, where x and y denote the pixel coordinates.

Taking your comment into account, the “LOCO-ANS Algorithm” section was updated to provide a more clear explanation of this error limit. 

Lastly, we want to thank you very much for your review. Your comments have been very helpful to improve the quality of the paper.

 

References

[1] T. Alonso, G. Sutter, and J. E. Lopez De Vergara, "LOCO-ANS: An Optimization of JPEG-LS Using an Efficient and Low-Complexity Coder Based on ANS," in IEEE Access, vol. 9, pp. 106606-106626, 2021, doi: 10.1109/ACCESS.2021.3100747.

 

Reviewer 4 Report

In this work an evaluation of a hardware architecture for the recently developed 2 LOCO-ANS lossless and near-lossless image compressor, which is based on JPEG-LS standard, has been presented.

The paper is very well described. 

I suggest to move the "related works" section to begin of paper.

The results and methods have good described. 

Table 5, you must fix the terms on column (first column is empty).

row 543 Introduce a simple description of 5.3 section.

Conclusion must be reduced and summarised.

 

Check Grammar and typos. 

Moreover, I suggest the following references, in order to improve the quality of bibliography:

• Chen, S. L., & Wu, G. S. (2017). A cost and power efficient image compressor VLSI design with fuzzy decision and block partition for wireless sensor networks. IEEE Sensors Journal, 17(15), 4999-5007.
• De Luca, P., Galletti, A., & Marcellino, L. (2022). A Novel GPU Implementation for Image Stripe Noise Removal. In Intelligent Computing (pp. 232-243). Springer, Cham.
• Zhaoning, Y., Yan, L., & Tiegang, G. (2021). A lossless self-recovery watermarking scheme with JPEG-LS compression. Journal of Information Security and Applications, 58, 102733.

 

Author Response

Dear Editors and Reviewers,

We would like to thank the reviewers for their feedback. We have addressed all comments, modifying the article when necessary, and believe that as a result of this, the article has become much stronger and clearer. Additionally, we discuss below all criticism, suggestions, and responses, including how we have improved the paper. Reviewers' comments are in bold, and our responses are in plain text.

As a summary, the most significant changes are the following:

• We have restructured sections 4 and 5 to improve the presentation of the results and the evaluation of the results.
• We have included additional details of how the presented system performance was accomplished.
• We have improved the compression comparison by including other encoder configurations.
• We have improved the description of the error metric and included examples of compressed images.

We are uploading (a) our point-by-point response to the comments (below), (b)  a document showing the differences with the previous version of our manuscript, with insertions in blue and curly underlined, and deletions in red and struck through and (c) a clean updated manuscript (PDF main document).

 

With kind regards,

Tobías, Gustavo and Jorge

 

Response to reviewers comments

I suggest to move the "related works" section to begin of paper.

Thank you for the suggestion. We considered this alternative, but we think that, given the length of the article, this information is correctly placed in the discussion section, so the reader can better understand the comparison with previous works.

However, also taking into account your comment, we have restructured sections 4 and 5 to provide a clearer evaluation of the presented system.

 

Table 5, you must fix the terms on column (first column is empty).

The first header row was originally added to group time specifications into propagation times and set up ones. However, considering your comment, we added the missing group headers.

 

row 543 Introduce a simple description of 5.3 section.

Thank you for the comment. However, this section had been restructured, making this comment not applicable anymore.

 

Conclusion must be reduced and summarised.

Thank you for the suggestion. Taking it into account, we revised the conclusion and reduced it a bit, making it more concise. However, considering the extension of the article and, in particular, of the discussion section, we think that the conclusion section has an appropriate length, stating only the most important takeaways. Also, this section follows MDPI directives.

 

Check Grammar and typos. 

We have proofread the text looking for these and corrected them.

 

Moreover, I suggest the following references, in order to improve the quality of bibliography:

• Chen, S. L., & Wu, G. S. (2017). A cost and power efficient image compressor VLSI design with fuzzy decision and block partition for wireless sensor networks. IEEE Sensors Journal, 17(15), 4999-5007.

• De Luca, P., Galletti, A., & Marcellino, L. (2022). A Novel GPU Implementation for Image Stripe Noise Removal. In Intelligent Computing (pp. 232-243). Springer, Cham.
• Zhaoning, Y., Yan, L., & Tiegang, G. (2021). A lossless self-recovery watermarking scheme with JPEG-LS compression. Journal of Information Security and Applications, 58, 102733.

Regarding the first paper, it is true that its general idea might be interesting and somewhat related to this paper. However, it presents a BTC-based codec, which is inherently a lossy process with no bounds on errors and no simple means to choose the distortion level. Therefore, we consider it doesn’t fit in the comparison section. Additionally, there are several issues and many inaccuracies in that paper. For example:

• Table X states that ref [28] requires a memory to store a whole frame. And in fact, says: “In addition, the memory requirement in this work is only a one-line-buffer memory which is much less than a frame memory requirement of JPEG [26], [27] and JPEG-LS [28], [29].”  This is not true nor for reference [28] and neither for most hardware implementations of JPEG-LS, which require only a 1 or 2 rows memory. In the case of [29], we think that it used an external memory to store the image, not because of JPEG-LS but for other reasons.
• It also gives PSNR and compression ratio values for JPEG-LS without indicating the NEAR parameter. The paper they reference is about a JPEG-LS adapted to code Bayer patterns. It also states that [28] achieves that particular PSNR, when [28] only supports lossless compression. The stated compression ratio does not correspond to JPEG-LS. 
• That work aims to provide a power-efficient compressor for wireless sensor networks, but they seem to focus too much on gate counts, not taking into account that a lot of power is needed for the transmission of the data. Therefore, trading gates for compression ratio can imply that the system as a whole has higher power requirements.

In general, the evaluation is imprecise, based on 3 images of an old dataset, and provides only arbitrary points of the distortion-compression curves.  

Regarding the second suggested reference,  we currently have access to the abstract of this chapter only. It is true that image denoising modules might be inserted in the image processing, which would result in an improved compression ratio if done before the encoder (as opposed to inserting it after the decoder and being able to keep the original image, while also providing the denoised version). However, we think that discussing other preprocessing steps, and in particular of a parallel implementation on GPUs of a denoising algorithm will not contribute to the clarity of our paper, which is already a bit long.

Finally, about the third one, although this paper is related to JPEG-LS, it is not related to real-time or highly constrained applications, but about secure storage of medical images, so we don’t see how it can contribute to the presented paper.

 

We want to thank you very much for your review. Your comments have been very helpful to improve the quality of the paper.

Round 2

Reviewer 1 Report

The manuscript is now ready for publication.

Author Response

Dear Reviewer,

We thank you again for the comments that allowed us to improve our paper.

 

With kind regards,

Tobías, Gustavo and Jorge

Reviewer 4 Report

Row 343 the set of z must be declared in math format.

row 371 the sentence "Ans coder" has to be deleted.

subsec 5.2 should involve the next subsection.

 

I suggest to expand the bibliography with previous suggested comments. Additional references must be added in order to give strong presentation of the study.

 

Author Response

Dear Editors and Reviewers,

We would like to thank again the reviewers for their feedback. We address below the reviewer’s suggestions and concerns, including how we have improved the paper. Reviewers' comments are in bold, and our responses are in plain text. 

As the most important request in this review round was the addition of references, the most significant change is the inclusion of 8 new references to reinforce some of the arguments on which we based our research Also, we have included the results of section 5.2.1 in the discussion of section 5.3. 

We are uploading (a) our point-by-point response to the comments (below), (b)  a document showing the differences with the previous version of our manuscript, with insertions in blue and curly underlined, and deletions in red and struck through (uploaded as a Supplementary file) and (c) a clean updated manuscript (PDF main document).

 

With kind regards,

Tobías, Gustavo and Jorge

 

Response to reviewer

Row 343 the set of z must be declared in math format.

In the latex code, we confirm that all references to the “z” variable observed in row 343 (of the revised document with highlighted changes) are in math mode.

row 371 the sentence "Ans coder" has to be deleted.

This is the paragraph heading. The problem is that the MDPI format uses the normal text font for these headings (without bold or italics), so it could be confused with a normal sentence. Taking this comment into account, these headings are now in italics throughout the manuscript.

subsec 5.2 should involve the next subsection.

 We thank the reviewer for the suggestion. Taking this into consideration, in addition to the previous comments of other reviewers, we have kept the preliminary considerations (section 5.2) separated from the comparison of lossless-only codecs (section 5.3), but we have included the results of section 5.2.1 in the discussion of section 5.3.

I suggest to expand the bibliography with previous suggested comments. Additional references must be added in order to give strong presentation of the study.

Taking your suggestion into consideration, we have updated the bibliography, adding the following references to reinforce some of the arguments on which we based our research:

• Sushma B. (2021) Endoscopic Wireless Capsule Compressor: A Review of the Existing Image and Video Compression Algorithms. In: Karuppusamy P., Perikos I., Shi F., Nguyen T.N. (eds) Sustainable Communication Networks and Application. Lecture Notes on Data Engineering and Communications Technologies, vol 55. Springer, Singapore. https://doi.org/10.1007/978-981-15-8677-4_23
• Zhang, Xiaoli, Xin Wei, Qianbo Sang, He Chen, and Yizhuang Xie. 2020. "An Efficient FPGA-Based Implementation for Quantized Remote Sensing Image Scene Classification Network" Electronics 9, no. 9: 1344. https://doi.org/10.3390/electronics9091344
• H. Saidi, M. Turki, Z. Marrakchi, A. Obeid and M. Abid, "Implementation of Reed Solomon Encoder on Low-Latency Embedded FPGA in Flexible SoC based on ARM Processor," 2020 International Wireless Communications and Mobile Computing (IWCMC), 2020, pp. 1347-1352, doi: 10.1109/IWCMC48107.2020.9148349.
• Y. Nagamatsu, F. Sugai, K. Okada and M. Inaba, "Basic Implementation of FPGA-GPU Dual SoC Hybrid Architecture for Low-Latency Multi-DOF Robot Motion Control," 2020 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2020, pp. 7255-7260, doi: 10.1109/IROS45743.2020.9341602.
• Li, Lin, Shengbing Zhang, and Juan Wu. 2019. "Efficient Object Detection Framework and Hardware Architecture for Remote Sensing Images," Remote Sensing 11, no. 20: 2376. https://doi.org/10.3390/rs11202376
• T. Richter, J. Keinert, S. Foessel, A. Descampe, G. Rouvroy and J.-B. Lorent, "JPEG-XS—A High-Quality Mezzanine Image Codec for Video Over IP," SMPTE Motion Imaging Journal, vol. 127, no. 9, pp. 39-49, Oct. 2018, doi: 10.5594/JMI.2018.2862098
• C. A. Lee, S. D. Gasster, A. Plaza, C. -I. Chang and B. Huang, "Recent Developments in High Performance Computing for Remote Sensing: A Review," IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing, vol. 4, no. 3, pp. 508-527, Sept. 2011, doi: 10.1109/JSTARS.2011.2162643.
• N. Merhav, G. Seroussi, and M. J. Weinberger, “Coding of sources with two-sided geometric distributions and unknown parameters,” IEEE Transactions on Information Theory, vol. 46, no. 1, pp. 229–236, 2000

 

Finally, we thank the reviewer for taking the time to analyze our paper, helping to make our article stronger.

Round 3

Reviewer 4 Report

All review comments have been addressed.