{"id":"bdbf3571-a0ba-4868-8646-1c940e947d27","arxiv_id":"2505.01938","paper_version":1,"verdict":"REJECT","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":6,"one_line_summary":"HybridGS compresses 3DGS scenes by training a compact, quantized Gaussian representation and feeding it to the standard GPCC point cloud encoder, achieving fast codec times at a modest rate-distortion cost.","lead":"This paper describes a hybrid 3D Gaussian Splatting compressor that produces a compact integer representation and then encodes it with the standard GPCC point cloud codec, reporting much faster encoding than neural alternatives. The speed comparison, however, counts only the final codec stage and omits the long 70,000-epoch training that creates the compact representation, so the headline speed advantage is not established.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 0-2s encoding claim in the abstract and Table 2 is unsupported: it times only GPCC on an already-trained representation, omitting the 70,000-epoch generation step that every competing method's reported encoding time includes.","rationale":"The paper is clearly written, the code is public, and the components (learnable low-rank latent features, robust quantization, LQM position decomposition, GPCC encoding) form a coherent integration of known ideas. The problem is not a mathematical inconsistency in the construction but the empirical support for the headline claim. The reader's weakest assumption identifies exactly the same issue: Section 4.2.2 and Table 2 define encoding time as GPCC-only CPU time, while the abstract and Section 1 present this as the full encoding/decoding time of HybridGS. The 70,000-epoch generation stage, which is the dominant computation and is part of producing the bitstream from source views, is never timed. Every comparison method in Table 2 reports a time that includes its own per-scene optimization, so the comparison is not apples-to-apples. This matters because the speed advantage is the stated reason HybridGS is preferable to generative methods with better rate-distortion performance. The paper itself acknowledges its upper bound is vanilla 3DGS and that its rate-distortion efficiency is below end-to-end RD-loss methods, so 'comparable reconstruction performance' is also somewhat overstated; the decisive unresolved issue is the timing. A fair full-pipeline timing comparison could rehabilitate the paper if the speed advantage survives, but as written the central claim is unverified.","tokens_in":23631,"tokens_out":3373,"duration_ms":35097,"concrete_test":"Run the released HybridGS code end-to-end on 'bicycle' and 'dance' from the multiview input images on the same NVIDIA RTX 4090 used in Section 4, timing wall-clock through warm-up, LQM, the full 70,000-epoch training, pruning, and GPCC encoding, and compare that time with the Table 2 baselines (HAC 85.03s, CompGS(MM) 36.29s) measured on the same machine. If the end-to-end time is not below 2s, then the 0-2s encoding claim and the Table 2 speed comparison are invalid. As a cheaper lower-bound check, time the first 1,000 training epochs and extrapolate linearly to 70,000 before deciding whether the full run is needed.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central contribution is the claim in the abstract and Section 1 that encoding and decoding 'typically ranges between 0s and 2s' and is 'evidently' faster than SOTA. The evidence in Section 4.2.2 and Table 2 does not support this claim. HybridGS is a two-stage pipeline: the dual-channel sparse representation is produced by training a 3DGS for 70,000 epochs (Section 4.1), including 7,500 warm-up epochs, LQM decomposition, uniqueness enforcement, and progressive pruning; only then is the resulting explicit 3DGS file fed to GPCC. The reported encoding time (e.g., 0.66-1.67s for 'bicycle') is explicitly 'CPU computation time for HybridGS with GPCC. Data I/O time is excluded' (Section 4.2.2). It therefore excludes the entire generation/training stage. For a compression system, encoding is the full path from source inputs to bitstream, and for per-scene 3DGS compression this includes the per-scene optimization. The baselines are not measured the same way: HAC's 85.03s and CompGS(MM)'s 36.29s include their end-to-end compression optimization. Comparing only the GPCC tail of HybridGS against full-pipeline baselines makes the speed advantage an artifact of the measurement boundary. The abstract's 0-2s claim is thus not established; counting the omitted training stage would put HybridGS far outside that range. Because the speed advantage is the paper's headline contribution, this is load-bearing.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes HybridGS, a two-stage 3D Gaussian Splatting (3DGS) compression framework. In the first stage, a dual-channel sparse representation is trained for 70,000 epochs, producing an explicit, compact 3DGS point cloud with quantized integer positions and low-dimensional latent features for color and rotation. In the second stage, the resulting point cloud is compressed with the standard GPCC codec, using octree coding for positions and RAHT for attributes, producing a standard bitstream. The paper claims that this design provides reconstruction quality comparable to state-of-the-art generative 3DGS compression methods while being much faster, with encoding and decoding 'typically ranging between 0s and 2s'. It also introduces two rate-control mechanisms based on primitive pruning and bit-depth reduction, supported by a formula that estimates bitrate using a fixed lossless compression ratio L=1.3.","tokens_in":24002,"tokens_out":3750,"duration_ms":36050,"significance":"If the speed and quality claims were supported, the work would be valuable for practical 3DGS streaming and standardization, since it would demonstrate that standard point cloud codecs can be used on compact, quantization-aware 3DGS representations. The paper includes several positive elements: the code is publicly available; the experiments cover multiple datasets and scenes; the appendix provides ablations for position uniqueness, outlier removal, and different quantizers; and the underlying idea of coupling quantization-aware training with a standard codec is coherent and worth pursuing. However, the central speed claim is not established by the reported measurements, and the reconstruction-quality comparison is overstated relative to the actual tables. These issues affect the paper's headline contributions and cannot be resolved by minor edits.","major_comments":[{"comment":"The claim that HybridGS encoding/decoding 'typically ranges between 0s and 2s' is not supported by the experiments. Section 4.2.2 states that the reported times are 'CPU computation time for HybridGS with GPCC' and that 'Data I/O time is excluded', so Table 2 measures only the GPCC tail of the pipeline after the 70,000-epoch 3DGS training stage (Section 4.1). For a compression system, encoding is the full path from source input to bitstream; the comparison methods' times, such as HAC's 85.03s and CompGS(MM)'s 36.29s, include their full end-to-end optimization. If the 70,000-epoch training is counted, HybridGS's encoding time is not 'between 0s and 2s' and is not 'evidently' faster than the baselines. Because the speed advantage is the paper's headline contribution, this is a load-bearing flaw.","section":"Abstract and Section 4.2.2, Table 2"},{"comment":"The abstract and Section 1 state that HybridGS 'provides comparable reconstruction performance against state-of-the-art methods', but the quantitative results do not support this. On 'playroom', HAC (λ=0.0005) achieves 30.84 dB PSNR at 6.86 MB, whereas HybridGS (kc=6, HR) achieves 29.89 dB at 16.08 MB; on 'bicycle', HAC (λ=0.004) achieves 24.81 dB at 26.99 MB, whereas HybridGS (kc=6, HR) achieves 24.10 dB at 30.21 MB. In these and most other rows, HybridGS is worse on both rate and distortion than HAC. The paper's own Limitations section concedes that 'the optimal compression efficiency of HybridGS is lower than end-to-end generation compression methods using RD loss as supervision.' The 'comparable' wording is therefore misleading and should be revised to a more precise statement of the trade-off.","section":"Section 4.2.1 and Table 1"},{"comment":"The coding-time comparison in Table 2 is not apples-to-apples even beyond the measurement-boundary issue. HybridGS timings were measured on the authors' machine ('Intel Core i9-14900HX, NVIDIA RTX 4090 Laptop', Section A.1), while the comparison times for HAC, CompGS(MM), and HGSC are taken from their original papers or official code (Section 4.1), which may involve different hardware, software stacks, and optimization levels. A fair speed comparison requires either re-running the baselines on the same machine with the same measurement protocol, or clearly stating the hardware configuration of each reported number. As presented, the speed advantage is confounded by both unequal scope and unequal platform.","section":"Table 2 and Section 4.1"}],"minor_comments":[{"comment":"The rate-control formula in Eq. (8) uses a fixed lossless compression ratio L=1.3, but Table 4 shows rate errors such as a target of 10 MB for 'train' producing 8.59 MB, and the text attributes this to point density influencing L. The fixed-L assumption should be presented with an explicit caveat or replaced by a density-dependent estimate, since the authors already note that 'the denser the point cloud, the higher the compression ratio'.","section":"Section 3.2.2 and Table 4"},{"comment":"The statement 'Data I/O time is excluded' appears only in the experimental section. Since the abstract's 'between 0s and 2s' claim is central to the paper's framing, the measurement scope should be stated clearly wherever the speed claim is made, otherwise readers will reasonably interpret the numbers as end-to-end encoding time.","section":"Section 4.2.2"},{"comment":"Table 2 reports coding times for only 'bicycle' and 'room', although Table 1 includes results for five scenes. Adding timing results for the other scenes would strengthen the generality of the speed claim.","section":"Table 2"},{"comment":"Table 3's header 'Total Size' is ambiguous because it includes pre-GPCC sizes in parentheses and the bitstream size as the outer value. Clarifying that 'Total Size' is the GPCC output size and the parenthetical values are the explicit 3DGS file sizes would improve readability.","section":"Table 3"},{"comment":"The dataset name 'drjoshson' is a typo and should read 'drjohnson'.","section":"Appendix A.6, Table 7"},{"comment":"The sentence selecting 'the samples in the 50,000 and 70,000 epochs as High and Low (i.e., pruning 47% and 75% primitives)' would benefit from a brief explanation of why these two epochs were chosen, especially for reproducibility of the reported HR/LR points.","section":"Section 4.1"}],"recommendation":"reject","confidential_remarks":"The paper has a sensible idea and useful ablation work, but the central speed claim is an artifact of the measurement boundary: Table 2 times only the GPCC stage while omitting the 70,000-epoch training that produces the compact representation. The quality comparison is also overstated: HAC dominates HybridGS on both rate and distortion on several scenes. These are load-bearing flaws in the paper's headline contributions, and fixing them would require substantially changing the evaluation and the claims, not just local edits. I recommend rejection, while noting that the general direction of quantization-aware 3DGS generation followed by a standard point cloud codec may still be worth exploring in future work."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe thing to know: HybridGS is a genuine integration, not a new theoretical result. It combines quantization-aware 3DGS generation (low-rank latent features, robust quantizer, integer unique positions) with GPCC encoding, ships code, and reports rate control. That is worth a look. But the headline speed claim—encoding/decoding “typically between 0s and 2s”—is not supported by the measurements. Section 4.2.2 times only the GPCC tail on an already-trained representation and excludes data I/O; the 70,000-epoch generation/training step that produces the compact 3DGS is never timed. Baseline numbers like HAC’s 85s include full compression optimization. Counting the training stage would put HybridGS far outside the 0-2s range. The decoding number also leaves out the dequantization and MLP decoding time that the paper reports separately.\n\nWhat is genuinely useful: the LQM for integer unique positions, the two-stage rate control, and the clean demonstration that a standard point cloud codec can be applied after quantization-aware generation. The ablation material (uniqueness, pruning, outlier removal) is reasonably thorough, and the code being public helps reproducibility. The paper’s own limitation statement admits that compression efficiency is below end-to-end RD-optimized methods, which is consistent with Table 1: on playroom, HAC reaches 30.84 dB at 6.86 MB while HybridGS gets 29.89 dB at 12.15 MB. “Comparable” overstates it.\n\nSoft spots besides timing: only five scenes in the main table, RD curves on two scenes, and the rate-control formula uses L=1.3 as a single fitted constant, disclosed as preliminary. None of these are disqualifying by themselves. The citation pattern looks fine—relevant MPEG documents and recent compression work are cited.\n\nBottom line: the paper deserves a serious referee, but not in current form. The speed comparison needs to be redone end-to-end, with training time counted or explicitly excluded and clearly stated as generation time rather than encoding time. If the authors fix the measurement boundary and soften the abstract, this is a solid technical report for the MPEG/3DGS streaming crowd. I would not cite the 0-2s claim, but I would cite the LQM and rate-control pieces.","headline":"HybridGS is a useful, reproducible integration of quantization-aware 3DGS generation with GPCC, but the headline 0-2s encoding claim is not supported because it excludes the 70,000-epoch training stage that baselines include in their reported times.","tokens_in":24543,"tokens_out":2619,"would_cite":true,"duration_ms":26208,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"HybridGS compresses 3D Gaussian Splatting scenes into standard point-cloud bitstreams with roughly two seconds of coding time, at reconstruction quality comparable to state-of-the-art generative compression methods like HAC.","keywords":["3D Gaussian Splatting compression","point cloud compression","GPCC","dual-channel sparse representation","quantization-aware training","rate control","novel view synthesis","primitive pruning"],"falsifier":"Run both pipelines end-to-end on the same hardware and scenes: HybridGS in full (70,000-epoch generation plus GPCC coding) and a state-of-the-art generative method such as HAC, measuring total wall-clock time to a compressed bitstream and the resulting PSNR. If the generation training is counted, the speed advantage reported in Table 2 (0.66 to 1.67 seconds versus 17 to 132 seconds) shrinks to roughly the training-time ratio, which directly decides whether the speed claim describes the whole compression system or only its last stage.","tokens_in":23414,"feed_emoji":"⚡","tokens_out":12204,"duration_ms":109435,"temperature":0.7,"pith_summary":"HybridGS addresses the practical bottleneck of 3D Gaussian Splatting (3DGS) compression: today's best methods embed scene data in bespoke neural formats and take from tens of seconds to over a minute to encode. The paper argues this trade-off is unnecessary. It builds a two-stage pipeline that first generates an explicit, compact 3DGS representation with integer positions and quantized low-dimensional latent features, then compresses that file with a standard point cloud codec (GPCC). The reported result is reconstruction quality close to state-of-the-art generative compression while encoding and decoding typically finish in 0 to 2 seconds, producing standardized bitstreams. The claim matters because it points to a route where 3DGS streaming can inherit mature, standard codec infrastructure instead of waiting on bespoke neural decoders.","feed_headline":"Gaussian scene coding slashed from 85 seconds to under two","feed_subtitle":"Compact Gaussian generation plus standard point-cloud coding keeps near-top quality at a fraction of the time.","key_machinery":"The load-bearing mechanism is the dual-channel sparse representation paired with a standard downstream encoder. 'Dual channel' denotes two kinds of sparsity imposed during generation: attribute sparsity, in which compressible features (color and rotation) are replaced by low-dimensional latent codes decoded by a one-hidden-layer MLP — a trained analogue of PCA — and precision sparsity, in which all attributes are quantized to a chosen bit depth inside the training loop using the Robust Quantizer, whose perturbation-injected affine transform at quantization and ridge-regression reconstruction at de-quantization keep quantization differentiable. For positions, the Learnable Quantizer-based Method (LQM) translates and rescales the scene into the integer range of a chosen bit depth, decomposes each integer coordinate as an inner product of a fixed basis vector and a learnable coding vector over $\\{-1,0,1\\}$, and enforces primitive uniqueness with progressive pruning, so positions render directly without de-quantization. The output is an explicit integer file whose per-primitive bit cost $3(\\mathrm{BD}_p+\\mathrm{BD}_s)+k_c\\mathrm{BD}_c+\\mathrm{BD}_o+k_r\\mathrm{BD}_r$ is known in closed form; GPCC then encodes geometry by octree and attributes by RAHT, and that same formula is what makes rate control possible — prune primitives to hit a target count, or reduce attribute bit depth uniformly.","core_discovery":"The central claim is that 3DGS compression does not have to sacrifice speed for compactness. Because 3DGS is surjective — many distinct primitive sets render to nearly identical views — the generation stage can be steered toward a representation that a conventional codec handles well, and HybridGS does exactly that in two steps. First, a dual-channel sparse representation supervises the primitive position field and the attribute bit depth during training: color and rotation are reconstructed from low-dimensional latent codes through a lightweight one-hidden-layer decoder, a trainable analogue of PCA; attributes are quantized during training with a robust quantizer; and positions are converted to unique integers through a learnable basis-vector and coding-vector decomposition, with progressive pruning and deduplication governing the primitive count. Second, the resulting explicit file is encoded by GPCC, with positions in octree mode and attributes via RAHT. On five benchmark scenes the paper reports PSNR within a small margin of HAC and CompGS(MM) while cutting coding time from tens of seconds to well under two seconds. Because HybridGS deliberately omits modules that would improve rendering quality, its declared quality ceiling is vanilla 3DGS itself, which the authors treat as a feature: compression loss stays interpretable.","pith_inferences":["Read as an end-to-end system, HybridGS suits offline asset preparation: the 70,000-epoch training that creates each compact scene happens once, and the 0 to 2 second figure covers only the coding pass, so the practical niche is fast streaming or delivery of already-processed scenes, not live encoding.","The paper's own numbers show GPCC's lossless ratio on 3DGS data (about 1.3 to 1.5 times) is far below its 3 to 4 times on dense point clouds; codec-side work tuned to 3DGS's locally dense, globally sparse geometry could roughly double the compression at no quality cost.","Because position uniqueness is enforced during generation, the explicit integer files are also ready-made inputs for learning-based point cloud codecs, whose destructive deduplication of duplicated points would otherwise be a source of loss.","The reported divergence between training-view and test-view PSNR under pruning suggests that compression-quality studies on 3DGS should report both; a method could look better on held-out views than it actually is on the views it was trained on."],"forward_implications":["Coding time for 3DGS scenes drops from the tens of seconds to minutes reported for HAC, CompGS(MM), and HGSC down to roughly 0 to 2 seconds, bringing interactive streaming of preprocessed Gaussian scenes into reach.","Because the output is a standard point-cloud bitstream, 3DGS compression can ride on existing codec deployments and hardware rather than requiring a custom neural decoder at the receiver.","Rate control becomes predictable: target bitrates are reached by pruning primitives or lowering feature bit depth against a known per-primitive bit budget, whereas RD-trained generative methods only discover their achieved rate after optimization.","The deliberate absence of quality-improving modules caps HybridGS at vanilla 3DGS quality, and the paper reports that pruning can occasionally even raise PSNR slightly by removing redundant primitives — evidence that primitive count is not a strict quality ceiling."],"supporting_citations":[{"why":"Defines vanilla 3DGS, the primitive format and rendering pipeline that HybridGS compresses; supplies the base representation and the rendering loss used in generation.","marker":"(Kerbl et al., 2023)"},{"why":"Contributes the primitive-pruning observation and strategy that HybridGS adapts, including the claim that roughly 60% of primitives contribute marginally to quality.","marker":"(Fan et al., 2024)"},{"why":"Supplies the Robust Quantizer (PAT-Q and DAT-R) used to make attribute quantization differentiable inside 3DGS generation.","marker":"(Ye et al., 2024)"},{"why":"The GPCC test model v23 that produces the standard output bitstreams and is the source of the reported sub-two-second coding times.","marker":"(WG7, 2023)"},{"why":"Defines RAHT, the transform GPCC uses to compress 3DGS attributes such as color, opacity, scaling, and rotation as point-cloud attributes.","marker":"(De Queiroz & Chou, 2016)"},{"why":"HAC, the state-of-the-art generative compression baseline whose reconstruction quality and 85-second encoding time HybridGS is compared against.","marker":"(Chen et al., 2024b)"},{"why":"CompGS(MM), the rate-distortion-trained generative baseline that sets the quality and speed benchmark HybridGS must approach.","marker":"(Liu et al., 2024)"},{"why":"HGSC, the traditional-compression baseline showing that compressing vanilla 3DGS data without altering generation yields much larger bitstreams at similar PSNR.","marker":"(Huang et al., 2025)"},{"why":"Source of the lightweight one-hidden-layer MLP decoder design used to reconstruct color and rotation from low-dimensional latent features.","marker":"(Girish et al., 2025)"},{"why":"Provides the study of 3DGS geometry quantization bit depth (optimal around 14 to 18 bits) that motivates the position bit-depth settings used in HybridGS.","marker":"(Zaghetto et al., 2024)"}],"fun_headline_variants":["40x faster Gaussian splatting compression with standard codec","3DGS coding slashed from 85 seconds to under two","HybridGS: point-cloud encoder beats custom formats at 40x speed","Compact Gaussian storage via dual sparse channels and GPCC"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The 0 to 2 second encoding claim counts only the final GPCC point-cloud coding pass; the roughly 70,000-epoch training run that produces the compact representation is not included in that time, even though the competing methods' published encoding times include their entire compression process.","fun_headline_variants_meta":{"raw":{"variants":["40x faster Gaussian splatting compression with standard codec","3DGS coding slashed from 85 seconds to under two","HybridGS: point-cloud encoder beats custom formats at 40x speed","Compact Gaussian storage via dual sparse channels and GPCC"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000529,"raw_usage":{"total_tokens":2574,"prompt_tokens":994,"completion_tokens":1580,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":610,"completion_tokens_details":{"reasoning_tokens":1507}},"tokens_in":610,"tokens_out":1580,"duration_ms":12601,"temperature":1.0,"reasoning_tokens":1507,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T04:06:47.995915+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run both pipelines end-to-end on the same hardware and scenes: HybridGS in full (70,000-epoch generation plus GPCC coding) and a state-of-the-art generative method such as HAC, measuring total wall-clock time to a compressed bitstream and the resulting PSNR. If the generation training is counted, the speed advantage reported in Table 2 (0.66 to 1.67 seconds versus 17 to 132 seconds) shrinks to roughly the training-time ratio, which directly decides whether the speed claim describes the whole compression system or only its last stage.","supporting_citations":[],"review_version":1}