]> AND Private Git Repository - these_gilles.git/blob - paper_lniv_gpu/review.tex
Logo AND Algorithmique Numérique Distribuée

Private GIT Repository
relecture vlad de 0 a 70
[these_gilles.git] / paper_lniv_gpu / review.tex
1 \documentclass{article}
2
3 \title{Answers to the questions asked by reviewers.}
4 \begin{document}
5 \maketitle
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.
9 \section*{Reviewer 1}
10 \begin{verbatim}
11 First, please define all your acronyms before using them.
12 \end{verbatim}
13 Unforgivable and fixed.
14
15 \begin{verbatim}
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.
19 \end{verbatim}
20 We managed to display this figure early in the paper, on page 3, shortly after we first referred to it on page 2. 
21
22 \begin{verbatim}
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.
27 \end{verbatim}
28 Abstract and introduction have been re-written accordingly. 
29
30
31 \section*{Reviewer 2}
32 \begin{verbatim}
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.
36 \end{verbatim}
37 We carefully parsed the whole article and hope there are no errors left. 
38
39 \begin{verbatim}
40 2. The term "Lengthenable" is not a word.
41 \end{verbatim}
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).
44
45 \begin{verbatim}
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.
49 \end{verbatim}
50 Done.
51 \begin{verbatim}
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.
56 \end{verbatim}
57 The introduction has been re-written. The reference to human vision is now part of the paragraph saying that no universal filter exists.  
58
59 \begin{verbatim}
60 5. Sections 2 and  3 should be collapsed into the introduction.
61 \end{verbatim}
62 Done.
63 \begin{verbatim}
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?
66 \end{verbatim}
67 Formulas have been detailed and the first sentences of the paragraph have been made more concise. 
68
69 \section*{Reviewer 3} 
70
71 \begin{verbatim}
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!
88 \end{verbatim}
89
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 exists 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.
96
97
98 \begin{verbatim}
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 
107 to be adjusted.
108 \end{verbatim}
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'. 
111
112 \begin{verbatim}
113 Circular poly-isolines are apparently excluded which would seem to be
114  a key limitation and needs discussion.
115 \end{verbatim}
116 We did not mean ``circular'' but ``that could roll onto themselves''. 
117 Once again, our language was not precise enough. 
118
119 \begin{verbatim}
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.
125 \end{verbatim}
126 We hope that the modifications we made are satisfactory.
127
128 \begin{verbatim}
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.
134 \end{verbatim}
135 That is not exact: 
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$.
139
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.
142  
143 \begin{verbatim}
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.
150 \end{verbatim}
151 We did so.
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
154
155 \begin{verbatim}
156 It starts off badly in the abstract, where the authors state that 
157 they 'propose to address the issue ..'.
158 If they just 'propose to address' something, then this paper should 
159 be in a work-in-progess workshop.
160 I presume what they really mean to say is:
161 'We describe a GPU-based filter for image denoising.'
162 Abstracts are supposed to be concise, so the rest of the sentence 
163 is redundant.
164 It is reasonable to assume that readers understand that modern 
165 GPUs are parallel processing devices!
166 The next sentence could similarly be shortened and made more 
167 appropriate for an abstract to ..
168 We use Matherton's level set theory which has rarely been 
169 implemented because of high computation cost.
170 Reference numbers should *not* appear in the abstract, because it 
171 will often be read by itself without the accompanying text and 
172 reference list - just use the author(s)' names as in the suggested 
173 improvement.
174 I'm not sure of the significance of 'try to guess' .. but again 
175 more precise wording is needed: I don't think anyone is interested 
176 in a guess .. except as a first step in a refinement.  
177 'What we actually do' should be deleted altogether
178 as colloquial and excess verbiage. Try 'We initially guess ...' 
179 (or something similarly concise).
180 Next sentence contains some historical notes which are probably 
181 best in the text alone: the abstract would normally concentrate 
182 on results, but it should not be vague - 
183 'the optimization heuristics' tells me nothing.  This is where a 
184 *concise* description of the heuristics should be included.
185 The final sentence is almost inviting a reader to skip reading the 
186 paper altogether (and your reviewer to reject it!). It would 
187 be better if it gave some actual results achieved by the authors 
188 (both for denoising level *and* time) and compared
189 with state-of-the-art denoising levels and time from other work.
190
191 The abstract should also give an example of denoising performance 
192 - perhaps some numbers from Fig 9 
193 (but SNR improvements, not actual SNRs!).  An average from
194 fig 9 would also be reasonable.
195
196 Some more examples of writing style unacceptable in a journal ..
197
198
199 Denoising has been a much studied research issue since
200 electronic transmission was rst used. The wide range of
201 applications that involve denoising makes it uneasy to
202 propose a universal ltering method. Among them, dig-
203 ital image processing is a major eld of interest as the
204 number of digital devices able to take pictures or make
205 movies is growing fast and shooting is rarely done in
206 optimal conditions.
207
208 to
209
210 Denoising has been extensively studied since images have
211 been transmitted electronically. The wide range of applications
212 requiring noise removal makes it difficult to find a universal
213  filter. The fast growth in digital devices
214 has made digital processing become more important.
215 \end{verbatim}
216 We modified our text accordingly and hope it will be more understandable.
217 As for the optimization heuristics, the most interesting ones are described
218 in the sections isoline-segments, PI-LD, PI-PD.
219
220 \begin{verbatim}
221 What's the significance of 'shooting is rarely done in
222 optimal conditions'? It's certainly not linked to digital images 
223 alone as it affects images however they are acquired and stored.
224 \end{verbatim}
225 Pictures made with mobile phones or digital cameras are most often taken in poor light conditions and without stabilizing stand.
226 Those pictures are quite noisy and need noise removal.    
227
228 \begin{verbatim}
229 higher noise effects -> higher noise levels
230
231 imposes high output flow rates .. -> requires high data rates 
232 in the processing algorithms
233
234 is subject to high variation ... -> varies significantly from 
235 person to person
236 \end{verbatim}
237 Done with a minor revision: \textit{data transfer rates}.
238
239 \begin{verbatim}
240 Many researchers have successfully speeded up image processing 
241 algorithms with GPUs.
242 \end{verbatim}
243 Our spell checker (aspell / Texlive / American dict.) says: sped up.
244 We tried to re-phrase our sentence.
245
246 \begin{verbatim}
247 Don't use reference numbers as substitutes for author's names ..
248 For example in [11],[7]
249 and [15], authors managed to design quite fast median
250 lters. Bilateral ltering has also been successfully pro-
251 posed in [17].
252
253 reads much better as
254
255 Fast median filters have been reported[11],[7];
256 bilateral filtering was also speeded up[17].
257
258 or 
259 McGuire[11] and Chen et al[7] reported ... ;
260 Yang et al sped up a bilateral filter[17].
261
262 Giving the actual rates (in terms, say, of frames per second) would
263  be even better in putting the author's current work into context!
264 \end{verbatim}
265 Right.
266
267 \begin{verbatim}
268 What do you mean by 
269 'even apparently sub-optimal solutions'?
270 'apparently sub-optimal' implies that they might really be optimal .. 
271 However, from the rest of the sentence, 
272 it would seem that you're referring to the usual trade-off between 
273 performance and speed - 
274 lower quality algortithms that run faster .. so say that .. in 5 words 
275 instead of 5 lines ..
276 \end{verbatim}
277 Right.
278
279 \begin{verbatim}
280 Section 2
281 I cannot find the 'conditions mentioned in section 5' clearly set 
282 out there!!
283 So I find the claim that 'real life images fulfill the above 
284 conditions' untenable.
285 List the conditions (or assumptions that your method relies upon)
286  *here*.
287
288
289 such level lines based algorithms as in [6] and [12] 
290 -> level lines algorithms[6,12].
291
292 A few years ago, in [3], authors proposed an original method ->
293 Bertaux et al described a method which ... [3].
294
295 Don't put in vague things like 'a few'!! It doesn't really matter
296  how long ago anyway ..
297 if someone is curious, they can look up the reference date!!
298
299 preserve -> preserving
300 \end{verbatim}
301 Done.
302
303 \begin{verbatim}
304 reference images taken from [1] .. but [1] is hardly a complete 
305 reference
306 Are you referring to the Matlab package or Stanford's Lab?
307 In which case, say .. images from <source> Denoise Lab[1]
308 and give a complete reference .. 
309
310 .. have been published.  Where?? At least some sample references required.
311 \end{verbatim}
312 The page of Steven Lansel at Stanford Lab, where the benchmark set of images could be downloaded, is no longer available. We withdrew the reference and added
313 a footnote in the text.
314
315 \begin{verbatim}
316 Section 4
317
318 This section would seem to be partly propaganda for Nvidia.  
319 They are not the only
320 manufacturers of GPUs and this section should at least recognize 
321 this.
322
323 The important distinction between what's on a 'card' and on the 
324 silicon die on the card is lost .. 
325 even though the chip is probably the only major component of the 
326 C2070 card
327 there will be a large difference between memory access times for 
328 on-chip and off-chip memory.
329 Nvidia themselves are rather vague about this, but that's no excuse
330 for propagating this
331 vagueness into (hopefully) carefully written and objective papers.
332
333 At least the clock rate of the card should be noted here.  
334 Some other parameters like
335 memory bandwidth are important too, but I can at least place the 
336 device used in historical
337 perspective with the clock rate.  I shouldn't have to look this up 
338 from Nvidia literature.
339 \end{verbatim}
340 It is not propaganda: we don't actually have any GPU from other manufacturer at our disposal.
341 We added clock rate values and precisions about different type of memory as requested.
342
343 \begin{verbatim}
344 What does 're-serialization' mean?
345 If you mean the inclusion of necessary barriers, then say so, 
346 rather than invent 
347 a new term (or follow someone else's unnecessary invention!) 
348 for a really simple concept.
349 \end{verbatim}
350 (or follow someone else's unnecessary invention!) ??? 
351
352 Please note that we are not talking about synchronization barriers.
353 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.
354 That has made us think of a backward move and chose to speak about \textit{re-serialization}.
355 Anyway, we changed for the word \textit{serialization}.  
356
357 \begin{verbatim}
358 requires -> requires that ..
359
360 The 'A' of CUDA is 'architecture' .. adding 'model' is not necessary .. 
361 it's already a virtual architecture.
362
363 There is no way to know how .. -> The order in which threads are 
364 scheduled is not defined.
365 ('how' is wrong .. threads will certainly be scheduled  .. 
366 the key point is you don't know the order!)
367
368 The point about coalesced memory accesses is badly phrased and 
369 probably not correct.
370 Again Nvidia is not very explicit, but almost certainly coalesced 
371 accesses must 
372 lie in the same n mod 2^7 address block .. not an arbitrary 2^7 byte
373  range.
374 \end{verbatim}
375 Modified.
376
377 \begin{verbatim}
378 The point about shared memory is just wrong.  
379 Threads within a 'warp' must access the
380 same shared memory block. The use of the term 'parallel thread' 
381 here is confusing and 
382 probably should be replaced by something more explicit. 
383 Of course, data must be distributed
384 carefully among shared memory blocks - 
385 probably this is what you are trying to say.
386 \end{verbatim}
387 Our first statement was actually incomplete.
388 We reproduced the sentence from the CUDA programmer's guide instead.
389
390 \begin{verbatim}
391 Last para is a general statement that applies to *any* parallel 
392 processing architecture: the authors seem to imply that they 
393 discovered this for GPUs!
394 \end{verbatim}
395 Removed.
396
397 \begin{verbatim}
398 constraining -> difficult
399 non-suited -> badly designed
400 probably -> may
401 \end{verbatim}
402 Adjusted.
403
404 \begin{verbatim}
405 Section 5
406
407 IID .. Each image is corrupted by ONE noise distribution .. 
408 so Identically distributed is meaningless, there's only one.
409 However, if you meant *images* corrupted by noise .. then IID 
410 has meaning.
411 Small point, but this is a journal paper .. so you should get it right!
412 \end{verbatim}
413 $I$/$\widehat{I}$ represent the family of reference/corrupted images.\\
414 Adjusted.
415
416
417 \begin{verbatim}
418 'As introduced above' .. where ?? In the previous para, you've just 
419 set down some notation.
420
421 'most common images are continuous and contain few edges' ??
422 This is an extremely contentious claim!!
423 If you want to persist with this, then you should give some examples 
424 of images which satisfy this criterion!
425 There are many images used for testing image processing algorithms 
426 which (deliberately) would fail this criterion.
427 \end{verbatim}
428 As said before, we focus on 'natural images' as defined by Caselles.\\
429 Adjusted.
430
431 \begin{verbatim}
432 Section 5.1
433 Here you introduce 'fixed length' isolines.  You don't justify 
434 this or explain its significance - except the fixed length 
435 obviously helps comparisons (as in previous para) .. 
436 Does an image with large bands of the same colour still have 
437 fixed length (ie short!) isolines?
438 Note that a 'continous' image with few edges actually contains 
439 little information so it's hard to see how interesting images 
440 satisfy this criterion.
441 \end{verbatim}
442 The length of the isolines depends on the power of noise.
443 Lower power of noise leads to shorter isolines.
444
445 \begin{verbatim}
446 You use the term 'isoline part' without definition ..
447 is this a fixed length segment of a longer isoline?
448 \end{verbatim}
449 An isoline part was meant to be a non terminated isoline.\\
450 Modified.
451
452 \begin{verbatim}
453 Z is a *set* of grey levels.
454 P is the likelihood of what ?
455 \end{verbatim}
456 First point: modified.
457 As for likelihood, it is the one defined by the expression that follows.\\
458 We added $Z$.
459  
460 \begin{verbatim}
461 developped as -> re-written
462
463 Last sentence ..
464 The best isoline is the one which maximizes (5).
465
466 Section 5.2 
467 Lengthenable is not an English word .. use 'extendable'
468 larger -> longer
469 lengthening -> extension
470 512x512 -> $512 \times 512$
471
472 could be seen as 
473 possible valid ..
474 You're defining a notation here .. don't use words implying vagueness!
475 'candidate' is a good word if you're going to make a choice among 
476 possibilities at some stage.
477 hypothesis -> hypotheses 
478 'share the same mean value'?  
479 You mean that the two segments S^n and S^p must have the same mean?
480 In place of 'First' 'Second' write
481 If S^n+p is an isoline then ...
482 Alternatively, if S^n and S^p are ...
483 There is no 'third', so this is clearer ..
484
485 to validate lengthening -> to extend ...
486 depends -> depends on
487 \end{verbatim}
488 We agree and have adjusted our text.
489 As for \textit{lengthenable}, as said before, we found this word in some US Patent titles.\\ 
490 Anyway, we followed the suggestion.
491
492 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. 
493
494 \begin{verbatim}
495 You should define what you mean by an isoline carefully.
496 'iso' implies same, yet you describe the grey levels along S^n 
497 (an isoline part) as having a distribution.
498
499 This whole section needs careful re-write.  
500 A diagram explaining how a pixel and an isoline are related 
501 might help.
502 Figure 1 does not seem to help much .. it just shows an isoline 
503 which appears to have the *same* intensity along its whole length.
504 \end{verbatim}
505 Inside a noisy image, the level lines of the reference scene are corrupted by the noise. 
506 Modifications have been made. We hope to be clearer.
507
508 \begin{verbatim}
509 Section 6
510
511 combinating -> combining
512
513 Figures should appear (roughly) in the order to which they are 
514 referred! You refer to fig 8 *before* fig 2 has appeared!
515 \end{verbatim}
516 Adjusted.
517
518 \begin{verbatim}
519 To fit the GPU-specific ... 
520 Significance? 
521 Did you mean to say that you chose the number of directions, D, 
522 to be 2^k ?
523 This is hardly GPU-specific, it would be done for *any* hardware 
524 implementation!
525 \end{verbatim}
526 What is actually GPU specific is 32.\\
527 We re-phrased.
528
529
530 \begin{verbatim}
531 because of the necessary reduction stage for which GPU efficiency 
532 is not maximum ->
533 because reduction is not efficient in a GPU
534 \end{verbatim}
535 Reduction can actually be efficient on GPU. For example summing the 10 million values of one single vector is efficient on GPU.
536 But here, we talk about thousands of small and irregular sums. That is not efficient on GPU.
537 That led us to use the above expression.
538 We have tried to improve it. 
539
540 \begin{verbatim}
541 If you were inspired by Bertaux et al's work, it would be nice 
542 to use their name(s) in the text, instead of reducing them 
543 to a number!  This also saves someone who is familiar with their 
544 work having to go to the reference list to confirm
545 whose work you're talking about!
546 \end{verbatim}
547 Bertaux is actually mentionned as one of the authors. 
548 The remark is justified but we never tried to reduce the significance of his work.\\
549 Modified. 
550   
551 \begin{verbatim}
552 Section 6.1
553 When considering S^n *under construction*,
554 how do you have C_x(Z(S^n)) .. having been obtained in the *previous* 
555 extension step?
556 \end{verbatim}
557 Because those sums are computed and accumulated at each stage.
558
559 \begin{verbatim}
560 wether -> whether
561 beeing -> being 
562 Please use a spelling checker!
563
564 deviation -> orientation change
565 (deviation can imply many things .. orientation change is more 
566 specific and appropriate here)
567 \end{verbatim}
568 Done.
569
570 \begin{verbatim}
571 It's not at all clear why circular lines are not allowed?  
572 Surely this is a common situation?
573 \end{verbatim}
574 Our mistaken English. As said before, we meant to say 'lines rolling onto themselves'.
575 It does not concern isolines that would have a circular shape with large radius.  
576
577 \begin{verbatim}
578 You *use* a test (GLRT) not perform it.
579
580 For each allowed pattern, GLRT is performed in order to decide if 
581 the corresponding segment could likely be added to the end of the 
582 poly-isoline Sn. If none is validated by GLRT, the poly-isoline 
583 Sn is stopped.
584
585 to
586
587 For each pattern, we use the GLRT to decide if the segment could
588 extend the poly-isoline Sn. If none satisfies the test, Sn is 
589 terminated.
590 \end{verbatim}
591 From our point of view, a test is rather performed than used.
592 We modified the other point.
593
594 \begin{verbatim}
595 In order to avoid critical situations where the first selected 
596 segment would not share the primary 
597
598 direction ....
599 Presumably you are trying to say that for the first segment of 
600 a line, you have to consider
601 all directions so you have D lines which could be extended?
602
603 To ensure isotropy .... 'isotropy' is not the right word here .. 
604 nor is 'shares' .. I suspect you mean to say that each of the 
605 D lines has the direction of the pattern p_{l,d} ?? 
606 \end{verbatim}
607 Done with adjustments. 
608
609 \begin{verbatim}
610 Fig 2 caption
611 indexes -> indices
612 It implies -> This implies
613 \end{verbatim}
614 Our spell checker says: indexes.
615 We changed for ``indices'' anyway. 
616
617 \begin{verbatim}
618 standard deviation -> standard deviation of grey levels for 
619 (you use deviation in another sense also .. so you need to be specific here)
620 \end{verbatim}
621 Changed to avoid any ambiguity.
622
623 \begin{verbatim}
624 Section 6.2
625
626 'a bit weak' is colloquial .. use 'inferior to'
627
628 Remove 'In order to be performed'
629
630 Branches stall parts of the pipeline or leave GPU ALUs idle .. 
631 be specific instead of the vague 'do not fit'.
632
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.
636 \end{verbatim}
637 Adjusted.
638
639 \begin{verbatim}
640 Section 6.3
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.
643 \end{verbatim}
644 Sorry, but we do not see were the confusion can come from.
645
646 \begin{verbatim}
647 Section 7
648
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 
653 higher speed-ups
654 than reported here are achievable with a little work to allocate 
655 tasks in such
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 
663 number of 
664 accessses to each pixel to make this worthwhile.
665 \end{verbatim}
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.
670
671 \begin{verbatim}
672 Results should ideally separate out time to transfer images between 
673 the CPU and GPU
674 and GPU computation times, since for applications (most presumably) 
675 that want to process
676 the de-noised image in the GPU, only the GPU time is of interest.
677 \end{verbatim}
678 Adjusted.
679
680 \begin{verbatim}
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 
685 be valuable.
686 \end{verbatim}
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.   
693
694 \begin{verbatim}
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!
700 \end{verbatim}
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'. 
704
705 \begin{verbatim}
706 Conclusion
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.
712 \end{verbatim}
713 Modified.  
714
715 \end{document}