修夜景的生成式模型一直被一个两难卡着：窗口看得越全，显存越爆；窗口切得越细，整张图的明暗又统一不起来。P-PatchDiff 的转折点，是把「去噪这一步看多大窗口」从写死的超参，变成随去噪进度伸缩的旋钮——生成式的低光增强，第一次跑得动 4K 整图。
暗光增强要把欠曝照片提亮、找回颜色和细节，而「提多亮、往什么色温提」取决于整张图的亮度分布：路灯亮着、角落全黑，不同区域的正确答案完全不同。扩散模型——文生图背后那类一步步把噪声「擦」成图像的生成模型——在这种任务上细节和颜色最自然，但它每步去噪都要把整张图过一遍网络，照片一到 4K（八百多万像素）显存就装不下。
业内的折中是把图切成小块（patch），一块块分别去噪再拼回去。代价是每块只能看到自己那点地盘，各自决定提多亮、往暖还是往冷提，拼回整图就是满图「补丁感」；暗光照片恰恰是亮度分布最不均匀的一类图，病得最重。把窗口放大能缓解，显存又上去了；几种尺度各跑一遍再平均，不同尺度的亮暗统计还会互相打架。
P-PatchDiff 的做法：窗口从 64×64 起步，随去噪推进逐级放大到 192×192——前期窗口小，专注把每块的纹理颜色擦干净；后期窗口大，负责把整图明暗统一。配套细节：块与块之间的间隔（步长）跟着窗口一起放大，既压住后期计算量，又守住「间隔不超过窗口一半」的经验线，避免拼图接缝。
光有调度还不够：不同大小的窗口，亮度和颜色统计天然不一致。第二个关键件是「全局亮度地图」——用一个很轻的 U-Net（编码-解码结构的小网络）从欠曝原图估出整图「该提亮到什么程度」的低分辨率参考，塞进去噪网络的每一层，每块工作前先对齐它，知道自己在整图亮度分布里的位置。作者故意不用物理光照模型，要的就是一个部署起来简单的统计量。
结果：4K 低光图 93 秒跑完，既有的切块扩散方法跑同一张图要 8232 秒，两个多小时。峰值显存 8.8GB，单张 12GB 级消费显卡装得下；不少全图扩散方法在这个分辨率直接爆显存。质量上它在标准低光测试集处在最强一档，换到没见过的真实长曝光和 4K 数据反而领先；采样也压到了 5 步。去模糊、去雨上换数据重训同样成立——这套窗口调度不是低光专属。
往真实工作流看：手机相册的夜景增强和老照片提亮，长期在「一键提亮的速度」和「生成式的质量」之间二选一，这套方法把生成式质量推到 4K、单卡可及的位置；监控安防的低光流活在 4K/8K 上，用不上扩散模型正是因为扩展不动。更通用的是这套组合拳——「局部要细节、全局要一致」的拉扯贯穿所有影像任务，去雾、HDR、整片调色都适用，「窗口随进度伸缩 + 全局统计对齐」是可以直接搬的骨架。作者也点了下一步：把调度搬进隐空间（先把图压小再处理），速度再降一个量级，那才是能进手机的前景。
局限也要说清：显存降了，总计算量没省——块仍从全分辨率整图上裁，重叠区域被反复处理；极暗区域偶尔「整块失明」，结构直接消失，作者归因于缺语义层面的一致性约束。真正值得追问的是那张全局亮度地图：它学的是整图平均亮度统计，一旦画面一半是暖光路灯、一半是冷色广告牌，这张「标准答案」本身就可能是错的——多光源混合场景，论文没有测。