libjpeg 和 .Net jpeg 编解码器在单色数据上真的有很大差异吗？
我处理大量单色图像数据，今天早上我注意到 libjpeg 和 .Net jpeg 编解码器处理单色数据的方式似乎存在显着差异。看起来使用 libjpeg 以任何质量设置保存并使用默认 .Net jpeg 编解码器打开的单色图像实际上仅加载 16 种不同的灰色阴影，并且所有中间阴影都呈现为点画。
这是由 libjpeg 保存并由 .net 加载的平滑渐变的直方图
直方图应该有已经完全水平了。
这是渐变的（放大）示例（它应该是完美平滑的过渡） 
这应该是从左侧的灰色 85 到右侧的灰色 136 的平滑过渡，但只有 4 个色调灰色实际上是为了进行这种过渡而渲染的。
我的问题是我疯了吗？如果不是的话，这种编解码器差异会持续到什么程度？如果您在不同的程序中使用这两个库，是否有一个好的解决方法？
我并不是责怪任何一个编解码器，只是指出似乎存在的差异。我注意到我知道是使用 libjpeg 创建的图像，假设这是质量设置问题，尝试使用 faststone 图像缩放器创建测试图像并得到相同的结果，尝试使用 irfanview 并再次得到相同的结果。由于这两个程序都必须使用一些 jpeg 库，我倾向于假设它们也使用 libjpeg 并且存在真正的编解码器冲突。
在加载方面，我使用自己的 .net 代码和 Paint.net 加载图像时遇到了相同的结果。
最后，这是一个正常分辨率的示例，您可以下载并亲自尝试。在某些程序中加载它会给你一个很好的渐变（例如你的浏览器），但是用你自己的.Net代码加载它，或者Paint.Net会给你一个抖动渐变，就像上面只使用16个灰色阴影渲染的那样。
有谁了解更多关于此问题的信息，它的进展如何以及可能有什么好的解决方法？
I work with a lot of monochrome image data and this morning I noticed that there appears to be a significant difference between the way libjpeg and the .Net jpeg codec handle monochrome data. It appears that a monochrome image saved at ANY quality setting using libjpeg and opened using the default .Net jpeg codec actually only loads with 16 different shades of gray and all intermediate shades are rendered as stippled.
Here is the histogram of a smooth gradient saved by libjpeg and loaded by .net
The histogram should have been perfectly level.
And here is a (zoomed in) sample of what that gradient looks like (it should a be perfectly smooth transition)
This should be a smooth transition from gray 85 on the left to gray 136 on the right but only 4 shades of gray are actually rendered to make that transition.
My question is am I crazy and if not just how far does this codec discrepancy go? Is there a good workaround if you are using both libraries in different programs?
I am not blaming either codec, just pointing out what appears to be a discrepancy. I noticed this with images I knew were created using libjpeg, assumed it was a quality setting issue, tried using faststone image resizer to create test images and got the same result, tried using irfanview and got the same result again. As both of those programs must use some jpeg library I tend to assume they are also using libjpeg and there is a genuine codec conflict.
On the loading side I have run into the same result loading images with both my own .net code and using Paint.net.
Finally, here is a sample at normal resolution so you can download it and try it yourself. Loading it in some programs will give you a nice gradient (e.g. your browser) but loading it with your own .Net code, or Paint.Net will give you a dithered gradient like the above rendered using only 16 shades of gray.
Does anyone know more about this, how far it goes and what good workarounds might be?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我可以通过在 Windows 7 捆绑的 Paint 版本中打开示例图像来重现您的症状。分析该文件表明它是有效的 JPEG，并且让它在浏览器中正确显示也证实了这一点。看来微软真的搞砸了。它已作为错误提交：
https://connect.microsoft.com/VisualStudio/feedback/details/597657/grayscale-jpeg-image-read-as-format8bppindexed-but-quantized-as-format4bppindexed#details
<一个href="http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/9132e2bd-23cc-4e5a-a783-1fa4abe11624/" rel="nofollow">http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/9132e2bd-23cc-4e5a-a783-1fa4abe11624/
解决方法是创建 JPEG作为全彩色图像，但仅将灰度像素值放入其中。
I am able to reproduce your symptoms by opening your sample image in the version of Paint bundled with Windows 7. Analyzing the file shows it to be a valid JPEG, and having it show up properly in the browser confirms this. It looks like Microsoft really messed up bad. It has already been submitted as a bug:
https://connect.microsoft.com/VisualStudio/feedback/details/597657/grayscale-jpeg-image-read-as-format8bppindexed-but-quantized-as-format4bppindexed#details
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/9132e2bd-23cc-4e5a-a783-1fa4abe11624/
The workaround would be to create your JPEG as a full color image, but only put grayscale pixel values into it.