C#:使用 Silverlight FJCore 库以 12 位精度解码 JPEG 图像?

发布于 2024-12-06 05:35:33 字数 856 浏览 0 评论 0原文

在我的 C# Silverlight 应用程序中,我尝试使用 FJCore< 以压缩的 JPEG 传输语法解码 DICOM 图像/a> 类库。

DICOM 图像通常以 12 位精度压缩。当尝试使用原始 FJCore 源代码解码此类图像时,我收到一个异常,提示“不支持的编解码器类型”,因为在原始 FJCore 实现中,只有 SOF0(基线 DCT)和 SOF2(渐进 DCT)起始帧标记是支持。如果我更改实现以接受 SOF1 标记(扩展顺序 DCT)并以与 SOF0 帧相同的方式处理 SOF1 帧,则图像将被解码,但仅考虑 8 位。

使用修改后的 FJCore 库解码后,典型的 12 位精度图像现在看起来像这样:

12 位精度 JPEG 图像编码为 8 -bit precision by FJCore

理想情况下,图像应如下所示:

12 位精度 JPEG 图像编码为完整12位精度

据我从FJCore实现中得知,图像精度记录在JpegFrame类中,但从未使用过。最初的 FJCore 实现似乎只完全支持 8 位精度的灰度图像。

我计划“不畏艰险”,尝试自己扩展 FJCore 以支持灰度图像的 12 位精度。但在此之前,我想我应该在 StackOverflow 中提出问题,看看以前是否有人遇到并解决过这个问题?在这种情况下,我会很高兴了解您如何解决问题。

非常感谢!
安德斯@Cureos

In my C# Silverlight application, I am trying to decode DICOM images in compressed JPEG transfer syntax, using the FJCore class library.

The DICOM images are normally compressed with 12-bit precision. When trying to decode such an image using the original FJCore source code, I get an exception saying "Unsupported codec type", because in the original FJCore implementation only SOF0 (Baseline DCT) and SOF2 (Progressive DCT) Start-of-Frame markers are supported. If I change the implementation to also accept the SOF1 marker (Extended Sequential DCT) and treat SOF1 frames the same way as SOF0 frames, the images are decoded, but only 8 bits are accounted for.

A typical 12-bit precision image now looks like this after decoding with the modified FJCore library:

12-bit precision JPEG image encoded to 8-bit precision by FJCore

Ideally, the image should look like this:

12-bit precision JPEG image encoded to full 12-bit precision

As far as I have been able to tell from the FJCore implementation, the image precision is recorded in the JpegFrame class, but it is never used. The original FJCore implementation seems to only fully support grayscale images with 8 bit precision.

I am planning to "take the bull by the horns" and try to extend FJCore myself to support 12-bit precision for grayscale images. But before I do, I thought I should pose the question here in StackOverflow to see if anyone has encountered and solved this problem before? In that case, I would be very happy to learn how you solved the problem.

Many thanks in advance!
Anders @ Cureos

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

眼藏柔 2024-12-13 05:35:33

我刚刚更新了我自己的 JPEG 解码器来处理扩展模式,我需要更改的是逆 DCT。在更改代码之前,输出看起来与上面的示例图像类似。我一直存储来自熵解码的 16 位系数值,但我的 DCT 计算在进行数学计算时使用 16 位整数来保存临时值,从而破坏了较大的值。我更改了 DCT 代码以使用 32 位整数进行计算,这解决了问题。

I just updated my own JPEG decoder to handle the extended mode and what I needed to change was my inverse DCT. Before changing the code, the output looked similar to your sample image above. I have always stored 16-bit coefficient values from the entropy decode, but my DCT calculation was corrupting the larger values by using 16-bit integers to hold temporary values while doing the math. I changed the DCT code to use 32-bit integers for the calculations and that solved the problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文