将图像直接发送到 Epson 投影仪，无法解码 jpeg 图像
Sending image directly to Epson Projector, trouble decoding jpeg image
我有一台没有 linux driver 的 Epson Ex5220，我一直在尝试通过 wifi 进行通信。我可以使用 driver 连接并发送通过 Windows 机器的数据包跟踪捕获的图像，但无法创建可接受的图像。这是问题所在：
在数据发送中，发送了一个 jpeg 图像，像这样附加了 header。
00:00:00:01:00:00:00:00:02:70:01:a0:00:00:00:07:90:80:85:00
00:00:00:04 - Number of jpeg images being sent (only the first header)
00:00 - X offset
00:00 - Y offset
02:70 - Width of Jpeg image (624 in this case)
01:a0 - Height of Jpeg image (416 in this case)
00:00:00:07:90 - Unknown (I believe it's a version number perhaps)
80:85:00 - (What I'm after) Some count of data units?
header 之后是一张普通的 jpeg 图片。如果我去掉 header，我可以查看图像。这是部分捕获的屏幕截图，突出显示了 3 个字节：
我发现将最后三个字节设置为 80:85:00 似乎是一个基线。少了一点，图像就无法投射。另外，我可以发送到投影仪的最小图像尺寸是 3w x 1h，这与下面显示的前两张图像相关。
这里有一些例子：
1a - 全白 (RGB565) 图像 1024x768 - 文件大小 12915 - 4 个块
2a - 彩色 (RGB565) 图像 1024x768 - 文件大小 58577 - 只有 3 个块
然后我将 3 个字节更改为 00:b5:80（将中间的字节增加 0x30）
1b - 全白 (RGB565) 图像 1024x768 - 文件大小 12915 - 22 整行和 4 个块。
2b - 彩色 (RGB565) 图像 1024x768 - 文件大小 58577 - 7 行和 22 个块。
看来这3个字节跟数据单位有关系。我已经阅读了很多关于 jpeg 的东西并且仍在消化其中的大部分内容，但我想如果我知道计算数据单位需要什么，我会找到我的神秘 3 个字节。
附加信息：
投影机只支持在数据发送中使用RGB565 jpeg图像。
您似乎误解了 SOS 标记的工作原理。以下是您在其中一个示例中显示的字节：
SOS = 00 0C 03 01 00 02 11 03 11 00 3F 00 F9 FE
这错误地将两个字节的压缩数据 (F9 FE) 包含在 SOS 中。 12（00 0C）的长度包括了2个长度字节本身，所以这个标记实际上只有10个字节的数据。
F9 FE 之前的 00 字节是 "successive approximation" 位字段，用于渐进式 JPEG 图像。它实际上是一对4位字段。
您看到的图像之间变化的字节实际上是前 2 个压缩数据字节（它为第一个 MCU 编码 DC 值）。
(代表OP发表).
我能够解决这个问题，但我想知道为什么会这样。这是最后 3 个字节的公式：
int iSize = bImage.length;
baHeader[17] = (byte) ((iSize) | 0x80);
baHeader[18] = (byte) ((iSize >> 7) | 0x80);
baHeader[19] = (byte) ((iSize >> 14));
我受够了弄乱它，只看了几张图片，记下了所有文件大小和魔法字节，将所有内容都转换为二进制，并反复进行 ANDing ORing 位移位运算，直到我强制执行一个有效的形式。我想知道这是否与计算 jpeg 数据单元有关。我仍在研究 Jpeg，但这不是简单的东西！
我有一台没有 linux driver 的 Epson Ex5220，我一直在尝试通过 wifi 进行通信。我可以使用 driver 连接并发送通过 Windows 机器的数据包跟踪捕获的图像，但无法创建可接受的图像。这是问题所在：
在数据发送中，发送了一个 jpeg 图像，像这样附加了 header。
00:00:00:01:00:00:00:00:02:70:01:a0:00:00:00:07:90:80:85:00
00:00:00:04 - Number of jpeg images being sent (only the first header)
00:00 - X offset
00:00 - Y offset
02:70 - Width of Jpeg image (624 in this case)
01:a0 - Height of Jpeg image (416 in this case)
00:00:00:07:90 - Unknown (I believe it's a version number perhaps)
80:85:00 - (What I'm after) Some count of data units?
header 之后是一张普通的 jpeg 图片。如果我去掉 header，我可以查看图像。这是部分捕获的屏幕截图，突出显示了 3 个字节：
我发现将最后三个字节设置为 80:85:00 似乎是一个基线。少了一点，图像就无法投射。另外，我可以发送到投影仪的最小图像尺寸是 3w x 1h，这与下面显示的前两张图像相关。
这里有一些例子：
1a - 全白 (RGB565) 图像 1024x768 - 文件大小 12915 - 4 个块
2a - 彩色 (RGB565) 图像 1024x768 - 文件大小 58577 - 只有 3 个块
然后我将 3 个字节更改为 00:b5:80（将中间的字节增加 0x30）
1b - 全白 (RGB565) 图像 1024x768 - 文件大小 12915 - 22 整行和 4 个块。
2b - 彩色 (RGB565) 图像 1024x768 - 文件大小 58577 - 7 行和 22 个块。
看来这3个字节跟数据单位有关系。我已经阅读了很多关于 jpeg 的东西并且仍在消化其中的大部分内容，但我想如果我知道计算数据单位需要什么，我会找到我的神秘 3 个字节。
附加信息：
投影机只支持在数据发送中使用RGB565 jpeg图像。
您似乎误解了 SOS 标记的工作原理。以下是您在其中一个示例中显示的字节：
SOS = 00 0C 03 01 00 02 11 03 11 00 3F 00 F9 FE
这错误地将两个字节的压缩数据 (F9 FE) 包含在 SOS 中。 12（00 0C）的长度包括了2个长度字节本身，所以这个标记实际上只有10个字节的数据。
F9 FE 之前的 00 字节是 "successive approximation" 位字段，用于渐进式 JPEG 图像。它实际上是一对4位字段。
您看到的图像之间变化的字节实际上是前 2 个压缩数据字节（它为第一个 MCU 编码 DC 值）。
(代表OP发表).
我能够解决这个问题，但我想知道为什么会这样。这是最后 3 个字节的公式：
int iSize = bImage.length;
baHeader[17] = (byte) ((iSize) | 0x80);
baHeader[18] = (byte) ((iSize >> 7) | 0x80);
baHeader[19] = (byte) ((iSize >> 14));
我受够了弄乱它，只看了几张图片，记下了所有文件大小和魔法字节，将所有内容都转换为二进制，并反复进行 ANDing ORing 位移位运算，直到我强制执行一个有效的形式。我想知道这是否与计算 jpeg 数据单元有关。我仍在研究 Jpeg，但这不是简单的东西！