Difference between revisions of "Talk:Riven tBMP resources"
m (A concurrence. And cleanup.) |
|||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
Aaron, I'm not entirely clear on your recent additions to the tBMP decode algorithms. Are you aware of specific images that exhibit the behaviors you describe to use a test cases, or a decoder implementation which respects those details? | Aaron, I'm not entirely clear on your recent additions to the tBMP decode algorithms. Are you aware of specific images that exhibit the behaviors you describe to use a test cases, or a decoder implementation which respects those details? | ||
| − | I think I've seen Aaron's effects in some compressed tBMPs. In particular, I recall being surprised by observing duplets repeating themselves, though I don't remember which tBMPs I was inspecting at the time. | + | '''[ [[User:TitoDalCanton|TitoDalCanton]] 21:18, 24 February 2009 (CET) ]''' I think I've seen Aaron's effects in some compressed tBMPs. In particular, I recall being surprised by observing duplets repeating themselves, though I don't remember which tBMPs I was inspecting at the time. |
| + | |||
| + | '''[ [[User:Aaron|Aaron]] 06:55, 23 February 2009 (CET) ]''' I mean to go back and check specifically for this, but I'm almost completely certain that this is true. Initially, in my algorithm, I used an unsigned integer to represent the number of pixels to look back from where I started, and decremented it each time I copied a pixel. This crippled all my images, and caused weird segfaults when it rolled over after 0. This was fixed when I used a signed integer type (ie let the command copy into newly-written pixels). This is basically an implementation detail, most people would do it a different way where this doesn't matter, or use a signed integer to begin with. [also, I think that pixel-based lookbacks ignore the extra space off the edge, while duplet-based ones do not, but I'm not certain on that. I'll verify that too, but it's too late now.] I didn't realize this was new information, I just thought it was left out. | ||
| + | |||
| + | '''[ [[User:Aaron|Aaron]] 04:21, 24 February 2009 (CET) ]''' OK, I found specific examples. First of all, pixel lookbacks either never happen close enough to new rows to look back into the last row, or they take into account the extra info not in the final image (the bytes per row thing I mentioned in the article), so I'm glad I tried to confirm it before adding it. As for the others, all of these examples are from my original 5-cd riven set, and they're all from b_Data.MHK. tBMPs 99, 101, and 106 (and others) have a higher bytes per row than image width, and only appear correctly when rendered as if they were (bytes per row) wide, then cropped. tBMP 0 (and almost every other compressed image) has many repeat subcommands that ask for more data than there is available at the time. Specifically, byte 165 of the command stream of tBMP 0 is 0xEC followed by 0x08, meaning n = 6 and m = 8, so it needs 12 pixels copied from 8 pixels ago. These images only render correctly when they are allowed to read into themselves. This also happens with repeat command 0xFC. I hope this clarifies things. | ||
| + | |||
| + | '''[ [[User:TitoDalCanton|TitoDalCanton]] 21:18, 24 February 2009 (CET) ]''' I checked my decoder implementation and I can confirm that your interpretation of row bytes is correct. In fact, I decode to a larger buffer (''rowbytes'' pixels wide) and then crop it to ''width'' pixels to get the final image. | ||
| + | |||
| + | '''[ [[User:BahamutZERO|Jean-Francois Roy]] 23:37, 25 February 2009 (PST) ]''' Thanks everyone for the information. MHKKit also uses a row_bytes * height * bytes_per_pixel for image decoding. If Tito's decoder is "correct", in that it produces correct images, I'll validate MHKKit against it. Perhaps post RGBA checksums for some of those tBMP resources for other people can unit test their decoders. Tito, is the source to maglev that you sent me a while ago still up to date? | ||
| + | |||
| + | '''[ [[User:Clone2727|Clone2727]] 12:42, 26 February 2009 (CET) ]''' My decoder does it the way Tito describes above using rowbytes * height. I also have been doing the "overlapping" with commands reading into themselves that Aaron describes. It has a second pointer which looks back and increments as it gets pixel and the actual image pointer increments as well with each new duplet. The images look fine to me. | ||
Latest revision as of 12:42, 26 February 2009
Aaron, I'm not entirely clear on your recent additions to the tBMP decode algorithms. Are you aware of specific images that exhibit the behaviors you describe to use a test cases, or a decoder implementation which respects those details?
[ TitoDalCanton 21:18, 24 February 2009 (CET) ] I think I've seen Aaron's effects in some compressed tBMPs. In particular, I recall being surprised by observing duplets repeating themselves, though I don't remember which tBMPs I was inspecting at the time.
[ Aaron 06:55, 23 February 2009 (CET) ] I mean to go back and check specifically for this, but I'm almost completely certain that this is true. Initially, in my algorithm, I used an unsigned integer to represent the number of pixels to look back from where I started, and decremented it each time I copied a pixel. This crippled all my images, and caused weird segfaults when it rolled over after 0. This was fixed when I used a signed integer type (ie let the command copy into newly-written pixels). This is basically an implementation detail, most people would do it a different way where this doesn't matter, or use a signed integer to begin with. [also, I think that pixel-based lookbacks ignore the extra space off the edge, while duplet-based ones do not, but I'm not certain on that. I'll verify that too, but it's too late now.] I didn't realize this was new information, I just thought it was left out.
[ Aaron 04:21, 24 February 2009 (CET) ] OK, I found specific examples. First of all, pixel lookbacks either never happen close enough to new rows to look back into the last row, or they take into account the extra info not in the final image (the bytes per row thing I mentioned in the article), so I'm glad I tried to confirm it before adding it. As for the others, all of these examples are from my original 5-cd riven set, and they're all from b_Data.MHK. tBMPs 99, 101, and 106 (and others) have a higher bytes per row than image width, and only appear correctly when rendered as if they were (bytes per row) wide, then cropped. tBMP 0 (and almost every other compressed image) has many repeat subcommands that ask for more data than there is available at the time. Specifically, byte 165 of the command stream of tBMP 0 is 0xEC followed by 0x08, meaning n = 6 and m = 8, so it needs 12 pixels copied from 8 pixels ago. These images only render correctly when they are allowed to read into themselves. This also happens with repeat command 0xFC. I hope this clarifies things.
[ TitoDalCanton 21:18, 24 February 2009 (CET) ] I checked my decoder implementation and I can confirm that your interpretation of row bytes is correct. In fact, I decode to a larger buffer (rowbytes pixels wide) and then crop it to width pixels to get the final image.
[ Jean-Francois Roy 23:37, 25 February 2009 (PST) ] Thanks everyone for the information. MHKKit also uses a row_bytes * height * bytes_per_pixel for image decoding. If Tito's decoder is "correct", in that it produces correct images, I'll validate MHKKit against it. Perhaps post RGBA checksums for some of those tBMP resources for other people can unit test their decoders. Tito, is the source to maglev that you sent me a while ago still up to date?
[ Clone2727 12:42, 26 February 2009 (CET) ] My decoder does it the way Tito describes above using rowbytes * height. I also have been doing the "overlapping" with commands reading into themselves that Aaron describes. It has a second pointer which looks back and increments as it gets pixel and the actual image pointer increments as well with each new duplet. The images look fine to me.
