nesdev.org

Considering the amount of work we put into reverse engineering this, I'm kind of glad that people who continue to use the graphics packs now will know that there are some, albeit rare, data glitches while they play... Mwhahahaha...

xD xD xD

"at least 8 contexts" is actually 12. And the last bit has 16 contexts.

Well, they still sum 31. So i will still suppose they are get as 2*5+(4-2)=12 and 2*5+(8-2)=16. Sadly, i cannot work on this today.

first symbol for the pixel is always the same context. And the next symbol appears to only have two contexts. The next symbol appears to have at least eight contexts? What? If this worked like mode1, you would see 5+10+20+40=75 contexts. But the patent describe how it "degenerate" the pos...

This makes it so each pixel value only affects the "global" pixel likelyhood order exactly once.

Well, as i said i did'nt run automatic checks, so it's easy i missed that.

OK. I *believe* i have figured it out. Please take into account i'm even more tired than yesterday, and i haven't had time to test exhaustively this, but it seems to work for all the data i have tried (though, as i say, i haven't driven any automatic validation, and i bet i'm not in the best conditi...

previous pixel data, previous 2nd pixel data, previous 8th pixel data, previous 9th pixel data

Why haven't you included the 7th pixel? From the point of view of the drawings, it has the same importance than the 9th.

I took another look at the patent, and it seems i had missed the discussion about the "color rank". It says the rearrangement of the color order is "flexible through the learning of the ocurrence probability of each color". In the embodiment it describe, it's simlply putting the ...

I'm starting to see the light... The reference pixels are clearly related to the selected ordering for the 4 pixel values. I have found some remarkable regularities (indeed, for one of the 10 contexts i think i'm able to predict the content of one of the positions of the ordering), but most refer to...

Instead you are suggesting we consider something like 0xAA = 1.0 (so the initial range is called 1.5 and the we always try to 'renormalize' to keep the range in $80-$FF ~ 0.75 - 1.5). While the result (the "black box") is the same, this interpretation does make much more sense. For now th...

I like the top=0xFF (all lower bits are implied 1's) instead of top=0x00 You are missing the point here. Your "top" doesn't play the same role than "A" in the standard implementations. To say it this way, your "top" try to indicate the maximum value of a certain range,...

OK. I took a look at your implementation for the type 0. Definitively we were talking of different things. :P Besides that, it's clear for me that that 0x7f "extrange limit case" is only an artifact derived from the way you have chosen your internal states. If you look at the way QM-coders...

This stuff is going so far over my head its not funny. I need to read up on the arithmetic coding techniques used here... As a first reading, i would suggest this document: http://msp.csie.ncu.edu.tw/DC/pdf/QM.pdf Hmm... I meant "invert" as it was for mode 0 (ie. the invert value used for...

OK. I took another look at the patent. I don't have the patiente to do a careful read (as i still it's too generic to pay too much attention to it), but i looked again at the PBP thing, as that seem what we are lacking to know how to select the context for bitplane #1. If i have understood it correc...

5 + context of first symbol*2 + 1 if first symbol is lps? Or if that doesn't work then something like: 5 + context of first symbol*2 + 1 if first symbol (lps^invert)? Yeah, i tried that and much more ideas. :P something like this 10 01 00 11 and sometimes something like 01 10 00 11 OK. It's more cl...

Ummm, i have failed both trying to figure out how every bitplane #0's context is "splitted" in 2 contexts for bitplane #1 and the exact way the "MPS" works for bitplane #0 (the "prediction" thing we saw in type 0). In my tests, the selection of the context for bitplane ...