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

Private GIT Repository
7 avril pour jury
[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 why 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 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.
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 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.   
154
155
156 \begin{verbatim}
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 
164 is redundant.
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 
174 improvement.
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.
191
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.
196
197 Some more examples of writing style unacceptable in a journal ..
198
199
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
207 optimal conditions.
208
209 to
210
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.
216 \end{verbatim}
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.
220
221 \begin{verbatim}
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.
225 \end{verbatim}
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.    
228
229 \begin{verbatim}
230 higher noise effects -> higher noise levels
231
232 imposes high output flow rates .. -> requires high data rates 
233 in the processing algorithms
234
235 is subject to high variation ... -> varies significantly from 
236 person to person
237 \end{verbatim}
238 Done with a minor revision: \textit{data transfer rates}.
239
240 \begin{verbatim}
241 Many researchers have successfully speeded up image processing 
242 algorithms with GPUs.
243 \end{verbatim}
244 Our spell checker (aspell / Texlive / American dict.) says: sped up.
245 We tried to re-phrase our sentence.
246
247 \begin{verbatim}
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-
252 posed in [17].
253
254 reads much better as
255
256 Fast median filters have been reported[11],[7];
257 bilateral filtering was also speeded up[17].
258
259 or 
260 McGuire[11] and Chen et al[7] reported ... ;
261 Yang et al sped up a bilateral filter[17].
262
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!
265 \end{verbatim}
266 Right.
267
268 \begin{verbatim}
269 What do you mean by 
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 ..
277 \end{verbatim}
278 Right.
279
280 \begin{verbatim}
281 Section 2
282 I cannot find the 'conditions mentioned in section 5' clearly set 
283 out there!!
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)
287  *here*.
288
289
290 such level lines based algorithms as in [6] and [12] 
291 -> level lines algorithms[6,12].
292
293 A few years ago, in [3], authors proposed an original method ->
294 Bertaux et al described a method which ... [3].
295
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!!
299
300 preserve -> preserving
301 \end{verbatim}
302 Done.
303
304 \begin{verbatim}
305 reference images taken from [1] .. but [1] is hardly a complete 
306 reference
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 .. 
310
311 .. have been published.  Where?? At least some sample references required.
312 \end{verbatim}
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.
315
316 \begin{verbatim}
317 Section 4
318
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 
322 this.
323
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 
327 C2070 card
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
331 for propagating this
332 vagueness into (hopefully) carefully written and objective papers.
333
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.
340 \end{verbatim}
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.
343
344 \begin{verbatim}
345 What does 're-serialization' mean?
346 If you mean the inclusion of necessary barriers, then say so, 
347 rather than invent 
348 a new term (or follow someone else's unnecessary invention!) 
349 for a really simple concept.
350 \end{verbatim}
351 (or follow someone else's unnecessary invention!) ??? 
352
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}.  
357
358 \begin{verbatim}
359 requires -> requires that ..
360
361 The 'A' of CUDA is 'architecture' .. adding 'model' is not necessary .. 
362 it's already a virtual architecture.
363
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!)
368
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 
372 accesses must 
373 lie in the same n mod 2^7 address block .. not an arbitrary 2^7 byte
374  range.
375 \end{verbatim}
376 Modified.
377
378 \begin{verbatim}
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.
387 \end{verbatim}
388 Our first statement was actually incomplete.
389 We reproduced the sentence from the CUDA programmer's guide instead.
390
391 \begin{verbatim}
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!
395 \end{verbatim}
396 Removed.
397
398 \begin{verbatim}
399 constraining -> difficult
400 non-suited -> badly designed
401 probably -> may
402 \end{verbatim}
403 Adjusted.
404
405 \begin{verbatim}
406 Section 5
407
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 
411 has meaning.
412 Small point, but this is a journal paper .. so you should get it right!
413 \end{verbatim}
414 $I$/$\widehat{I}$ represent the family of reference/corrupted images.\\
415 Adjusted.
416
417
418 \begin{verbatim}
419 'As introduced above' .. where ?? In the previous para, you've just 
420 set down some notation.
421
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.
428 \end{verbatim}
429 As said before, we focus on 'natural images' as defined by Caselles.\\
430 Adjusted.
431
432 \begin{verbatim}
433 Section 5.1
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.
442 \end{verbatim}
443 The length of the isolines depends on the power of noise.
444 Lower power of noise leads to shorter isolines.
445
446 \begin{verbatim}
447 You use the term 'isoline part' without definition ..
448 is this a fixed length segment of a longer isoline?
449 \end{verbatim}
450 An isoline part was meant to be a non terminated isoline.\\
451 Modified.
452
453 \begin{verbatim}
454 Z is a *set* of grey levels.
455 P is the likelihood of what ?
456 \end{verbatim}
457 First point: modified.
458 As for likelihood, it is the one defined by the expression that follows.\\
459 We added $Z$.
460  
461 \begin{verbatim}
462 developped as -> re-written
463
464 Last sentence ..
465 The best isoline is the one which maximizes (5).
466
467 Section 5.2 
468 Lengthenable is not an English word .. use 'extendable'
469 larger -> longer
470 lengthening -> extension
471 512x512 -> $512 \times 512$
472
473 could be seen as 
474 possible valid ..
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 ..
485
486 to validate lengthening -> to extend ...
487 depends -> depends on
488 \end{verbatim}
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.
492
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. 
494
495 \begin{verbatim}
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.
499
500 This whole section needs careful re-write.  
501 A diagram explaining how a pixel and an isoline are related 
502 might help.
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.
505 \end{verbatim}
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.
508
509 \begin{verbatim}
510 Section 6
511
512 combinating -> combining
513
514 Figures should appear (roughly) in the order to which they are 
515 referred! You refer to fig 8 *before* fig 2 has appeared!
516 \end{verbatim}
517 Adjusted.
518
519 \begin{verbatim}
520 To fit the GPU-specific ... 
521 Significance? 
522 Did you mean to say that you chose the number of directions, D, 
523 to be 2^k ?
524 This is hardly GPU-specific, it would be done for *any* hardware 
525 implementation!
526 \end{verbatim}
527 What is actually GPU specific is 32.\\
528 We re-phrased.
529
530
531 \begin{verbatim}
532 because of the necessary reduction stage for which GPU efficiency 
533 is not maximum ->
534 because reduction is not efficient in a GPU
535 \end{verbatim}
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. 
540
541 \begin{verbatim}
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!
547 \end{verbatim}
548 Bertaux is actually mentionned as one of the authors. 
549 The remark is justified but we intimately never tried to reduce him.\\
550 Modified. 
551   
552 \begin{verbatim}
553 Section 6.1
554 When considering S^n *under construction*,
555 how do you have C_x(Z(S^n)) .. having been obtained in the *previous* 
556 extension step?
557 \end{verbatim}
558 Because those sums are computed and accumulated at each stage.
559
560 \begin{verbatim}
561 wether -> whether
562 beeing -> being 
563 Please use a spelling checker!
564
565 deviation -> orientation change
566 (deviation can imply many things .. orientation change is more 
567 specific and appropriate here)
568 \end{verbatim}
569 Done.
570
571 \begin{verbatim}
572 It's not at all clear why circular lines are not allowed?  
573 Surely this is a common situation?
574 \end{verbatim}
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.  
577
578 \begin{verbatim}
579 You *use* a test (GLRT) not perform it.
580
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 
584 Sn is stopped.
585
586 to
587
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 
590 terminated.
591 \end{verbatim}
592 From our point of view, a test is rather performed than used.
593 We modified the other point.
594
595 \begin{verbatim}
596 In order to avoid critical situations where the first selected 
597 segment would not share the primary 
598
599 direction ....
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?
603
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} ?? 
607 \end{verbatim}
608 Done with adjustments. 
609
610 \begin{verbatim}
611 Fig 2 caption
612 indexes -> indices
613 It implies -> This implies
614 \end{verbatim}
615 Our spell checker says: indexes. 
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}