Reconfigurable Morphological Processor for Grayscale Image Processing

Round 1

Reviewer 1 Report

Please see attached document for comments.

Comments for author File: Comments.pdf

Author Response

I am grateful to you and the four reviewers for the constructive comments and suggestions on the revision of my manuscript. I have made all the necessary changes as suggested by the reviewers. All the revisions in the manuscript have been highlighted in red color. A detailed list of our responses to the reviewers’ reports is also given in the following.

1) In figure 1, the authors present two algorithms one for the maximum and one for the minimum. My understanding is that the authors are using the duality principle in mathematical morphology, which has not been described or discussed in the text. According to duality principle in order to obtain the minimum function we use again the max function over the complement of 1s. That is the max of all potential candidates which are defined as those objects that are in the race to become maximums. The authors should discuss this point.

A: The minimum circuit is implemented in my previous work[21]. See LOA3 and 6.

2) The authors benchmark using current technology as underlined in table 5. His processor is based on the systolic array and is closer to the precessor described in the reference 19. They hence provide a very relevant comparison. The authors add a hardware for GrayScale image unit thus increasing the number of hardwares compared to the reference 19 better to use author name than a number). The authors should further explain the relevance of this exercise. They should also explain the extent to which modify the algorithms for máximum and mínimum of the reference 19. If we use the algorithms iunderlined in 19, do we get worse results?

A: The improvement of the computing circuits is added in lines 120-122, and in Fig. 2. See LOA3.

3) If the supposed desired result is to get low Area/pixels ratio, then the authors have to explain how is it possible a more flexible system like yours gets higher ratio, meaning “worse” than the technology presented in reference 7, and reported in table 5? The authors are encouraged to discuss this point.

A: The  [7] can only conduct dilation with a 5 ˟ 5 disk SE. The chip is designed specially. The discuss is in lines 342-344, and Table 6.

4) The second paragraph of page 2 that starts “In this study, we present….” And ends “….extensive application range” should be rephrased. Other parts of the text have minor grammatical mistakes, please correct them.

A: The mistake has been corrected in lines 49 and 59.

Reviewer 2 Report

This paper presents a processor for Grayscale Image Processing.

The paper is good structured, has pratictal experiments as well as a comparison between the presented solution and solutions from other papers.

Overall, this can be a good paper but it needs to improve some major things beforehand:

First, it is not clear what the primarly novelty of this paper is. Currently, it reads like this is just an implementation of a Grayscale Image Processing Unit, which is a good engineering work but not a scientific novelty. So the paper must be improved in a way to clarify what the exact scientific novelty of this realization is, compared to the already existing solutions from the literature. This impression is further amplified due to the comparison (table 5): there some key features of all solutions are compared and it reads like some kind of general purpose CPU datasheed: "the new generation has now more throughput and needs less power due to change in Semiconductor constrctuion size, but is otherwise basically the same as before". The author miss the opportunity to clarify what key differences are that make this approach unique and novel, other than e.g. the fact that the image size is bigger.

Additionally, it is not very clear how this processor ist realized. Is this an ASIC realization, or e.g. an FPGA realization ? If this is not an e.g. FPGA realization, then how is it possible to change image sizes ? Line 229ff: "For example, if the maximum horizontal image size is 1,920, then the line memory can be 8 ˟ 1,920 ˟ 8 bits. For larger SE, the number of the line memories can be increased." how is this practically realized ? Some more details are needed in order to clarify. (Line 218: "That means the processor can transform the structure by different configurations as they are needed.") The fact that it is done with the Synopsys Design Compiler suggests that this is an ASIC realization, but this arises the question how the reconfiguration is realized.

Reconfiguration on a FPGA is done via a (partial) Bitstream, meaning a physical reconfiguration of the hardware resources of the FPGA as well as their connections.
It is not clear at the moment how the reconfiguration is done here. Or does reconfiguration "only" mean setting some other values in the configuration registers ? Either way: a clarification is needed.
If by reconfiguration the authors mean changing setting in the registers, then there is some kind of explanation needed how this changes the proposed processor, when it is possible (e.g. the processor needs to stop working, or is it only possible before first start-up etc?)
The authors claim that this processor is real-time capable, but there is no explanation what real-time means in this context.
(Line 292ff: "the frame rate of operations is more than 200 f/s, which significantly exceeds the real-time requirement") 
What is the real-time requirement, from what it is derived ? Here are no informations given. Can it be assured that under no circumstances this rate will drop even for just a moment (e.g. due to reconfiguration, it was said that most of the reconfiguration informations comming from extern, so it has to be assumed that they could be changed during runtime etc.?)

Example: just because someone claims "180 f/s is needed for real-time", and this processor can compute 200 f/s does not mean it is real-time capable. There are way more constraints in order to be able to compute things in real-time, like e.g. how interruptions are handled, reconfigurations etc. and is has to be proven that even in those situations, the real-time characteristic is always met and not violated. Just the sentence (L. 292ff) "The table shows that the frame rate of operations is more than 200 f/s, which significantly exceeds the real-time requirement." is way to less in order to claim/justify real-time capabilities.

Author Response

I am grateful to you and the four reviewers for the constructive comments and suggestions on the revision of my manuscript. I have made all the necessary changes as suggested by the reviewers. All the revisions in the manuscript have been highlighted in red color. A detailed list of our responses to the reviewers’ reports is also given in the following.

1) it is not clear what the primarly novelty of this paper is. Currently, it reads like this is just an implementation of a Grayscale Image Processing Unit, which is a good engineering work but not a scientific novelty. So the paper must be improved in a way to clarify what the exact scientific novelty of this realization is, compared to the already existing solutions from the literature. This impression is further amplified due to the comparison (table 5): there some key features of all solutions are compared and it reads like some kind of general purpose CPU datasheed: "the new generation has now more throughput and needs less power due to change in Semiconductor constrctuion size, but is otherwise basically the same as before". The author miss the opportunity to clarify what key differences are that make this approach unique and novel, other than e.g. the fact that the image size is bigger.

A: The novelty has been added. See LOA1.

2) Additionally, it is not very clear how this processor ist realized. Is this an ASIC realization, or e.g. an FPGA realization ? If this is not an e.g. FPGA realization, then how is it possible to change image sizes ? Line 229ff: "For example, if the maximum horizontal image size is 1,920, then the line memory can be 8 ˟ 1,920 ˟ 8 bits. For larger SE, the number of the line memories can be increased." how is this practically realized ? Some more details are needed in order to clarify. (Line 218: "That means the processor can transform the structure by different configurations as they are needed.") The fact that it is done with the Synopsys Design Compiler suggests that this is an ASIC realization, but this arises the question how the reconfiguration is realized.
Reconfiguration on a FPGA is done via a (partial) Bitstream, meaning a physical reconfiguration of the hardware resources of the FPGA as well as their connections.
It is not clear at the moment how the reconfiguration is done here. Or does reconfiguration "only" mean setting some other values in the configuration registers ? Either way: a clarification is needed.
If by reconfiguration the authors mean changing setting in the registers, then there is some kind of explanation needed how this changes the proposed processor, when it is possible (e.g. the processor needs to stop working, or is it only possible before first start-up etc?)

A: The reconfiguration manner has been added. See LOA 4.

3) The authors claim that this processor is real-time capable, but there is no explanation what real-time means in this context.
(Line 292ff: "the frame rate of operations is more than 200 f/s, which significantly exceeds the real-time requirement") 
What is the real-time requirement, from what it is derived ? Here are no informations given. Can it be assured that under no circumstances this rate will drop even for just a moment (e.g. due to reconfiguration, it was said that most of the reconfiguration informations comming from extern, so it has to be assumed that they could be changed during runtime etc.?)

Example: just because someone claims "180 f/s is needed for real-time", and this processor can compute 200 f/s does not mean it is real-time capable. There are way more constraints in order to be able to compute things in real-time, like e.g. how interruptions are handled, reconfigurations etc. and is has to be proven that even in those situations, the real-time characteristic is always met and not violated. Just the sentence (L. 292ff) "The table shows that the frame rate of operations is more than 200 f/s, which significantly exceeds the real-time requirement." is way to less in order to claim/justify real-time capabilities.

A: The  means of the real-time has been added. See LOA 5.

Reviewer 3 Report

The content of the paper is original and the content is clearly described.

Please correct the following items.

Point 1 : Please add a description of the recent research trend by             
               creating a new section “2. Literature Review”.

 Point 2 : Please add the simulation result waveform of synthesis for the
                frame rate in Table 4.

Author Response

I am grateful to you and the four reviewers for the constructive comments and suggestions on the revision of my manuscript. I have made all the necessary changes as suggested by the reviewers. All the revisions in the manuscript have been highlighted in red color. A detailed list of our responses to the reviewers’ reports is also given in the following.

1) Please add a description of the recent research trend by creating a new section “2. Literature Review”.
A: Section 2 Literature Review has been added in page 2. See LOA 2.

2) Please add the simulation result waveform of synthesis for the frame rate in Table 4.
A: The data in Table can been calculated by the design. So I think there is no need to add the waveform.

Reviewer 4 Report

In this study, a reconfigurable grayscale image processor was proposed to conduct real-time grayscale image morphological processing. The processor consists of an RGPM and peripheral circuits. The RGPM has a reconfigurable architecture with high performance and flexibility.

The authors demonstrated the good performance of the new approach by comparing the results with those of other methods. It might be interesting to examine other operations, such as morphological gradient, for future studies.

Author Response

I am grateful to you and the four reviewers for the constructive comments and suggestions on the revision of my manuscript. I have made all the necessary changes as suggested by the reviewers. All the revisions in the manuscript have been highlighted in red color. A detailed list of our responses to the reviewers’ reports is also given in the following.

Round 2

Reviewer 1 Report

Dear author,

thank you for your reply. 

Author Response

No comment.

Reviewer 2 Report

Dear Author,

you addressed some of the points that i mentioned, but for some i could not find the additional information/explanation.

Novelty is more clear now.

The reconfiguration could really need 2-3 more sentences, how exactly the reconfiguration is done, meaning: i think the hardware stays the same but reconfigurations means a change in dataflow ? Or does really something changes during reconfiguration on a hardware level ? The already added paragraph already helps the explanation, for the configuration and dataflow, but i would love to see maybe just 2 more sentences to clarify the manner.

The big part that is still missing from my point of view is the real-time capabilities. In the added/changes paragraphs, i could not find any information on this manner. As i already wrote in the first review: often something is declared "real-time capable", but what is really meant is just: really fast computing, which is way off. Real-time does not mean fast, it means that there is a set real-time constraint (which can be quite "slow" actually) and it is assured that (and this has to be proven, e.g. with the help of a theoretical proof like e.g. induction counting techniques or similar) under no circumstances this set constraint will be violated (hard real-time capabilities). Or at least that in 99% of the time this contraint will be met (soft real-time capabilities).  So what happens e.g. if during the computation, values of the parameters will be changed, due to some kind of error that happens outside ? Since most of the parameters will be set externally, this can very well happen. How does this system behave in such a case ? Will it still compute correct and faster than the constraint says ? Will it compute with the old set of parameters or with the new and why ? etc. etc.

To prove real-time capability, all those and similar questions has to be ansered.

If real-time means in this manner means real-fast, then the term real-time must not be used.

Additionally, i have some minor problems with the added section literature review. A section called e.g. state of the art, literature review or similar, i, as a reader, would expect the most source references, yet not a single in the whole section.

E.G. i would expect something to read like: "In recent years,the image and vision applications arewidely used in the advanced manufacturing [source] , medicine [source][source] [source]  , national defense [source] , public safety [source] , and space technology [source][source]."

Overall, the changes address most of the comments, expect real-time as mentioned, and literature review should be improved.

Author Response

LOA1: Section 2. Literature Review has been modified in page 2.

LOA2: The reconfiguration process has been added in page 10.

LOA3: The “real-time” has been deleted.

Round 3

Reviewer 2 Report

I have no further comments.