Difference: ADNavReview (1 vs. 2)
Revision 22006-06-09 - TWikiGuest
| Line: 1 to 1 | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
| Changed: | ||||||||
| < < | ||||||||
| > > | 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 | ||||||||
| Line: 308 to 309 | ||||||||
| ||||||||
| Deleted: | ||||||||
| < < | ||||||||
Revision 12006-06-07 - TWikiGuest
| Line: 1 to 1 | ||||||||
|---|---|---|---|---|---|---|---|---|
| Added: | ||||||||
| > > |
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.
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.
| |||||||
View topic | History: r2 < r1 | More topic actions...
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