Jonathan, two small things, one merely cosmetic, the other not serious either (provided it's a bug at all)... In fractalp.c the second prompt for type "dynamic" is missing a closing parenthesis: "time step (<0 = Euler" In gifview.c the following line appears two times to set the color depth: planes = (buffer[10] & 0x0F) + 1; Now this masks the lowest 4 bits, where the lowest 3 determine the color depth and the next bit is set to zero in GIF87a anyway, but in GIF89a it might be set to 1 signalling an "ordered palette". So if someone is loading a non-fractint GIF with this bit set... (If the last paragraph is nonsense - not too unlikely considering my programming "expertise" - please kindly ignore.) Regards, Gerald
On Thursday 05 February 2004 12:10 am, Gerald K. Dobiasovsky wrote:
two small things, one merely cosmetic, the other not serious either (provided it's a bug at all)...
In fractalp.c the second prompt for type "dynamic" is missing a closing parenthesis:
"time step (<0 = Euler"
Fixed it. Thanks.
In gifview.c the following line appears two times to set the color depth:
planes = (buffer[10] & 0x0F) + 1;
Now this masks the lowest 4 bits, where the lowest 3 determine the color depth and the next bit is set to zero in GIF87a anyway, but in GIF89a it might be set to 1 signalling an "ordered palette". So if someone is loading a non-fractint GIF with this bit set...
(If the last paragraph is nonsense - not too unlikely considering my programming "expertise" - please kindly ignore.)
I don't see this line twice in gifview.c in any of the four different sources I have. Although it doesn't always matter, it is helpful to know which source you are looking at and where did you get it. 8-)) Jonathan
Jonathan Osuch wrote:
I don't see this line twice in gifview.c in any of the four different sources I have. Although it doesn't always matter, it is helpful to know which source you are looking at and where did you get it. 8-))
Because this guy here [points at himself] forgot to switch his brains on :-( The two lines are *not* identical (the second one manages the appearance of a possible local color table). Source: 2002sync.zip patched up to v20.3, but gifview.c hasn't changed since v20.2. Line 143: planes = (buffer[10] & 0x0F) + 1; Line 263: planes = (buffer[8] & 0x0F) + 1; In the first case the next bit after the global color palette size info signals a sorted palette and should be excluded by the mask. In the second case the next two bits after the local color palette size info are reserved and should be excluded by the mask, too (although I doubt there ever will be a new GIF version which will use this field :-)). Regards (still feeling stupid), Gerald
On Thursday 05 February 2004 9:47 pm, Gerald K. Dobiasovsky wrote:
The two lines are *not* identical (the second one manages the appearance of a possible local color table).
Source: 2002sync.zip patched up to v20.3, but gifview.c hasn't changed since v20.2.
Line 143: planes = (buffer[10] & 0x0F) + 1;
Line 263: planes = (buffer[8] & 0x0F) + 1;
In the first case the next bit after the global color palette size info signals a sorted palette and should be excluded by the mask.
In the second case the next two bits after the local color palette size info are reserved and should be excluded by the mask, too (although I doubt there ever will be a new GIF version which will use this field :-)).
I'm not the GIF guru, so I have no idea what you are talking about. Do you mean to say we should use 0xFF (or 0x1F) instead of 0x0F? Or is it something else? Jonathan
Jonathan Osuch wrote:
Gerald wrote:
Line 143: planes = (buffer[10] & 0x0F) + 1;
Line 263: planes = (buffer[8] & 0x0F) + 1;
[...]
I'm not the GIF guru, so I have no idea what you are talking about. Do you mean to say we should use 0xFF (or 0x1F) instead of 0x0F? Or is it something else?
No, it should be 0x07. In both cases (line 143 and 263) the information about the palette size is contained in the 3 least significant bits, everything else contains other information - but doing "byte & 0x0F" reads out the lowest 4 bits, one too many. However, as I wrote in my original post, it is nearly a non-issue, because in one case (line 263) this additional bit is not used (reserved), and in the other case (line 143)this bit, if set, signifies a so called ordered palette - one would have to load a GIF produced by software which does exactly this to experience a problem. In closing, apologies for creating such Shakespearean "much ado about nothing", I really didn't intend to :-) Regards, Gerald
participants (2)
-
Gerald K. Dobiasovsky -
Jonathan Osuch