我正在尝试这样做:Facebook Preview Photos。
据我了解,他们正在使用小型jpegs以及所有jpeg都有相似的标题"在完整图像加载之前向用户提供非常小的初始图像预览的信息。
我想用建议的工作流程做类似的事情:
1)。利用data
和Base64将JPEG标头存储在每个<image>
元素中。
2)。加载剩余的小图片作为附加到Base64标题字符串。
3)。使用JavaScript onloads加载完整图像。
供参考:JPEG Specs
我有一个十六进制编辑器,我剥离了EXIF数据,保存了标题,现在有一个不会显示的图像。我相信,当我剥离EXIF数据时,我花了太多钱。我使用 this 来决定数据的剪切位置,即从0xFF, 0xC0
到0xFF, 0xDA
的所有内容,我认为这些内容太多了。在我输出图像扫描之前,我正在寻找关于如何获得最基本的可渲染标题的权威答案。也就是说,在转换为Base64之前,我可以从标题中删除多少十六进制数据?
我们查看了唯一的标准JPEG标题的其余部分 其他表可能会随着不同的图像和选项而变化 哈夫曼表。
但是在这个阅读中我并不清楚这是否意味着他们保留了标题的其余部分,或者他们只是操纵了这个标题。
答案 0 :(得分:0)
听起来他们正在使用相同的DHT和DQT标记来压缩所有图像。他们的应用知道这些标记的内容。
当他们传输图像时,他们会删除除SOF和SOS标记之外的所有内容。
然后,他们的应用程序客户端组装SOI标记,应用程序DHT和DQT标记,传输的SOF和SOS标记以及EOS标记。然后它将该流发送到客户端的解码器。
据我了解,他们正在使用小型jpegs以及所有jpeg都有相似的标题&#34;在完整图像加载之前向用户提供非常小的初始图像预览的信息。
NO。他们正在以标记相同的方式压缩图像。