I don’t understand what you are trying to say.
The code you added is missing some keywords – for example you removed the “if” from a couple of statements.
You don’t say what you think the problem is.
- Mark
]]>Regards, Michael.
]]>It seems you made a small mistake in the part called “The Real Decoder”.
In article:
Now let's look if after reading your article I will be able to understand an entropy encoding part of JPEG-XR codec. That is, assuming that it is actually adaptive arithmetic coder. So far, I couldn't figure out even that. I guess, I am not good at understanding minimally commented source codes.
]]>It seems you made a small mistake in the part called "The Real Decoder".
In article:
if ( low >= 0x80000000U || high < 0x80000000U ) {
low <<= 1;
high <= 0x40000000 && high < 0xC0000000U ) {
low << = 1;
low &= 0x7FFFFFFF;
high <= 0x80000000U || high < 0x80000000U ) {
low <<= 1;
high << = 1;
high |= 1;
value <= 0x40000000 && high < 0xC0000000U ) {
low << = 1;
low &= 0x7FFFFFFF;
high << = 1;
high |= 0x80000001;
value <<= 1;
value += m_input.get_bit() ? 1 : 0;
} else
Now let's look if after reading your article I will be able to understand an entropy encoding part of JPEG-XR codec. That is, assuming that it is actually adaptive arithmetic coder. So far, I couldn't figure out even that. I guess, I am not good at understanding minimally commented source codes.
]]>with regards from Kenya.
]]>It's a little difficult to determine how many bits are being used per code word. It's not a code like, say Huffman coding, in which a symbol has a specific integral number of bits.
In arithmetic coding, codes tend to have close to -ln(p) bits, where p is the probability of the appearance of a symbol in your model using base 2. The actual number of bits used will be as close to that as the precision your model allows.
So in order to restrict a symbol to a certain number of bits, you have to adjust your model to not generate a probability that will be less than 1/2&bits or something like that. Since you control the model this is totally under your control
- Mark
]]>Wish I knew enough about it to write an article!
- Mark
]]>Cheers,
Aaron
But after some more thinking (after writing the first post), I think I understand it. Lets say |A| = 3 and |B| = 5. Since we want to map one to another, lets make it of equal length by "multiplying" A on |B| and B on |A|:
We see, that mapping from A to B is just y=floor(|B|*x/|A|). To do the reverse, we need to take next y (hence, y + 1) and find how many |B| we can fit into it: |A|*(y + 1)/|B|. But we need to avoid case where |A|*(y + 1) % |B| == 0, because in that case we will get x + 1, not x we are looking for. For that purpose we subtract 1: ( |A|*(y + 1) - 1)/|B|.
As you can see my explanation is clumsy and not formal, so I would like to hear a better on, if somebody has it.