app+csdk+docs: 修正上一轮最近邻2×的退化（颗粒/边沿台阶）——照片改为从160×120单级6×放大（官方ImageViewer同款），实时缓冲与csdk回退为插值2×；实测冷区|dx| 0.76×官方（更平滑），119单测全绿

csdk/include/mag160c/mag160c_render.h

@@ -61,12 +61,13 @@ typedef struct mag160c_render_cfg_t {
     /* Brightness offset for the Android LUT base; the official app passes 0. */
     int lut_brightness;
     /* 1 = replicate pixels in the 160x120 -> 320x240 stage instead of interpolating.
-       The official ANDROID path has no such stage at all (its SDK hands the app a
-       160x120 bitmap which ImageViewer draws with a non-filtering paint = nearest),
-       while the PC SDK's bilinear version fabricates an interleaved full/half
-       amplitude column pattern at the sensor Nyquist - visible as extra fine stripes
-       in the dark/cold regions.  Measured on device: fine-scale cold-region stripe
-       ratio vs the official 1.16-1.29x (bilinear) -> 1.00/0.93 (nearest). */
+       Measured on device, this is the WRONG trade: replication halves the effective
+       resolution (2-sensor-pixel granules, a coarse staircase along hot/cold edges,
+       reported by the user), while the interpolation only adds a faint full/half
+       amplitude column pattern at the sensor Nyquist.  A consumer that can draw
+       gray160 directly (like the Android app's photo path: one 6x bilinear step from
+       the sensor grid) needs no intermediate stage at all and gets both right.
+       Kept as a switch for experiments; leave 0. */
     int upscale_nearest;
     mag160c_render_ffc_cb_t ffc_cb;
     void *ffc_user;

csdk/tools/mag160c_demo3.c

@@ -618,7 +618,12 @@ int WINAPI WinMain(HINSTANCE inst, HINSTANCE prev, LPSTR cmd, int show) {
     cfg.cdf_pivot_75 = 1;      /* kept for the PC path */
     cfg.android_lut = 1;
     cfg.fpa_temp_fix = 1699;   /* BasePara2.fpaTempFix of device 160043865 */
-    cfg.upscale_nearest = 1;   /* official Android path has no interpolating 2x stage */
+    /* Keep the interpolating 2x: the nearest variant halves the effective
+       resolution (2-sensor-pixel granules / a coarse staircase on hot-cold edges),
+       which was visible on device.  A display path that consumes gray160 directly
+       needs no intermediate stage at all - that is what the Android app now does
+       for its photos (single 6x step from the sensor grid). */
+    cfg.upscale_nearest = 0;
     cfg.ffc_cb = ffc_cb;
     cfg.post_nuc_cb = post_nuc_cb;
     cfg.post_gray_cb = post_gray_cb;

csdk/tools/mag160c_linux_demo.c

@@ -134,7 +134,12 @@ int main(int argc, char **argv) {
     cfg.cdf_pivot_75 = 1;      /* kept for the PC path */
     cfg.android_lut = 1;
     cfg.fpa_temp_fix = 1699;   /* BasePara2.fpaTempFix of device 160043865 */
-    cfg.upscale_nearest = 1;   /* official Android path has no interpolating 2x stage */
+    /* Keep the interpolating 2x: the nearest variant halves the effective
+       resolution (2-sensor-pixel granules / a coarse staircase on hot-cold edges),
+       which was visible on device.  A display path that consumes gray160 directly
+       needs no intermediate stage at all - that is what the Android app now does
+       for its photos (single 6x step from the sensor grid). */
+    cfg.upscale_nearest = 0;
     cfg.ffc_cb = ffc_cb;
     mag160c_render_t *render = NULL;
     if (mag160c_render_init(&render, &cfg) != MAG160C_OK) {