RD-OPT enhancement

[chuck2004]

I know it's a hard job, could you implement the RD-OPT algorithm in jpeg-turbo?

Would any company be able to pay for your work on this?
What amount would you price implementing this feature at?
A request for you guys to write to ceo's of companies that use jpeg-turbo to support the idea with donations etc.

Last year, I found the source code and papers in .pdf regarding RD-OPT and QCLIC at: https://lost-contact.mit.edu/afs/cs.wisc.edu/p/qclic/. It looks like the site is taken down for good. I attach copies of the files and the most important pdfs in the links below.

Overview of RD-OPT

Source code
List of papers concerning RD-OPT/QCLIC

[dcommander]

Referring to my own comments under mozilla/mozjpeg#182, whether or not such an enhancement could be considered for libjpeg-turbo would depend on several things:

1. Can the feature be implemented without severely disrupting the libjpeg API or architecture?
2. Does the performance of the feature fall within the scope of the performance of other libjpeg-turbo modes of operation? (If RD-OPT is as slow as other historic efforts at automatic quantization table generation, such as DCTune, then it doesn't make sense for libjpeg-turbo. However, it may make sense for mozjpeg, which is geared toward maximum compression ratio regardless of performance.)
3. Does a patch exist to implement the feature against libjpeg, and does the patch have a "clean" copyright? (IOW, are all modifications clearly indicated in the copyright headers, and did the author have clear authority to release the modifications into the open source.) Otherwise, the reality is that I don't have the cycles to implement the feature from scratch, because this is only one of three open source projects that I maintain.
4. Even with a patch, it will take some effort to integrate the feature, and 100% of my labor toward that effort will have to be funded. (This feature isn't strategically important enough to use any libjpeg-turbo General Fund money for it, and that fund is exhausted at the moment anyhow.)

Generally speaking, corporate funding for libjpeg-turbo happens at much lower levels than the CEO, because such funding will generally come out of an organization's R&D budget. CEOs of big corporations generally won't be involved with software development on a deep enough technical level to understand the pros and cons of specific JPEG features.

The best I can do right now is flag this issue with "funding needed" and "help wanted" and hope that other parties will step forward to lay the groundwork, as described above. Once a patch exists, then I can review it and get an idea of whether it's something that can be integrated and, if so, how much time it would take.

[jeffman]

RDOPT is no longer state of the art; I'll plug OptD-HDQ as well from the other thread, which outperforms RDOPT at a fraction of the complexity. See "Quantization Table Design Revisited for
Image/Video Coding" by Yang et al.

[chuck2004]

Papers:

· Quantization Table Design Revisited for Image/Video Coding
· An Efficient DCT-Based Image Compression System Based on Laplacian Transparent Composite Model
· An Efficient DCT-Based Image Compression System Based on Laplacian Transparent Composite Model, detailed test results
· Patent

[dcommander]

Can someone please summarize the tradeoffs? The libjpeg-turbo General Fund for this year is exhausted, so I don't have time to dig into any pure research. I was interested in RD-OPT mainly because there might have been preexisting code I could use.

[chuck2004]

I compared rdopt source files from this archive and maked into one. This will be useful for reverse engineering the code. @zvezdochiot did git for version 2.0, I also compared files from version 3.0. I compared the dates of creation, the size of the files, further the content with the WinMerge.

Index of compared files in PDF
file list

Source files v2.0 and v3.0