lifthrasiir / j40 Goto Github PK

Test image: https://stsci-opo.org/STScI-01GA76Q01D09HFEV174SVMQDMV.png

$ time ./dj40 w.fjxl 
14560x8418 frame read and discarded.

real    0m16,854s
user    0m16,325s
sys     0m0,549s

8 MPx/s, PNG decoding speed on the same CPU is 50 MPx/s.
Too slow for just a prefix_codes + simple_avg_predictor + color_conversion.

dj40.c
line 5:
#include "j40.h"
#include "j40.h"

If a block comment /* */ was used instead of many one line // comments around the example program, then it could be copy pasted easier, with no need to remove all the // by hand or using an editor (many don't offer multi-line comment/uncomment).

Might be helpful.

I built cjxl from the official https://github.com/libjxl/libjxl repo. I then made a bricks-color.jxl file (attached, with a fake .png file extension to satisfy the GitHub upload UI).

$ build/tools/cjxl bricks-color.png bricks-color.jxl
JPEG XL encoder v0.8.0 506714ed [AVX2,SSE4,SSSE3,Unknown]
Read 160x120 image, 33928 bytes, 18.7 MP/s
Encoding [VarDCT, d1.000, effort: 7], 
Compressed to 7287 bytes (3.036 bpp).
160 x 120, 0.76 MP/s [0.76, 0.76], 1 reps, 8 threads.

Trying to decode that with j40 hits an error:

$ ./dj40 bricks-color.jxl out.png
Error: Decoding failed (rnge) during j40_next_frame

• bricks-color.png
  

• bricks-color.really-a-jxl.but-github-only-uploads.png
  

Color management in JPEG XL is a complicated story. Ideally it's the best possible design: every JPEG XL codestream has a defined color profile (either ICC profile or abbreviated color space parameters) and it should be converted to the display color space. Unfortunately the status quo is not that ideal.

• ICCv2 and v4 are yet another 100-plus-page standards.
• The full conversion process is a many-to-many relation; not only the display color space is defined, but the image color space can vary.
• There is no public domain color management system (CMS) to my knowledge.
• There is no single-file CMS to my knowledge either. The closest is probably skcms, a part of Skia, which consists of two source files and two header files, and it is already ~4000 lines of C++.

As such, I don't think J40 will ever implement the full ICC profile by itself (at least in C). This is also the case in libjxl, where either skcms or Little CMS 2 can be used, but it is a bit baffling to require an external library to implement the full format. Any other ideas are welcomed.

Anyway, this decision leads to the following subtasks:

• Fully implement the ICC codec
• Handle abbreviated color space parameters
• Implement and expose API functions for external CMSes (e.g. J40_USE_LCMS2)

As I noted in the orange site, it is a long-term goal to produce a parallel Rust version of J40. There are many unanswered questions before starting this process, however.

• Should we cooperate with the image-rs organization? Or should we let image-rs to use J40 as a dependency?
• J40 needs to use many image buffers; should we use ImageBuffer for this purpose, or make our own? (This is important when J40 is going to be used as a dependency!)
• Rust version can probably afford the default CMS as opposed to the C version (#9), but which one to use?
• The current design of J40 involves many layered subsystems---input source, backing buffer, container and codestream-offset-to-file-offset mapping, logical buffer, bit reader---and they may not translate clearly to Rust.
• In the C version the error is primarily communicated with a shared state (j40__st), which would be a bad design in Rust. But this allows for a delayed error checking, which may be crucial for some cases.
• The top-level of decoding process involves a coroutine (that would be a part of j40_advance in the future), which is a good abuse of C macros. I'm not very sure this can be ever translated to Rust (should I use something like genawaiter?).

This is currently an empty macro (and will remain so by default), but probably should be something else if it is to be used as, for example, a dynamically linked library.

Now that Chromium has dropped support for JPEG XL, the WebAssembly decoder is needed. Could you please provide a WASM version of J40? Thanks!

Thanks for this project.

Reading the README it is not clear to me whether progressive JPEG images are supported. Could you please clarify that?

(I'd like to try this lib it in a ESP32 with limited resources, where adding many dependencies is problematic).

libjxl has a battery of conformance tests, which is expected to become ISO/IEC 18181-3 in the future. They are coarser-grained tests and not suitable for detailed testing or estimating the actual progress, but they represent a good milestone so will be tracked here.

• alpha_nonpremultiplied
• alpha_premultiplied
• alpha_triangle
• animation_icos4D
• animation_newtons_cradle
• animation_spline
• bench_oriented_BRG
• bicycles
• bike
• blendmodes
• cafe
• cmyk_layers
• delta_palette
  • Decodes but incorrect
• grayscale
  • Fails before TODO is reached
• grayscale_jpeg
  • Fails before TODO is reached
• grayscale_public_university
• lossless_pfm
• lz77_flower
  • Decodes and almost correct but has a subtle intensity difference
• noise
• opsin_inverse
  • Decodes but incorrect
• patches
• patches_lossless
• progressive
• spot
• sunset_logo
• upsampling