Comments (5)
My preferred is YCoCg-R, but I’m not objective, because I regularly work in Y′CoCg for old additive colour systems (cinema from the 1920s and 1930s), which often don’t fit well in RGB. I will delve info PLHaar.
from ffv1.
My understanding of PLHaar from some tests is that it may lose some compression at lower bit depths, but work better at higher depths (this is just from some small tests - I would expect much larger testing before any is adopted.)
Aside: PLHaar has a problem, for example, on greyscale content, because it centres on 127.5, so your chroma (which should be all 128) is a mix of 127/128.
from ffv1.
I think the key questions are
- how does it affect compression across a representative set of inputs
- hoes does it affect speed across a representative set of inputs
- are we missing some "better" choices. Has someone reviewed the current state of the art from other similar simple transforms to per image, per slice, or per pixel adapted transforms?
There is also the question of
- what is the best compression achievable by modifying the RCT if one disregards speed.
This would give a bound to what can be gained in the best case with a transform considering speed and compression
from ffv1.
how does it affect compression across a representative set of inputs
I plan to run a lot of RCTs over various sets of RGB videos soon, and post the results here - stay tuned.
hoes does it affect speed across a representative set of inputs
I would expect most RCTs to be small (with some exceptions, see my reply to the last question)
are we missing some "better" choices. Has someone reviewed the current state of the art from other similar simple transforms to per image, per slice, or per pixel adapted transforms?
Yep, there has been a fair bit of research since j2k-rct, as you would expect.
what is the best compression achievable by modifying the RCT if one disregards speed.
This would give a bound to what can be gained in the best case with a transform considering speed and compression
This is interesting, specifically for RDLS modifed RCTs, where the lifting step in various RCTs is replaced by a denoised lifting step in order to. In the paper, they use a set of 11 weighted linear averaging filters, on two planes, and choose the one that minimizes codign cost, so it would require a little more work from the encoder. In their paper they take the memoryless entropy of the median predicted plane as an estimate of BPP, but I think we can do better both in cost estimation and filters. This also requires transmitting some sort of info on which filter was used in the bitstream - in the paper, they use two four-bit numbers (since there are 11 filters), meaning one byte. The rest on here, aside from RKLT, are all extremely simple operations (you can find some of their complexities listed in[1]).
I plan to test the following over a large set of images and videos:
- The current J2K-RCT as it is in the spec. (requires N+1 bit chroma)
- YCoCg-R (Paper: see original post) (requires N+1 bit chroma)
- PLHaar (Paper: see original post) (does not expand dynamic range)
- RKLT (based on converting the 3x3 KLT via [0]) (requires up to N+2 bits, and transmission of the matrix)
- RDgDb & mRDgDb (Paper [1]) (Requires N+1 bits chroma for non-m variant only)
- LDgDb & mLDgDb (Paper [1]) (Requries N+1 bits chroma for non-m variant only)
- LDgEb & mLDgEb (Paper [1]) (Requries N+1 bits chroma for non-m variant only)
- The RDLS variants of all the above (Paper [2]). Requires choosing filters (if any is chosen at all), and may expand chroma by 1 bit on some transforms.
I've already implemented the annoying parts of these, but it should be just a matter of finding time to modify the FFV1 encoder to test them. I could also be unaware of other developments in RCTs, of course - this is just what I've found after a little playing around.
[0] https://www.semanticscholar.org/paper/General-Reversible-Integer-Transform-Conversion-Pei-Ding/bf1c3c63cfca437ac697c2ed135cf5540df5a9da?p2df
[1] http://sun.aei.polsl.pl/~rstaros/papers/s2014-jvcir-AAM.pdf
[2] https://arxiv.org/abs/1508.06106
from ffv1.
@dwbuiten thats nice, thanks alot for working on this!
from ffv1.
Related Issues (20)
- 4.6.2. plane_pixel_height has incorrect information on chroma planes
- Quant tables: reference decoder relies too much on reference encoder HOT 3
- [v4] Consider adding prediction to inter mode HOT 5
- sign_extend is used but not defined HOT 1
- Spec allows >8bit depth in Golomb-Rice mode but nothing can make this HOT 3
- IEEE CRC-32 referenced in spec is not a standard IEEE CRC-32 HOT 8
- JPEG2000-RCT transform equations are incomplete / don't match reference HOT 1
- few instances of lines too long HOT 2
- section 3.8.1.2 needs to define get_rac HOT 8
- section 3.8.1.1 should have pseudocode HOT 16
- [v4] slices HOT 5
- Build produces pages of warnings and errors HOT 8
- Nothing in the Makefile removes the genarated *.svg files HOT 1
- reading through section 3.8.1.1 HOT 8
- add list of ffv4 goals and promises
- Renaming of the repo to ffv1-specification HOT 4
- FFV1 CUDA accelerated version HOT 7
- Handling of odd dimensions, subsampling and more than 1 slice
- remove exceptions from FFV1 version 4? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ffv1.