Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dicom 1.2.840.10008.1.2.4.70 not supported? #638

Closed
blazespinnaker opened this issue Dec 16, 2022 · 2 comments
Closed

Dicom 1.2.840.10008.1.2.4.70 not supported? #638

blazespinnaker opened this issue Dec 16, 2022 · 2 comments
Assignees

Comments

@blazespinnaker
Copy link

blazespinnaker commented Dec 16, 2022

Have you searched the existing issues (both open and closed) in the libjpeg-turbo issue tracker to ensure that this bug report is not a duplicate?

Yes

Does this bug report describe one of the two known and unsolvable issues with the JPEG format?
No

Clear and concise description of the bug:
Getting error when decoding dicom jpg with transfer syntax 1.2.840.10008.1.2.4.70

Unsupported JPEG process: SOF type 0xc3

Steps to reproduce the bug (using only libjpeg-turbo):

This works:

from libjpeg import decode
arr = decode('/kaggle/working/1_2_840_10008_1_2_4_70.jpg')
import matplotlib.pyplot as plt
plt.imshow(arr)
plt.show() 

This does not:

jpeg = TurboJPEG()
in_file = open('/kaggle/working/1_2_840_10008_1_2_4_70.jpg', 'rb')
arr = jpeg.decode(in_file.read())

OSError: Unsupported JPEG process: SOF type 0xc3

Image(s) needed in order to reproduce the bug (if applicable):

https://github.com/blazespinnaker/klibs/blob/main/1_2_840_10008_1_2_4_70.jpg

Expected behavior:

Expected turbojpeg to decode the file

Observed behavior:

Error

Platform(s) (compiler version, operating system version, CPU) on which the bug was observed:

Linux Ubuntu

libjpeg-turbo release(s), commit(s), or branch(es) in which the bug was observed (always test the tip of the main branch or the latest stable pre-release to verify that the bug hasn't already been fixed):

Using this library https://github.com/lilohuang/PyTurboJPEG

If the bug is a regression, the specific commit that introduced the regression (use git bisect to determine this):
I don't think it's a regresssion

Additional information:

@dcommander
Copy link
Member

Duplicate of #402. Not a bug. This is simply that, historically, libjpeg and its derivatives never supported lossless JPEG. I am in the process of implementing that support under contract.

@dcommander dcommander added duplicate and removed bug labels Dec 16, 2022
This was referenced Dec 16, 2022
@dcommander
Copy link
Member

8-bit, 12-bit, and 16-bit lossless JPEG is fully implemented in both the libjpeg and TurboJPEG APIs in the dev branch, and the beta release containing the feature will land early next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants