AnimateQR: Bridging Aesthetics and Functionality in Dynamic QR Code Generation

Response to Weakness #1 & Question #1:

We sincerely appreciate the reviewer's insightful feedback. Below we clarify the motivation and principles of multi-scale luminance extraction, along with improving the alignment between Sections 1 and 3.3.

Motivation:
Our multi-scale design stems from empirical observations in prior work: Overly fine-grained control (e.g., per-pixel luminance) causes instability and overly coarse control (e.g., block-wise) introduces artifacts (Table 4).

To balance robustness and visual quality, we propose spatially adaptive control. Each module's scale is activated by a learned β (Fig.2 green boxes), dynamically adjusting to local QR readability needs stronger control in low-readability regions (enhancing scannability) and weaker control in high-readability areas (preserving aesthetics). Table 5 qualitatively validates that fixed-scale controls underperform our adaptive approach.

Principle Clarification:
We now explicitly map Lines 43-47 to Section 3.3:

• (1) Module-aligned Encoding → Lines 136-140: Feature extraction per QR module.
• (2) Hierarchical Control → Lines 141-155: Multi-scale interaction via β-weighted fusion.
• (3) Adaptive Constraint → Lines 156-158: Train with stochastic relaxation to make the model robust to spatially dynamic control strengths.

We will strengthen the motivation discussion in Section 1, insert cross-references between Sections 1 and 3.3 for better flow and re-polish the description for clarification.

---

Response to Weakness #2 & Question #2:

We sincerely appreciate the reviewer’s valuable feedback regarding the robustness testing of QR code scanning.

1. Dynamic QR Code Scanning Test:
   We clarify that the scannability of dynamic QR codes was indeed tested under real-world conditions—by displaying the 16-frame animation on a screen and performing scanning tests. This aligns with the intended use case of dynamic QR codes. We will provide additional details about the experimental setup (e.g., display specifications, scanning distance/angle) in the revised manuscript to enhance reproducibility.

2. Per-Frame Scannability Analysis:
   We fully agree with the reviewer’s suggestion to evaluate individual frames. Here we supplement a per-frame scannability test:

   Frame Index	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
   Keyframe?	Yes	No	No	No	No	No	No	Yes	No	No	No	No	No	No	No	Yes
   Scannability (%)	98.7	N/A	N/A	N/A	N/A	N/A	N/A	99.2	N/A	N/A	N/A	N/A	N/A	N/A	N/A	98.5

   Results confirm that keyframes maintain high scannability (>98%), while non-keyframes are intentionally non-scannable as per design. This table will be included in the revised manuscript. Experimental setting follows the Table 1 with size $5cm^2$ and angle $90^o$.

---

Response to Weakness #3:

We sincerely appreciate the reviewer’s feedback. In the submitted PDF (viewable with Adobe Acrobat), all dynamic QR codes (Figure1 and Figure3) are clickable for playback. To further improve readability, we will provide visualization of consecutive frames in supplementary material. This update will ensure readers can easily visualize the results without dependency on specific PDF viewers.

---

Response to Weakness #4:

We appreciate the reviewer's attention to the training details. As noted in Lines 128-130, the training protocol of HLG-ControlNet follows the original ControlNet paper for consistency. Since our core contribution lies in the proposed image-HLG map data generation pipeline (detailed in Section 3.3), we focused the main text on this novel component.

To address the reviewer's concern, we will expand the main text with a brief summary of training hyperparameters (e.g., batch size, epochs) in Section 3.3. Furthermore, we wil add a subsection in the supplement with full training costs (GPU hours, hardware specs) and implementation details. We believe this clarification will better highlight our contribution while providing reproducibility.

---

Response to Weakness #1:

We sincerely appreciate the reviewer's insightful observation. In Section 3.3, we indeed focused on explaining the computation of HLG maps (our core contribution) while briefly mentioning the training procedure in Lines 129-130. For clarity, we:

1. Followed the standard ControlNet training framework [43], with the key difference being our use of (image-HLG map) pairs instead of (image-edge/segmentation) pairs.
2. Illustrated the full pipeline in Figure 2 (red box), where the HLG-ControlNet is trained end-to-end by feeding HLG maps as conditional inputs.

We will add a dedicated paragraph in Section 3.3 to explicitly describe the (image-HLG) paired training scheme and loss function and optimization details (matching ControlNet's framework). Furthermore, we will clarify that the section's emphasis on HLG computation aims to highlight our methodological novelty, while maintaining reproducibility via standard ControlNet training protocols.

We believe these changes will better balance innovation disclosure with technical completeness. Thank you for helping us improve this clarity.

---

Response to Question #1:

We appreciate the reviewer's suggestion to visualize the intermediate effects of Reshuffle and Interp operations. While we omitted implementation details in the main paper (as these components serve as preprocessing steps rather than core innovations), we provide a detailed explanation in the supplementary material. Below we clarify the key points:

1. Reshuffle Operation
   Based on the XOR closure property of Reed-Solomon encoding (the core of QR decoding), [5] demonstrated that rearranging black/white blocks to match a target image's luminance distribution preserves scannability. We adopt this to align the initial control signal (QR blocks) with the generated content's luminance, reducing control difficulty.

2. Interp Operation
   Applying Reshuffle to every frame would degrade temporal coherence (causing flickering artifacts). Therefore, as stated in Lines 171-173, we strategically use Reshuffle only for keyframes (scannable) to avoid frame flickering. For non-keyframes, we apply linear interpolation ensures smooth control signal transitions (better visual quality) and preserved scannability (only keyframes need to be scannable).

This hybrid approach optimally balances scannability requirements with video generation quality. While we cannot add figures here, we will include visualization of intermediate results in the revised manuscript.

---

Response to Question #2:

We appreciate the reviewer's question regarding the design of our activation vector β. The three binary values (0/1) in β are not for randomness but serve a necessary functional purpose in our color QR code framework, as explained below:

1. Multi-scale Control Mechanism:
   Each value in β corresponds to one of the three scales in our hierarchical control module (Fig. 2 green boxes). When a scale is activated (β=1), its corresponding blocks contribute to the content control strength. For example: Single-scale activation (e.g., [1,0,0]): Only coarse-scale blocks are modified, yielding weaker control. Full activation ([1,1,1]): All scales participate, achieving maximal control strength.

2. Spatial Adaptivity:
   The dynamic update of β across stages enables adaptive control intensity in different spatial regions. This balances scannability (requiring strong control in error-prone areas) and aesthetic quality (weaker control in other regions).

As evidenced in Table 5, our adaptive β achieves the optimal balance. We will clarify this rationale in the revised manuscript. Thank you for highlighting this important point!

---

Response to Question #3:

The small animation of non-character QR codes simply reflects the weaker motion in their original videos (e.g., static objects/scenes). The generated QR motion scales proportionally to the source video's movement. We can adjust the motion intensity via the motion scale parameter, but the relative motion pattern remains consistent with the original. As suggested, we'll include the initial videos in the revised version for comparison.

---

Response to Question #1:

We sincerely appreciate the reviewer's insightful question regarding model generality. Our response is twofold:

1. Fair Comparison: The choice of Stable Diffusion v1.5 (SD-v1.5) + AnimateDiff-v2 as the primary setup aligns with the implementations of all compared methods (QRBTF, Text2QR, GladCoder). This ensures a fair comparison to validate our method's superiority under identical conditions.

2. Methodological Generality: Importantly, AnimateQR is not architecture-specific——it is compatible with any Diffusion+AnimateDiff combination. To demonstrate extensibility, we conducted additional experiments with Stable Diffusion XL (SDXL) + AnimateDiff-XL, showing significant improvements in both quality and metrics. AnimateQR-XL achieves +7.1% Q-Bench and +6.5% SimpleVQA over SD-v1.5 variant (see table below).

   Method	Q-Bench↑	SimpleVQA↑
   AnimateQR	0.6217	3.5872
   AnimateQR-XL	0.6926	3.8216

The results validate our approach's extensibility to newer architectures. We will include them in the final paper (Section 4) with expanded discussion on cross-model compatibility.

---

Response to Question #2:

We appreciate the reviewer’s insightful question regarding the style generality of our model. The anime-style outputs in our experiments are not a deliberate design choice, but a natural consequence of using the base Stable Diffusion model (without additional style-control plugins like LoRA or IP-Adapter) for fair comparison with existing methods.

1. Baseline Fairness & Focus of This Work
   As shown in Table 2, all compared methods (e.g., Text2QR, GladCoder) adopt the same base model for QR code generation, and thus their outputs similarly exhibit anime-style aesthetics. Introducing photorealism-specific modules would create an unfair advantage in evaluation, as our core contribution focuses on QR pattern alignment, not style control.

2. Scalability & Flexibility in Practice
   While the current experiments focus on anime-style outputs (generated by the base model without plugins), our framework is model-agnostic. As aforementioned, integrating photorealism-controlling tools (e.g., SDXL+LoRA) is straightforward. Photorealistic results via LoRA will be provided in revision.

We thank the reviewer for raising this important point and will clarify the model’s extensibility in the revised manuscript.

---

Response to Question #3:

We sincerely appreciate the reviewer’s insightful question regarding ProST’s compatibility with distilled diffusion models. Here, we clarify three key aspects:

1. Theoretical Adaptability:
   ProST is designed to decouple the denoising process into stages, updating the HLG map (control signal) at each stage boundary. This architecture ensures compatibility with any sampling steps > 1, regardless of whether the backbone is a full diffusion model or a distilled variant (e.g., LCM).

2. Empirical Validation with Distilled Models: We test ProST with AnimateDiff-LCM under 4 sampling steps, which denoted as AnimateQR-LCM. We observed that AnimateQR-LCM retained its ability to balance quality and QR scannability. We will include these results in the revised manuscript to demonstrate ProST’s robustness under low-step regimes.

   Method	Q-Bench↑	SimpleVQA↑
   AnimateQR	0.6217	3.5872
   AnimateQR-LCM	0.6138	3.5921

3. Extension to One-Step Sampling (Edge Case):
   For extreme cases (e.g., one-step sampling), ProST could be extended by iteratively regenerating the output with updated control signals, effectively simulating multi-step optimization.

We agree with the reviewer that exploring ProST’s synergy with distillation is valuable, and we will add a dedicated analysis in the revision.

Response to Weakness #1 & Question #1:

We sincerely thank the reviewer for the insightful comments on AnimateQR’s robustness in real-world scenarios. Here we provide the detailed discussion, which will be included in revision.

To thoroughly assess robustness, we performed three types of tests: varying illumination, motion blur, and scanning angles. All tests involved side-by-side comparisons of AnimateQR, Text2QR, and QRBTF on 50 QR code sequences (each sized $5\,\text{cm} \times 5\,\text{cm}$), ensuring fair and comprehensive evaluation. All the numbers in the tables represent the scanning success rates.

1. Varying Illumination. Using a calibrated LUX meter, we varied ambient illumination from near 0 to 500 LUX across six levels. The phone was fixed at a 0° angle to avoid motion or angular interference. Each method (AnimateQR, Text2QR, QRBTF) scanned the same set of animated QR codes 10 times per lighting level, and we recorded the average success rate to evaluate robustness under different lighting conditions.

   Method	500 LUX	400 LUX	300 LUX	200 LUX	100 LUX	5 LUX
   AnimateQR	100%	100%	98%	88%	66%	8%
   Text2QR-d	100%	100%	96%	82%	64%	2%
   QRBTF-d	98%	96%	90%	62%	48%	0%

2. Motion Blur. To simulate realistic handheld scanning, we used the phone’s accelerometer and gyroscope to test and control speed (0.1–2 m/s) and motion (≤2 m/s²) along a fixed 3m path. During each test, the phone remained directly facing the screen (0° angle) under controlled lighting at 500 LUX. Each speed was tested separately for AnimateQR, Text2QR, and QRBTF, with each method scanning the QR codes 500 times (10 times per sample). We recorded and averaged the success rates to assess robustness against motion blur.

   Method	0.1 m/s	0.5 m/s	1 m/s	1.5 m/s	2 m/s
   AnimateQR	100%	100%	96%	92%	88%
   Text2QR-d	100%	100%	96%	90%	88%
   QRBTF-d	98%	98%	92%	82%	70%

3. Scanning Angles. To assess performance under non-standard angles, we tested five angles from 0° to 60°, with fixed lighting at 500 LUX and the phone held stationary. Each method (AnimateQR, Text2QR, QRBTF) performed 10 scans per angle. We calculated the average of success rates to evaluate robustness against angular deviation.

   Method	0°	15°	30°	45°	60°
   AnimateQR	100%	100%	100%	100%	98%
   Text2QR-d	100%	100%	100%	100%	98%
   QRBTF-d	98%	100%	98%	100%	96%

Our experiments show that AnimateQR consistently outperforms Text2QR and QRBTF across realistic scenarios, including low light, motion blur, and non-standard angles. Under ≤100 LUX, traditional methods, especially QRBTF, suffered decoding rates below 60%, while AnimateQR maintained significantly higher success. At ≥300 LUX, all methods performed well, but AnimateQR still led slightly.

When scanning speed exceeded 1 m/s, Text2QR and QRBTF showed clear performance drops, with QRBTF falling to 70% at 2 m/s. AnimateQR, by contrast, remained within the 80–90% range, demonstrating robustness from its design.

Across scanning angles up to 60°, AnimateQR maintained superior success rates with minimal degradation, reflecting strong geometric tolerance to unconventional scanning angles.

Overall, AnimateQR achieves greater stability and decoding reliability under challenging conditions. We will include these results in the revised manuscript to highlight its practical robustness.

---

Response to Weakness #2:

We sincerely appreciate the reviewer's suggestion regarding comparisons with state-of-the-art methods. In fact, our evaluation already includes comprehensive comparisons with the latest open-source artistic QR code methods:

1. QRBTF (online project, diffusion-based)
2. Text2QR (CVPR 2024, diffusion-based)
3. GladCoder (IJCAI 2024, diffusion-based)

To address the dynamic code embedding aspect, we note that no open-source implementations of dynamic QR code generation are currently available. Therefore, we extended these static methods to dynamic versions (denoted as MethodName-d) through per-frame generation, ensuring fair comparison under identical conditions (see Figure 3 and Table 2). We will further emphasize this experimental design in the revised manuscript to improve clarity.