ADNavReviewNotes
The acceptance process was extremely competitive this year. We received 228 submissions from which we could offer Accept / Accept with Minor Revision to only 63 papers for Vis 2006.
DETAILS ON THE REVIEW PROCEDURE
This year for the first time the IEEE Visualization Conference Proceedings will
be published as a Special Issue of the IEEE Transactions on Visualization and Computer Graphics Journal (TVCG). A multi-round review process is done that is consistent with journal paper reviewing. After the first review-cycle the submissions have now been classified as:
- Accept: The paper is accepted for Vis 2006 as is, without a further review cycle.
- Accept with Minor Revision: The paper undergoes a second review cycle.
- Reject with Major Revision: The paper is rejected from Vis 2006. Authors receiving a major revision recommendation will be recommended to revise and resubmit
their paper to TVCG at which point it will become a new submission to TVCG.
- Reject: The paper is rejected from Vis 2006.
Attached please find the comments from the reviewers. This information contains:- comments from the paper co-chairs (optional)
- summary review from the Program Committee member responsible for your paper (primary)
- regular review from the primary (optional, if this regular review was not done, this is indicated by a zero in the overall rating)
- regular reviews (scale is 1..5\; 5 is best)
UPCOMING TASKS AND TIMELINE
Your paper will undergo a second review cycle. Please read the reviewers222 comments and apply their suggestions where possible when revising your paper. This is especially important in cases where the reviewer pointed out related work that should be cited and compared to your work. Important dates:
- 3rd July: Authors upload the revised version of their paper through PCS (https://precisionconference.com/~ieee/
).
- 17th July: Notification of final Accept / Reject sent out to authors.
- 1st Aug: Final version of accepted papers due.
Please also upload with your revised paper a cover letter (as Additional File) with comments on how you addressed the reviewer comments and on changes you incorporated. We also highly encourage you to include a video of your work. Upload your revised version through PCS via the 223Submit the final version224 link (and
do not be confused by this link name).
We are looking forward to an exciting and vibrant conference, with an outstanding set of papers. We thank you for your contribution to IEEE Visualization 2006.
Eduard Groeller, Claudio Silva, and Alex Pang
IEEE Visualization 2006 Papers Chairs
Paper 474, Review 5 ------------------------ Title: Composite Rectilinear Deformation for Stretch and Squish Navigation Reviewer: primary Overall rating: 0 (scale is 1..5; 5 is best) Summary-Review Form (1st Review Cycle) Accept with Minor Revision Short Summary Justification This is an interesting research paper, well-motivated, with a good algorithmic part and complexity analysis. Several reviewers have some difficulty understanding what exactly is meant by "regions". This should be amended. There is plenty of space left to add clarifying discussions. Regular-Review Form (1st Review Cycle) Type of Paper Overall Rating () Expertise () Short Justification Detailed Review
Paper 474, Review 1 ------------------------ Title: Composite Rectilinear Deformation for Stretch and Squish Navigation Reviewer: external Overall rating: 4 (scale is 1..5; 5 is best) Reviewer expertise: 3 (scale is 1..4; 3 = "Knowledgeable") Type of Paper Research Overall Rating 4 (Probably accept: I would argue for accepting this paper.) Expertise 3 (Knowledgeable) Short Justification This is a reasonably well-written paper which describes an efficient mechanism for performing stretch and squish navigation. The method is scalable to very large data sets. I think a few minor changes would make the paper easier to understand. Detailed Review This is an appropriate paper for Visualization 2006. It (relatively) clearly describes an algorithm for performing scalable stretch-and-squish navigation. I have a few comments as to how the exposition could be made clearer, as I had to work harder than I think I should have to understand the method. Throughout, I remained unclear about whether all points in an image move, or only some of them. This seemed unreasonably obscure. Starting with the abstract, "typical usage only changes the extents of a small subset of k of these n regions at once". I assume this means that we are "stretching" for example, only a handful of regions. But it remains true that the actual location of all of the regions changes, no? Then in the third paragraph of the introduction "a typical navigation action would only directly change some small number of regions at once, or else the visual complexity of the trasition would be overwhelming". Is this saying the same thing? However isn't it true that a typical navigation action does change all of the regions? (minus "clamping" only very briefly mentioned later in the paper). And I don't understand the comment "so complexity is not a concern" in that same paragraph. Why not? This n (tens or hundreds) is quite small; how does this comment relate to this paper's consideration of very large n? Even though the computation of relative positions requires klog(n) computations, don't you have to then compute the actual positions of all n regions for rendering? I remain confused on this point. The discussion in Section 3 of SequenceJuxtaposer, Accordion drawing, and TreeJuxtaposer comes across as somewhat odd. I am well aware that this earlier work was published by one of the authors, which presumably leads to the awkwardness. But how can a paper "assume the existence of a navigation algorithm"? Presumably this system had a navigation algorithm, no? It was a real system, wasn't it? In the first paragraph of section 4, I found the sentence beginning with "Moving these lines resizes the rectangle in the horizontal..." confusing. I'm not sure what an "entire column of regions" is. It's not really a column since it extends over many regions in the horizontal direction, right? I know what you mean, but the word "column" or "row" does not seem correct. In Figure 7, is it correct that k in this case is 2? If so this should be explicitly stated to help understanding. Figure 7 does not very well present the "klog(n)" behavior of the algorithm, since you essentially do traverse the entire tree (except for c). So it seems you should explicitly say that C's relative position is not recomputed because it is not an ancestor of either A or F (the ones that move). And it would help if you had an example where more things didn't move; this one doesn't really prove the point very well. In the second paragraph of section 6, what does it mean to say it outputs q split lines, Q. Is it q? Or Q? "clamping" is only briefly mentioned in section 5.4. All that is said is that you support a clamping ability, but I don't see how that is achieved by what is written.
Paper 474, Review 2 ------------------------ Title: Composite Rectilinear Deformation for Stretch and Squish Navigation Reviewer: external Overall rating: 5 (scale is 1..5; 5 is best) Reviewer expertise: 3 (scale is 1..4; 3 = "Knowledgeable") Type of Paper Research Overall Rating 5 (Definite accept: I would argue strongly for accepting this paper.) Expertise 3 (Knowledgeable) Short Justification A nice paper presenting a new algorithm for composite rectilinear deformation for stretch and squish navigation. Detailed Review The paper is very appropriate for the Vis 2006 conference. It is based on previous work of the authors and is an interesting and very helpful extension of their previous work. It is well written, presents all the related work in enough detail, defines all the considered requirements of the algorithm and explains the algorithm in detail. An implementation is available in the PRISAD infrastructure. The authors have tested their algorithm. The test shows that the good performance also for large data sets.
Paper 474, Review 3 ------------------------ Title: Composite Rectilinear Deformation for Stretch and Squish Navigation Reviewer: external Overall rating: 4 (scale is 1..5; 5 is best) Reviewer expertise: 3 (scale is 1..4; 3 = "Knowledgeable") Type of Paper Research Overall Rating 4 (Probably accept: I would argue for accepting this paper.) Expertise 3 (Knowledgeable) Short Justification This paper is a really nice accomplishment. It's closely related to one kind of interactive visualization, making it very relevant; it presents a clever, new algorithm; and it even has a complexity bound on performance. An admirable set of traits making it very well rounded. Detailed Review I admit I haven't taken the time to understand the algorithm in low level detail, but I understand enough to be convinced that it's efficient. There is something a little unclear though. I think the authors might be using the word "region" in two different ways. Let's distinguish between what might be called "atomic regions", which are the smallest rectangles in figure 1, and "composite regions", which are made of 1 or more atomic regions. Each of the red rectangles in figure 2 corresponds to a selection of a single composite region, made up of many atomic regions. It seems to me that, when the authors state that their algorithm's performance is O(k log n), n is the total number of atomic regions, whereas k is the number of selected composite regions. The authors don't make this distinction clear, and so initially one might think that k and n are both numbers of atomic regions: k the number of atomic regions that will be deformed, and n the total number. If k and n are indeed both numbers of atomic regions (and I suspect that's not the case), then in figure 6, if the clamping lines k0 and k2 are chosen to be at the left and right extremities respectively, then it seems to me that k would be equal to n (since every atomic region is either stretched or squished) and so the running time would be high. Continuing this line of thought, even if k were typically only a fraction of n, say k = 0.1 n or so, then the complexity would be O(k log n) = O(0.1 n log n) = O(n log n). But as I said, I think k is actually the number of selected composite regions, not the number of atomic regions being deformed. Whatever the case, the authors can tweak their presentation of ideas to make this clearer to someone like myself. Other minor points: You explain in section 5.2 why you don't support insertion of handles. I haven't thought about this very carefully, but it seems likely to me that you could support handles if you allowed your tree to become somewhat unbalanced. If h is the number of handles inserted by the user, we can assume that h is much smaller than n (since each of the h handles are created manually by the user). It may be possible to support handle insertion by simply inserting a new node in the tree of split lines, and not bothering to keep the tree balanced. Then the tree might become unbalanced by as many as h levels, and so your running time for stretch operations would become something like O(k log(n+h)) or maybe O((k+h)log(n+h)). This would still be pretty good performance, since h is small compared to n. I don't understand why section 5.5 is there. It seems to say some obvious things ... maybe cut it ? Some of the citations only mention the first author's name and should say "et al.", such as when Keahey or Carpendale are mentioned.
Paper 474, Review 4 ------------------------ Title: Composite Rectilinear Deformation for Stretch and Squish Navigation Reviewer: external Overall rating: 5 (scale is 1..5; 5 is best) Reviewer expertise: 3 (scale is 1..4; 3 = "Knowledgeable") Type of Paper Research Overall Rating 5 (Definite accept: I would argue strongly for accepting this paper.) Expertise 3 (Knowledgeable) Short Justification This paper features genuinely new content and contributes to the state of the art. It is well written and structured. The presentation is also good, with images supplementing textual explanations nicely. Just some minor issues remain, see details. Detailed Review Please add just a few words on the PRISAD framework, the term is mentioned throughout the paper and a reference is given, however, as you base your algorithms's rendering on it, some explanation would make things clearer.
).
- 17th July: Notification of final Accept / Reject sent out to authors.
- 1st Aug: Final version of accepted papers due.
Please also upload with your revised paper a cover letter (as Additional File) with comments on how you addressed the reviewer comments and on changes you incorporated. We also highly encourage you to include a video of your work. Upload your revised version through PCS via the 223Submit the final version224 link (and
do not be confused by this link name).
We are looking forward to an exciting and vibrant conference, with an outstanding set of papers. We thank you for your contribution to IEEE Visualization 2006.
Eduard Groeller, Claudio Silva, and Alex Pang
IEEE Visualization 2006 Papers Chairs
Paper 474, Review 5 ------------------------ Title: Composite Rectilinear Deformation for Stretch and Squish Navigation Reviewer: primary Overall rating: 0 (scale is 1..5; 5 is best) Summary-Review Form (1st Review Cycle) Accept with Minor Revision Short Summary Justification This is an interesting research paper, well-motivated, with a good algorithmic part and complexity analysis. Several reviewers have some difficulty understanding what exactly is meant by "regions". This should be amended. There is plenty of space left to add clarifying discussions. Regular-Review Form (1st Review Cycle) Type of Paper Overall Rating () Expertise () Short Justification Detailed Review
Paper 474, Review 1 ------------------------ Title: Composite Rectilinear Deformation for Stretch and Squish Navigation Reviewer: external Overall rating: 4 (scale is 1..5; 5 is best) Reviewer expertise: 3 (scale is 1..4; 3 = "Knowledgeable") Type of Paper Research Overall Rating 4 (Probably accept: I would argue for accepting this paper.) Expertise 3 (Knowledgeable) Short Justification This is a reasonably well-written paper which describes an efficient mechanism for performing stretch and squish navigation. The method is scalable to very large data sets. I think a few minor changes would make the paper easier to understand. Detailed Review This is an appropriate paper for Visualization 2006. It (relatively) clearly describes an algorithm for performing scalable stretch-and-squish navigation. I have a few comments as to how the exposition could be made clearer, as I had to work harder than I think I should have to understand the method. Throughout, I remained unclear about whether all points in an image move, or only some of them. This seemed unreasonably obscure. Starting with the abstract, "typical usage only changes the extents of a small subset of k of these n regions at once". I assume this means that we are "stretching" for example, only a handful of regions. But it remains true that the actual location of all of the regions changes, no? Then in the third paragraph of the introduction "a typical navigation action would only directly change some small number of regions at once, or else the visual complexity of the trasition would be overwhelming". Is this saying the same thing? However isn't it true that a typical navigation action does change all of the regions? (minus "clamping" only very briefly mentioned later in the paper). And I don't understand the comment "so complexity is not a concern" in that same paragraph. Why not? This n (tens or hundreds) is quite small; how does this comment relate to this paper's consideration of very large n? Even though the computation of relative positions requires klog(n) computations, don't you have to then compute the actual positions of all n regions for rendering? I remain confused on this point. The discussion in Section 3 of SequenceJuxtaposer, Accordion drawing, and TreeJuxtaposer comes across as somewhat odd. I am well aware that this earlier work was published by one of the authors, which presumably leads to the awkwardness. But how can a paper "assume the existence of a navigation algorithm"? Presumably this system had a navigation algorithm, no? It was a real system, wasn't it? In the first paragraph of section 4, I found the sentence beginning with "Moving these lines resizes the rectangle in the horizontal..." confusing. I'm not sure what an "entire column of regions" is. It's not really a column since it extends over many regions in the horizontal direction, right? I know what you mean, but the word "column" or "row" does not seem correct. In Figure 7, is it correct that k in this case is 2? If so this should be explicitly stated to help understanding. Figure 7 does not very well present the "klog(n)" behavior of the algorithm, since you essentially do traverse the entire tree (except for c). So it seems you should explicitly say that C's relative position is not recomputed because it is not an ancestor of either A or F (the ones that move). And it would help if you had an example where more things didn't move; this one doesn't really prove the point very well. In the second paragraph of section 6, what does it mean to say it outputs q split lines, Q. Is it q? Or Q? "clamping" is only briefly mentioned in section 5.4. All that is said is that you support a clamping ability, but I don't see how that is achieved by what is written.
Paper 474, Review 2 ------------------------ Title: Composite Rectilinear Deformation for Stretch and Squish Navigation Reviewer: external Overall rating: 5 (scale is 1..5; 5 is best) Reviewer expertise: 3 (scale is 1..4; 3 = "Knowledgeable") Type of Paper Research Overall Rating 5 (Definite accept: I would argue strongly for accepting this paper.) Expertise 3 (Knowledgeable) Short Justification A nice paper presenting a new algorithm for composite rectilinear deformation for stretch and squish navigation. Detailed Review The paper is very appropriate for the Vis 2006 conference. It is based on previous work of the authors and is an interesting and very helpful extension of their previous work. It is well written, presents all the related work in enough detail, defines all the considered requirements of the algorithm and explains the algorithm in detail. An implementation is available in the PRISAD infrastructure. The authors have tested their algorithm. The test shows that the good performance also for large data sets.
Paper 474, Review 3 ------------------------ Title: Composite Rectilinear Deformation for Stretch and Squish Navigation Reviewer: external Overall rating: 4 (scale is 1..5; 5 is best) Reviewer expertise: 3 (scale is 1..4; 3 = "Knowledgeable") Type of Paper Research Overall Rating 4 (Probably accept: I would argue for accepting this paper.) Expertise 3 (Knowledgeable) Short Justification This paper is a really nice accomplishment. It's closely related to one kind of interactive visualization, making it very relevant; it presents a clever, new algorithm; and it even has a complexity bound on performance. An admirable set of traits making it very well rounded. Detailed Review I admit I haven't taken the time to understand the algorithm in low level detail, but I understand enough to be convinced that it's efficient. There is something a little unclear though. I think the authors might be using the word "region" in two different ways. Let's distinguish between what might be called "atomic regions", which are the smallest rectangles in figure 1, and "composite regions", which are made of 1 or more atomic regions. Each of the red rectangles in figure 2 corresponds to a selection of a single composite region, made up of many atomic regions. It seems to me that, when the authors state that their algorithm's performance is O(k log n), n is the total number of atomic regions, whereas k is the number of selected composite regions. The authors don't make this distinction clear, and so initially one might think that k and n are both numbers of atomic regions: k the number of atomic regions that will be deformed, and n the total number. If k and n are indeed both numbers of atomic regions (and I suspect that's not the case), then in figure 6, if the clamping lines k0 and k2 are chosen to be at the left and right extremities respectively, then it seems to me that k would be equal to n (since every atomic region is either stretched or squished) and so the running time would be high. Continuing this line of thought, even if k were typically only a fraction of n, say k = 0.1 n or so, then the complexity would be O(k log n) = O(0.1 n log n) = O(n log n). But as I said, I think k is actually the number of selected composite regions, not the number of atomic regions being deformed. Whatever the case, the authors can tweak their presentation of ideas to make this clearer to someone like myself. Other minor points: You explain in section 5.2 why you don't support insertion of handles. I haven't thought about this very carefully, but it seems likely to me that you could support handles if you allowed your tree to become somewhat unbalanced. If h is the number of handles inserted by the user, we can assume that h is much smaller than n (since each of the h handles are created manually by the user). It may be possible to support handle insertion by simply inserting a new node in the tree of split lines, and not bothering to keep the tree balanced. Then the tree might become unbalanced by as many as h levels, and so your running time for stretch operations would become something like O(k log(n+h)) or maybe O((k+h)log(n+h)). This would still be pretty good performance, since h is small compared to n. I don't understand why section 5.5 is there. It seems to say some obvious things ... maybe cut it ? Some of the citations only mention the first author's name and should say "et al.", such as when Keahey or Carpendale are mentioned.
Paper 474, Review 4 ------------------------ Title: Composite Rectilinear Deformation for Stretch and Squish Navigation Reviewer: external Overall rating: 5 (scale is 1..5; 5 is best) Reviewer expertise: 3 (scale is 1..4; 3 = "Knowledgeable") Type of Paper Research Overall Rating 5 (Definite accept: I would argue strongly for accepting this paper.) Expertise 3 (Knowledgeable) Short Justification This paper features genuinely new content and contributes to the state of the art. It is well written and structured. The presentation is also good, with images supplementing textual explanations nicely. Just some minor issues remain, see details. Detailed Review Please add just a few words on the PRISAD framework, the term is mentioned throughout the paper and a reference is given, however, as you base your algorithms's rendering on it, some explanation would make things clearer.
- Figures
- Generally clear and well arranged. Figure one could be made smaller to allow more space for figures three and four, which are very small indeed.
Edit | Attach | Raw edit | More topic actionsTopic revision: r2 - 2006-06-09 - TWikiGuest
Site map
BETA web
Users
Groups
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback