1 \documentclass{article}
3 \title{Answers to the questions asked by reviewers.}
6 We would first like to thank reviewers for analyzing our article and making suggestions to improve it.
7 We did our best to comply with their requirements. We hope it will now meet the required standard.
8 We detail the changes made below.
11 First, please define all your acronyms before using them.
13 Unforgivable and fixed.
16 Second Figure 8 was referred to in page 4 and displyed in page 8.
17 Please display at least the upper part of this figure in page 4
18 even though it is slightly redundant.
20 We managed to display this figure early in the paper, on page 3, shortly after we first referred to it on page 2.
23 Also, I had to wait till section 6.2 and 6.3 until I understood
24 the main contribution of the paper. If you refer to this earlier
25 (maybe at the end of the introduction) you will be able to hock
26 your reader in a better way.
28 Abstract and introduction have been re-written accordingly.
33 1. There are a few English errors and typos sprinkled throughout
34 the paper. These need to be corrected.
35 Most of them are spelling errors.
37 We carefully parsed the whole article and hope there are no errors left.
40 2. The term "Lengthenable" is not a word.
42 The same remark was made by reviewer 3. We replaced it, as suggested, by the word extendable.
43 Please note that the term \textit{lengthenable} is used, for example, in the text of some US Patents: \textit{Balance type minute lengthenable adjuster} (US patent 4995847 A) or \textit{lengthenable garment} (US patent 2602163).
46 3. In formulae, the use of a dot to represent multiplication is
47 distracting. It can be interpreted as a dot product or a period.
48 I would suggest these be removed.
52 4. The second paragraph in the introduction (p. 1) starts with a
53 reference to human vision, but the paragraph describes various
54 noise filters that have been accelerated.
55 The sentence is irrelevant.
57 The introduction has been re-written. The reference to human vision is now part of the paragraph saying why no universal filter exists.
60 5. Sections 2 and 3 should be collapsed into the introduction.
64 6. The second paragraph on p. 5 is unclear. Where does the
65 formula and numbers given for the number of segments come from?
67 Formulas have been detailed and the first sentences of the paragraph have been made more concise.
72 It is also difficult to follow because the introduction doesn't
73 clearly explain how the isolines and de-noising are connected.
74 This leads to the confusion that will be evident from my comments
75 below. An *iso*line would normally be expected to delineate areas
76 of the *same* intensity, so it's not obvious why a std devn should
77 be associated with one. This doesn't become clear until well into
78 section 6!! The authors need to explain (even if only briefly) how
79 associating a pixel with an isoline removes noise *early* in their
80 paper. I would suggest moving figure 4(a,b,c) to the introduction
81 and adding the set of isolines that their process adds to the that
82 noisy window. Since it's only an 11x11 window, there should be only
83 a small number of them.
84 If the diagram becomes too cluttered with neighbouring lines in
85 the edge region, then something like the isoline through every 2nd
86 pixel in the centre column should enable someone to discover
87 immediately why *iso*lines have different intensities in them!
90 As a preliminary remark, we would like to stress the fact, that what we call isolines is not exactly what Matheron calls level lines.
91 We tried to explain the principle of this filter more clearly and earlier (beginning of section 3).
92 We do not ``add'' any isoline, we only make a local search, around each pixel, of the pattern that would best match the shape of the level line in the noiseless image.
93 Isolines are built by combining those patterns and once one isoline is terminated, the output gray level value is the average value of all gray level values along that isoline.\\
94 The level lines exist in the noiseless image model but we only have access to the noisy images that have been corrupted by Gaussian noise,
95 so a probability density function (pdf) has been 'applied' to all pixels, including those belonging to the level line we are trying to estimate.
99 There is a key inconsistency in presentation .. there is a statement
100 that 'most common' images are continuous and continuous few edges.
101 Such images would contain little information and be of little interest.
102 However, tests have been conducted on 'real' images with no shortage
103 of edges - see figure 7b. If the continuity and few edges condition
104 is important, then the effect of deviations (textured images with
105 large edge counts) should be discussed. If the condition is not
106 actually important (as results suggest), then these references need
109 We removed the expression 'few edges'. It was actually an ill-advised attempt to speak about the limitations of the method.
110 Instead, we now refer to the definition given by Caselles of a 'natural image'.
113 Circular poly-isolines are apparently excluded which would seem to be
114 a key limitation and needs discussion.
116 We did not mean ``circular'' but ``that could roll onto themselves''.
117 Once again, our language was not precise enough.
120 In general, the paper could be a lot better written. The authors might
121 remove the 'noise' (in the sense of unnecessary words and phrases)
122 from the text also and make it more precise and concise!
123 Some examples of this verbal noise are given below.
124 The whole paper should be checked for similar excesses.
126 We hope that the modifications we made are satisfactory.
129 Similarly, figure 9 contains excess noise in the form of meaningless
130 digits in numbers presented. By convention, if you write 19.49,
131 you imply 19.49 ± 0.005 (half the least significant digit).
132 It's certain that the last 9 means nothing here and you should
133 therefore write 19.5.
136 Let us consider a noisy $512\times 512$ pixel image of PSNR=19.50~dB.
137 The corresponding Sum of Square Errors is then $SE_{19.5}=750032$.
138 If the PSNR value is PSNR=19,49~dB, then $SE_{19.49}=751761$.
140 The difference is $1729$ which could be the consequence of 1729 pixels each having its own error increased by one.
141 It is absolutely measurable and has a meaning even if it is not visible by a human eye.
144 This table would be further improved by reporting the *improvement*
145 in SNR (ie the difference between noisy and improved images).
146 This would result in smaller (easier and faster to read) numbers
147 and highlight differences. It's not clear to me why, if noise of
148 the same sigma was added to each image,
149 how the SNR's for the noisy images are not the same too.
152 As for the PSNR, it depends on the content of each image: especially the average gray level value and the drawing of noise.
153 For example, if one tries to add a noise value of 25 to a reference gray level value of 240, the resulting corrupted value will be truncated to 255, it but won't be the case if the reference value is under 230.
157 It starts off badly in the abstract, where the authors state that
158 they 'propose to address the issue ..'.
159 If they just 'propose to address' something, then this paper should
160 be in a work-in-progess workshop.
161 I presume what they really mean to say is:
162 'We describe a GPU-based filter for image denoising.'
163 Abstracts are supposed to be concise, so the rest of the sentence
165 It is reasonable to assume that readers understand that modern
166 GPUs are parallel processing devices!
167 The next sentence could similarly be shortened and made more
168 appropriate for an abstract to ..
169 We use Matherton's level set theory which has rarely been
170 implemented because of high computation cost.
171 Reference numbers should *not* appear in the abstract, because it
172 will often be read by itself without the accompanying text and
173 reference list - just use the author(s)' names as in the suggested
175 I'm not sure of the significance of 'try to guess' .. but again
176 more precise wording is needed: I don't think anyone is interested
177 in a guess .. except as a first step in a refinement.
178 'What we actually do' should be deleted altogether
179 as colloquial and excess verbiage. Try 'We initially guess ...'
180 (or something similarly concise).
181 Next sentence contains some historical notes which are probably
182 best in the text alone: the abstract would normally concentrate
183 on results, but it should not be vague -
184 'the optimization heuristics' tells me nothing. This is where a
185 *concise* description of the heuristics should be included.
186 The final sentence is almost inviting a reader to skip reading the
187 paper altogether (and your reviewer to reject it!). It would
188 be better if it gave some actual results achieved by the authors
189 (both for denoising level *and* time) and compared
190 with state-of-the-art denoising levels and time from other work.
192 The abstract should also give an example of denoising performance
193 - perhaps some numbers from Fig 9
194 (but SNR improvements, not actual SNRs!). An average from
195 fig 9 would also be reasonable.
197 Some more examples of writing style unacceptable in a journal ..
200 Denoising has been a much studied research issue since
201 electronic transmission was rst used. The wide range of
202 applications that involve denoising makes it uneasy to
203 propose a universal ltering method. Among them, dig-
204 ital image processing is a major eld of interest as the
205 number of digital devices able to take pictures or make
206 movies is growing fast and shooting is rarely done in
211 Denoising has been extensively studied since images have
212 been transmitted electronically. The wide range of applications
213 requiring noise removal makes it difficult to find a universal
214 filter. The fast growth in digital devices
215 has made digital processing become more important.
217 We modified our text accordingly and hope it will be more understandable.
218 As for the optimization heuristics, the most interesting ones are described
219 in the sections isoline-segments, PI-LD, PI-PD.
222 What's the significance of 'shooting is rarely done in
223 optimal conditions'? It's certainly not linked to digital images
224 alone as it affects images however they are acquired and stored.
226 Pictures made with mobile phones or digital cameras are most often taken in poor light conditions and without stabilizing stand.
227 Those pictures are quite noisy and need noise removal.
230 higher noise effects -> higher noise levels
232 imposes high output flow rates .. -> requires high data rates
233 in the processing algorithms
235 is subject to high variation ... -> varies significantly from
238 Done with a minor revision: \textit{data transfer rates}.
241 Many researchers have successfully speeded up image processing
242 algorithms with GPUs.
244 Our spell checker (aspell / Texlive / American dict.) says: sped up.
245 We tried to re-phrase our sentence.
248 Don't use reference numbers as substitutes for author's names ..
249 For example in [11],[7]
250 and [15], authors managed to design quite fast median
251 lters. Bilateral ltering has also been successfully pro-
256 Fast median filters have been reported[11],[7];
257 bilateral filtering was also speeded up[17].
260 McGuire[11] and Chen et al[7] reported ... ;
261 Yang et al sped up a bilateral filter[17].
263 Giving the actual rates (in terms, say, of frames per second) would
264 be even better in putting the author's current work into context!
270 'even apparently sub-optimal solutions'?
271 'apparently sub-optimal' implies that they might really be optimal ..
272 However, from the rest of the sentence,
273 it would seem that you're referring to the usual trade-off between
274 performance and speed -
275 lower quality algortithms that run faster .. so say that .. in 5 words
276 instead of 5 lines ..
282 I cannot find the 'conditions mentioned in section 5' clearly set
284 So I find the claim that 'real life images fulfill the above
285 conditions' untenable.
286 List the conditions (or assumptions that your method relies upon)
290 such level lines based algorithms as in [6] and [12]
291 -> level lines algorithms[6,12].
293 A few years ago, in [3], authors proposed an original method ->
294 Bertaux et al described a method which ... [3].
296 Don't put in vague things like 'a few'!! It doesn't really matter
297 how long ago anyway ..
298 if someone is curious, they can look up the reference date!!
300 preserve -> preserving
305 reference images taken from [1] .. but [1] is hardly a complete
307 Are you referring to the Matlab package or Stanford's Lab?
308 In which case, say .. images from <source> Denoise Lab[1]
309 and give a complete reference ..
311 .. have been published. Where?? At least some sample references required.
313 The page of Steven Lansel at Stanford Lab where the benchmark set of images could be downloaded is no more available. We withdrew the reference and added
314 a footnote in the text.
319 This section would seem to be partly propaganda for Nvidia.
320 They are not the only
321 manufacturers of GPUs and this section should at least recognize
324 The important distinction between what's on a 'card' and on the
325 silicon die on the card is lost ..
326 even though the chip is probably the only major component of the
328 there will be a large difference between memory access times for
329 on-chip and off-chip memory.
330 Nvidia themselves are rather vague about this, but that's no excuse
332 vagueness into (hopefully) carefully written and objective papers.
334 At least the clock rate of the card should be noted here.
335 Some other parameters like
336 memory bandwidth are important too, but I can at least place the
337 device used in historical
338 perspective with the clock rate. I shouldn't have to look this up
339 from Nvidia literature.
341 It is not propaganda: we don't actually have any GPU from other manufacturer at our disposal.
342 We added clock rate values and precisions about different type of memory as requested.
345 What does 're-serialization' mean?
346 If you mean the inclusion of necessary barriers, then say so,
348 a new term (or follow someone else's unnecessary invention!)
349 for a really simple concept.
351 (or follow someone else's unnecessary invention!) ???
353 Please note that we are not talking about synchronization barriers.
354 When parallelizing an existing sequential process (on GPU), if the parallel code causes divergent branches or shared memory bank conflicts, some thread instructions just cannot be executed in parallel. Instead, the warps will run branches sequentially or replay the instructions.
355 That has made us think of a backward move and chose to speak about \textit{re-serialization}.
356 Anyway, we changed for the single word \textit{serialization}.
359 requires -> requires that ..
361 The 'A' of CUDA is 'architecture' .. adding 'model' is not necessary ..
362 it's already a virtual architecture.
364 There is no way to know how .. -> The order in which threads are
365 scheduled is not defined.
366 ('how' is wrong .. threads will certainly be scheduled ..
367 the key point is you don't know the order!)
369 The point about coalesced memory accesses is badly phrased and
370 probably not correct.
371 Again Nvidia is not very explicit, but almost certainly coalesced
373 lie in the same n mod 2^7 address block .. not an arbitrary 2^7 byte
379 The point about shared memory is just wrong.
380 Threads within a 'warp' must access the
381 same shared memory block. The use of the term 'parallel thread'
382 here is confusing and
383 probably should be replaced by something more explicit.
384 Of course, data must be distributed
385 carefully among shared memory blocks -
386 probably this is what you are trying to say.
388 Our first statement was actually incomplete.
389 We reproduced the sentence from the CUDA programmer's guide instead.
392 Last para is a general statement that applies to *any* parallel
393 processing architecture: the authors seem to imply that they
394 discovered this for GPUs!
399 constraining -> difficult
400 non-suited -> badly designed
408 IID .. Each image is corrupted by ONE noise distribution ..
409 so Identically distributed is meaningless, there's only one.
410 However, if you meant *images* corrupted by noise .. then IID
412 Small point, but this is a journal paper .. so you should get it right!
414 $I$/$\widehat{I}$ represent the family of reference/corrupted images.\\
419 'As introduced above' .. where ?? In the previous para, you've just
420 set down some notation.
422 'most common images are continuous and contain few edges' ??
423 This is an extremely contentious claim!!
424 If you want to persist with this, then you should give some examples
425 of images which satisfy this criterion!
426 There are many images used for testing image processing algorithms
427 which (deliberately) would fail this criterion.
429 As said before, we focus on 'natural images' as defined by Caselles.\\
434 Here you introduce 'fixed length' isolines. You don't justify
435 this or explain its significance - except the fixed length
436 obviously helps comparisons (as in previous para) ..
437 Does an image with large bands of the same colour still have
438 fixed length (ie short!) isolines?
439 Note that a 'continous' image with few edges actually contains
440 little information so it's hard to see how interesting images
441 satisfy this criterion.
443 The length of the isolines depends on the power of noise.
444 Lower power of noise leads to shorter isolines.
447 You use the term 'isoline part' without definition ..
448 is this a fixed length segment of a longer isoline?
450 An isoline part was meant to be a non terminated isoline.\\
454 Z is a *set* of grey levels.
455 P is the likelihood of what ?
457 First point: modified.
458 As for likelihood, it is the one defined by the expression that follows.\\
462 developped as -> re-written
465 The best isoline is the one which maximizes (5).
468 Lengthenable is not an English word .. use 'extendable'
470 lengthening -> extension
471 512x512 -> $512 \times 512$
475 You're defining a notation here .. don't use words implying vagueness!
476 'candidate' is a good word if you're going to make a choice among
477 possibilities at some stage.
478 hypothesis -> hypotheses
479 'share the same mean value'?
480 You mean that the two segments S^n and S^p must have the same mean?
481 In place of 'First' 'Second' write
482 If S^n+p is an isoline then ...
483 Alternatively, if S^n and S^p are ...
484 There is no 'third', so this is clearer ..
486 to validate lengthening -> to extend ...
487 depends -> depends on
489 We agree and have adjusted our text.
490 As for \textit{lengthenable}, as said before, we found this word in some US Patent titles.\\
491 Anyway, we followed the suggestion.
493 When one segment A is supposed to extend another segment B, if we consider both of them as one single isoline part, they ``share'' the same mean value inside the (A+B) polyline, by hypothesis.
496 You should define what you mean by an isoline carefully.
497 'iso' implies same, yet you describe the grey levels along S^n
498 (an isoline part) as having a distribution.
500 This whole section needs careful re-write.
501 A diagram explaining how a pixel and an isoline are related
503 Figure 1 does not seem to help much .. it just shows an isoline
504 which appears to have the *same* intensity along its whole length.
506 Inside a noisy image, the level lines of the reference scene are corrupted by the noise.
507 Modifications have been made. We hope to be more clear.
512 combinating -> combining
514 Figures should appear (roughly) in the order to which they are
515 referred! You refer to fig 8 *before* fig 2 has appeared!
520 To fit the GPU-specific ...
522 Did you mean to say that you chose the number of directions, D,
524 This is hardly GPU-specific, it would be done for *any* hardware
527 What is actually GPU specific is 32.\\
532 because of the necessary reduction stage for which GPU efficiency
534 because reduction is not efficient in a GPU
536 Reduction can actually be efficient on GPU. For example summing the 10 million values of one single vector is efficient on GPU.
537 But here, we talk about thousands of small and irregular sums. That is not efficient on GPU.
538 That led us to use the above expression.
539 We have tried to improve it.
542 If you were inspired by Bertaux et al's work, it would be nice
543 to use their name(s) in the text, instead of reducing them
544 to a number! This also saves someone who is familiar with their
545 work having to go to the reference list to confirm
546 whose work you're talking about!
548 Bertaux is actually mentionned as one of the authors.
549 The remark is justified but we intimately never tried to reduce him.\\
554 When considering S^n *under construction*,
555 how do you have C_x(Z(S^n)) .. having been obtained in the *previous*
558 Because those sums are computed and accumulated at each stage.
563 Please use a spelling checker!
565 deviation -> orientation change
566 (deviation can imply many things .. orientation change is more
567 specific and appropriate here)
572 It's not at all clear why circular lines are not allowed?
573 Surely this is a common situation?
575 Our bad English. As said before, we meant to say 'lines rolling onto themselves'.
576 It does not concern isolines that would have a circular shape with large radius.
579 You *use* a test (GLRT) not perform it.
581 For each allowed pattern, GLRT is performed in order to decide if
582 the corresponding segment could likely be added to the end of the
583 poly-isoline Sn. If none is validated by GLRT, the poly-isoline
588 For each pattern, we use the GLRT to decide if the segment could
589 extend the poly-isoline Sn. If none satisfies the test, Sn is
592 From our point of view, a test is rather performed than used.
593 We modified the other point.
596 In order to avoid critical situations where the first selected
597 segment would not share the primary
600 Presumably you are trying to say that for the first segment of
601 a line, you have to consider
602 all directions so you have D lines which could be extended?
604 To ensure isotropy .... 'isotropy' is not the right word here ..
605 nor is 'shares' .. I suspect you mean to say that each of the
606 D lines has the direction of the pattern p_{l,d} ??
608 Done with adjustments.
613 It implies -> This implies
615 Our spell checker says: indexes.
618 standard deviation -> standard deviation of grey levels for
619 (you use deviation in another sense also .. so you need to be specific here)
621 Changed to avoid any ambiguity.
626 'a bit weak' is colloquial .. use 'inferior to'
628 Remove 'In order to be performed'
630 Branches stall parts of the pipeline or leave GPU ALUs idle ..
631 be specific instead of the vague 'do not fit'.
633 candidate -> candidates
634 The notation [0;D] for the set [0..D] is also unusual and probably
635 better changed (everywhere) to a more common one.
641 Discussion associated with edge detection and fig 5 is confusing
642 and needs to be re-written. Fig 5 does not seem to help at all.
644 Sorry, but we do not see were the confusion can come from.
649 There is little mention of the use of shared memory -
650 only for P_l, not for the images themselves, which are much larger.
651 This is usually a critical
652 factor in achieving good speed-up with a GPU, so one assumes that
654 than reported here are achievable with a little work to allocate
656 a way as to allow efficient use of shared memory.
657 The thread / pixel model used
658 here is easy to program but probably less than optimal.
659 Blocking images to use
660 the shared memory effectively is relatively easy but needs a
661 little more programming
662 effort. In this case, it would appear that there are a sufficient
664 accessses to each pixel to make this worthwhile.
666 As we have shown in our previous work, shared memory is not \textit{the} solution to obtain speed on GPU.
667 An optimized sequence of texture fetches is most often faster, as soon as the halos of neighbor pixels overlap.
668 We applied this technique to design for example the fastest median filter known to date (accepted paper to be available soon) able to output more than 1.85 billion pixel per second \textit{without} using shared memory, unlike most of the other existing implementations.
669 In the process of designing this filter, we tested the shared memory solution but gave it up.
672 Results should ideally separate out time to transfer images between
674 and GPU computation times, since for applications (most presumably)
676 the de-noised image in the GPU, only the GPU time is of interest.
681 There is a disappointing lack of data for values of l other than 5.
682 For real-time applications,
683 the performance-time trade-off is always important.
684 Choice of l affects both time and performance so some data would
687 All images of the set have the same size ($512\times 512$)
688 and have the same level of relevant details.
689 These conditions lead to an optimal value of $l=5$.
690 Moreover, the power of noise $\sigma^2$ lead to a maximum length of $n=25$.
691 It is one interesting point, because that way, $l$ and $n$ are no more parameters to be adjusted.
692 It is the same for both GLRT threshold values.
695 'around' 3.5ms is vague and unacceptable in a scientific paper.
696 Either specify the error explicitly or simply use the half
697 least significant digit
698 convention (assumed by default). Adding 'around' suggests
699 vagueness or unexplained error!
701 As runtime varies with the content of the image, we used the word ``around''.
702 We agree that it can be confusing.
703 We just cleared the occurrences of the word 'around'.
707 It's generally understood now that, to obtain speed-up, you need
708 to consider the architecture. The disparaging comment in the
709 first sentence and the implication that the authors discovered
710 the need to link solution and architecture is unrealistic
711 and should be removed.