[Docs]: 屏幕分辨率过大导致截图文字无法识别。

[s9ik]

📌 Documentation Location

由于我的屏幕是8k分辨率，导致它截图好像无法识别到准确内容，截图里的文字都是模糊的，有没有什么方法可以改进。

🚑 Issue with Current Content

No response

👍 Suggested Improvement

No response

[s9ik]

例如，现在的截屏是这样的。。

[s9ik]

🧩 Bug 报告：高分辨率屏幕下截图模糊、OCR 识别率低

问题描述

在高分辨率显示器（4K/5K/8K）上运行 MineContext 时，Screen Monitor 捕获的截图分辨率明显低于实际显示分辨率，导致截图内容模糊、文字识别不准确、细节丢失等问题。

主要现象

• 当系统缩放比例 ≥150% 时，截图明显不清晰；
• 屏幕物理分辨率为 3840×2160，但实际保存的截图像素仅约 2560×1440；
• OCR 识别文字时出现大量误判或无法识别；
• 当系统缩放比例调回 100% 后，截图与识别均恢复正常。

结论

MineContext 当前的截图逻辑未正确处理 Windows 的 DPI 缩放机制，在高 DPI 环境下调用的截图 API 返回的是缩放后的逻辑坐标画面，而非原始物理像素。

---

可能原因（技术分析）

1. Electron 主进程未声明 Per-Monitor DPI Aware 模式；
2. 截图调用 desktopCapturer 或系统 GetDC(NULL) 时，未使用物理像素坐标；
3. Electron 默认会以逻辑 DPI 进行缩放，从而丢失分辨率；
4. OCR 模块获取的是缩放后图像，实际 DPI 低于 100，导致识别率显著下降。

---

建议修复方案

1. 在 Electron 主进程启用 DPI 感知

在 main.js 中添加如下设置：

app.commandLine.appendSwitch('high-dpi-support', '1')
app.commandLine.appendSwitch('force-device-scale-factor', '1')

[s9ik]

截图清晰度修复（提高捕获像素）方案

背景与问题

• 4K 及以上分辨率、系统缩放（DPI）≥150% 场景下，截图中文字发糊，细节丢失。
• 根因：Electron desktopCapturer.getSources 的 thumbnailSize 固定 1920×1080，导致捕获阶段即被强制下采样；后续即使在处理端放大也无法恢复细节。
• 补充：后端 Web 管理的“最大图片尺寸（4096）/ 批处理大小（20）”属于处理阶段参数，不会提升前端捕获到的像素，只会在过大时再次下采样。

现状代码定位

• 保存截图（前端主进程）：frontend/src/main/services/ScreenshotService.ts
  • 通过 source.thumbnail.toPNG() 持久化保存，像素由上游 thumbnailSize 决定。
• 生成缩略图尺寸（关键）：frontend/src/main/utils/get-capture-sources.ts
  • window/screen 分支均为 thumbnailSize: { width: 1920, height: 1080 }（导致清晰度不足）。
  • 列表页小预览 thumbnailSize: { width: 256, height: 144 }（非关键，可保持小尺寸控资源）。
• 处理阶段下采样上限（后端）：config/config.yaml
  • processing.screenshot_processor.max_image_size: 1920（单位：像素最大边）。

解决思路

方案 A（快速可落地）

• 将保存截图链路中 desktopCapturer.getSources 的 thumbnailSize 从 1920×1080 提升到 4096×2304（16:9）。
• 将处理阶段的 max_image_size 从 1920 提升到 4096，避免进一步缩小。
• 列表小预览保持 256×144（或略提到 512×288），不影响性能。

优点：改动小、见效快；风险低。

方案 B（推荐，DPI 自适应）

• 按显示器物理分辨率 × scaleFactor 动态设置 thumbnailSize，并设置上限（推荐 4096 或 8192）。
• 伪代码：

import { screen } from 'electron'
const MAX_W = 4096, MAX_H = 4096
function getTargetSize() {
  const d = screen.getPrimaryDisplay()
  const scale = d.scaleFactor || 1
  const w = Math.min(Math.round(d.size.width * scale), MAX_W)
  const h = Math.min(Math.round(d.size.height * scale), MAX_H)
  return { width: w, height: h }
}
// desktopCapturer.getSources({ thumbnailSize: getTargetSize() })

• Window/Screen 分支均使用动态尺寸；列表页预览仍用小尺寸。

优点：适配任意分辨率与 DPI，4K/5K/8K+HiDPI 下都能稳定清晰。

变更点清单

• 前端（Electron 主进程）：

  • 文件：frontend/src/main/utils/get-capture-sources.ts
  • 修改：
    • Window/Screen 两处 desktopCapturer.getSources 的 thumbnailSize
    • 方案 A：写死为 4096×2304
    • 方案 B：改为按 screen.getPrimaryDisplay().size * scaleFactor 动态计算，上限 4096/8192
  • 列表页小预览可保持 256×144（或 512×288）

• 后端处理：

  • 文件：config/config.yaml
  • 修改：processing.screenshot_processor.max_image_size: 4096（单位：像素最大边）

兼容性与风险

• 捕获像素提高会增加：
  • PNG 文件大小与磁盘占用
  • I/O 写入与处理层下游成本
• 建议：
  • 仅提升“保存截图链路”的尺寸；列表页预览仍小图，控制 UI 资源与交互性能
  • 先设上限 4096，再按设备与体验评估是否提高至 8192

验收与回归

• 测试矩阵：
  • 分辨率：1080p / 1440p / 2160p（4K）/ 5K
  • DPI：100% / 125% / 150% / 200%
  • 内容：系统字体、IDE 等细文本、UI 线条
• 目标：文字边缘无明显模糊，放大 150% 仍可清晰辨认，处理端不再出现额外压缩导致的糊化。

备选增强

• 对 Screen 类捕获优先尝试 screenshot-desktop 获取原生分辨率，失败再回退 desktopCapturer。
• 在设置页新增“截图清晰度”开关/档位（高/中/低）绑定上限与质量参数。

上线计划

1. 先落地方案 A，验证清晰度与体积的平衡。
2. 收集真实设备（4K+HiDPI）反馈。
3. 切换为方案 B（DPI 自适应）并加“上限像素”可配置。

说明

• 本次修复属于“捕获前端链路”的参数调整，不涉及后端框架或系统层改动。
• 处理端 max_image_size 只用于限制过大图片的最大边，单位为像素；非 KB/MB。

[qin-ctx]

@s9ik 可以提一个pr呀，不过图片像素过大使用的token也会更多

[haoping1]

遇到同样的问题，截图模糊，识别不准确

[haoping1]

截图清晰度修复（提高捕获像素）方案

背景与问题

• 4K 及以上分辨率、系统缩放（DPI）≥150% 场景下，截图中文字发糊，细节丢失。
• 根因：Electron desktopCapturer.getSources 的 thumbnailSize 固定 1920×1080，导致捕获阶段即被强制下采样；后续即使在处理端放大也无法恢复细节。
• 补充：后端 Web 管理的“最大图片尺寸（4096）/ 批处理大小（20）”属于处理阶段参数，不会提升前端捕获到的像素，只会在过大时再次下采样。

现状代码定位

• 保存截图（前端主进程）：frontend/src/main/services/ScreenshotService.ts

  • 通过 source.thumbnail.toPNG() 持久化保存，像素由上游 thumbnailSize 决定。

• 生成缩略图尺寸（关键）：frontend/src/main/utils/get-capture-sources.ts

  • window/screen 分支均为 thumbnailSize: { width: 1920, height: 1080 }（导致清晰度不足）。
  • 列表页小预览 thumbnailSize: { width: 256, height: 144 }（非关键，可保持小尺寸控资源）。

• 处理阶段下采样上限（后端）：config/config.yaml

  • processing.screenshot_processor.max_image_size: 1920（单位：像素最大边）。

解决思路

方案 A（快速可落地）

• 将保存截图链路中 desktopCapturer.getSources 的 thumbnailSize 从 1920×1080 提升到 4096×2304（16:9）。
• 将处理阶段的 max_image_size 从 1920 提升到 4096，避免进一步缩小。
• 列表小预览保持 256×144（或略提到 512×288），不影响性能。

优点：改动小、见效快；风险低。

方案 B（推荐，DPI 自适应）

• 按显示器物理分辨率 × scaleFactor 动态设置 thumbnailSize，并设置上限（推荐 4096 或 8192）。
• 伪代码：

import { screen } from 'electron' const MAX_W = 4096, MAX_H = 4096 function getTargetSize() { const d = screen.getPrimaryDisplay() const scale = d.scaleFactor || 1 const w = Math.min(Math.round(d.size.width * scale), MAX_W) const h = Math.min(Math.round(d.size.height * scale), MAX_H) return { width: w, height: h } } // desktopCapturer.getSources({ thumbnailSize: getTargetSize() })

• Window/Screen 分支均使用动态尺寸；列表页预览仍用小尺寸。

优点：适配任意分辨率与 DPI，4K/5K/8K+HiDPI 下都能稳定清晰。

变更点清单

• 前端（Electron 主进程）：

  • 文件：frontend/src/main/utils/get-capture-sources.ts

  • 修改：

    • Window/Screen 两处 desktopCapturer.getSources 的 thumbnailSize
    • 方案 A：写死为 4096×2304
    • 方案 B：改为按 screen.getPrimaryDisplay().size * scaleFactor 动态计算，上限 4096/8192

  • 列表页小预览可保持 256×144（或 512×288）

• 后端处理：

  • 文件：config/config.yaml
  • 修改：processing.screenshot_processor.max_image_size: 4096（单位：像素最大边）

兼容性与风险

• 捕获像素提高会增加：

  • PNG 文件大小与磁盘占用
  • I/O 写入与处理层下游成本

• 建议：

  • 仅提升“保存截图链路”的尺寸；列表页预览仍小图，控制 UI 资源与交互性能
  • 先设上限 4096，再按设备与体验评估是否提高至 8192

验收与回归

• 测试矩阵：

  • 分辨率：1080p / 1440p / 2160p（4K）/ 5K
  • DPI：100% / 125% / 150% / 200%
  • 内容：系统字体、IDE 等细文本、UI 线条

• 目标：文字边缘无明显模糊，放大 150% 仍可清晰辨认，处理端不再出现额外压缩导致的糊化。

备选增强

• 对 Screen 类捕获优先尝试 screenshot-desktop 获取原生分辨率，失败再回退 desktopCapturer。
• 在设置页新增“截图清晰度”开关/档位（高/中/低）绑定上限与质量参数。

上线计划

1. 先落地方案 A，验证清晰度与体积的平衡。
2. 收集真实设备（4K+HiDPI）反馈。
3. 切换为方案 B（DPI 自适应）并加“上限像素”可配置。

说明

• 本次修复属于“捕获前端链路”的参数调整，不涉及后端框架或系统层改动。
• 处理端 max_image_size 只用于限制过大图片的最大边，单位为像素；非 KB/MB。

本人动手能力比较差，大佬能发我一个你修改好以后的版本吗

[s9ik]

遇到同样的问题，截图模糊，识别不准确

MineContext_清晰度修复工具包.zip你试试

[s9ik]

@haoping1