jpg error: unknown JPEG marker FFC3

[ivmartel]

Are there any plans to add support for lossless JPEG decoding in jpg.js?

[Snuffleupagus]

There are no concrete plans, that I'm aware of, since that marker doesn't seem to be commonly used (or maybe not used at all?) in JPEG images embedded in PDF file. But PRs are always welcome, though!

Also, would you be able to provide a link to a PDF file that actually includes that kind of JPEG image?

[ivmartel]

Sorry, I don't have a PDF, I'm trying to use jpg.js to decode jpeg embedded in a DICOM file (standard for medical images). I'm already using jpx.js for JPEG2000 (ivmartel/dwv#131).

[ivmartel]

The JPEGLosslessDecoderJS library does the job. Thanks!

[photopea]

Hi, could you please reopen this issue and implement the lossless standard? The format is extremely simple, I think it would be like 50 more lines of code.

I am not using PDF.js, but just the JPEG decoder from it. I think it is better to have everything in one library, than using several libraries. I would do it myself, but I am not familiar with this implementation and with JPEG in general, so it would take me 10x more time, than the original author.

[yurydelendik]

Hi, could you please reopen this issue and implement the lossless standard?

@photopea re-opening the issue will not guarantee that a contributor will start working on it or submit a solution.

I think it would be like 50 more lines of code.

Looks like it's easy patch. You are welcome to submit a pull request with working code. We will review the proposed solution.

[yurydelendik]

so it would take me 10x more time, than the original author.

it's better than nobody is working on it at all.

[photopea]

Is it possible to get in touch with the original author? I want to decode JPGs, which have 12 bits per sample. I would like to know, if this decoder is prepared for such input, or if everything is built just for 8 bits per sample.

[yurydelendik]

Is it possible to get in touch with the original author?

https://github.com/mozilla/pdf.js/blob/master/src/core/jpg.js belongs now to the PDF.js project and it was modified by multiple contributors, to provide optimal speed for the project.

I want to decode JPGs, which have 12 bits per sample.

By reading the code, it's possible to do so, however it might loose all performance benefits we invested into the code. If PDF.js project will not loose the performance, we will be glad to access processing 0f 12bit images.

At this moment, and if licensing permits, it will easier to compile existing C/C++ code into asm.js/wasm and use it instead.

[photopea]

The lossless JPEG decoding is implemented in this tiny lib: https://github.com/rawdevjs/lossless-jpeg-decoder . I think that 80% of their code is already present in our jpg.js (like Huffman decoding). So we just need somebody to connect the pieces. I am not familiar enough with JPEG and this implementation to do it :(

Right now, I am trying to catch an error in jpg.js and then I use this library. It is an ugly solution.

[timvandermeij]

Reopening as a feature request in case someone wants to help out with this. I would like to emphasize that we do need some example PDF files to be able to verify this, so if you have any, please attach them to this issue.

[photopea]

Thanks. Lossless JPGs have been "ignored" by public after publishing the JPG standard. Almost no program can open them. You will probably never find a PDF with such JPGs.

I am talking about jpg.js (a part of PDF.js), which is currently the best Javascript JPEG decoder in the world and has much bigger potential, than just being used in a PDF viewer. I am using jpg.js to parse lossless JPEG-encoded data inside DNG (digital negative) files. Here is a sample JPG file (renamed to TXT), that I need to parse (1 sample per pixel, 16 bits per sample).
image.txt

[Snuffleupagus]

As already mentioned elsewhere, the implementation in src/core/jpg.js only support 8-bit JPEG images since that's the only thing that matters for PDF files; note also #6128 (comment) here.

Hence the example provided in #6128 (comment) doesn't seem entirely useful, given that it's apparently a 16-bit image, and consequently I'd suggest re-closing this issue since it's not really actionable as-is.