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

rate control #64

Open
boxerab opened this issue Jul 7, 2021 · 2 comments
Open

rate control #64

boxerab opened this issue Jul 7, 2021 · 2 comments

Comments

@boxerab
Copy link
Contributor

boxerab commented Jul 7, 2021

Hello Aous,
Hope all is well.
Do you have plans to add rate control to the encoder?
I've been looking into this : as PCRD won't work on HTJ2K,
I guess it's possible to simply use quantization for lossy rate control,
but it won't be precise. Interested to know what approach you think
would work best.
Best,
Aaron

@aous72
Copy link
Owner

aous72 commented Jul 8, 2021

Hi Aaron,

All is good here; thank you for asking. I hope you are fine and doing well.
I am have been engaged in a task that takes all my brain bandwidth.

I want to have rate control, after supporting Qfactor.
There is some work done to find a quantization step size (qstep) that corresponds to the Qfactor of JPEG; roughly, JPEG and JPEG2000 should have the same visual quality at roughly the same QP. That work is here.
This is already supported in Kakadu, and I wish to have it in OpenJPH. This does not require RD control, and, for JPEG, people seem to be happy with using a Qfactor.

For rate control, the same PCRD procedure can be used.
Let's assume that OpenJPH also has SPP and MRP in the encoder.
Then, we can have the following passes:
CUP
CUP+SPP
CUP+SPP+MRP
CUP+SPP+MRP+CUP
CUP+SPP+MRP+CUP+SPP, and so on
Of course, each CUP has all the data in the previous CUP, SPP, and MRP. We can then define change (or increase) in rate vs change (or decrease) in distortion for each pass. These are the slopes we deal with in the PCRD procedure. In the end, we keep
one CUP and potentially the following SPP and possibly MRP. This is not hard to implement.
However, this means we have to code the quantized coefficient multiple times. This requires storage and is slow. A better option is to try to find a rough estimate of the bitplane at which the terminating CUP is, for the desired rate; basically, guess (or estimate) what CUP of these these CUPs we will eventually keep. Then, only generate passes around that CUP; this saves time and storage. Kakadu implements such a technique.

I wish I had more time to give to OpenJPH.
Hope this is useful.

Kind regards,
Aous.

Edit: minor touch ups.

@boxerab
Copy link
Contributor Author

boxerab commented Jul 9, 2021

Hi Aous,
Glad to hear all is well! Thanks a lot for explaining these different approaches to rate control and Q.
I may do some experiments on the CUP termination estimate approach.

Good luck with your current project and hopefully you have some time in the near future for OpenJPH.
Best,
Aaron

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

No branches or pull requests

2 participants