Difference between revisions of "Talk:Riven tBMP resources"
(citations and clarifying authorship) |
(details for my decoder) |
||
| 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? | ||
| − | [ | + | '''[ [[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]] 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: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. | ||
Revision as of 22:18, 24 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.
