PureBasic Forums - English

Hum. The gif bytes written out to a file load and display fine here. The png bytes load into the code and output a gif that works. No idea what to look for next

Wait a minute, ie doesn't display it. Chrome does and so does windows photo viewer and photoshop.

netmaestro wrote:Wait a minute, ie doesn't display it. Chrome does and so does windows photo viewer and photoshop.

I didn't think of using Chrome but indeed it shows on OS X on Chrome as well but the OS X preview application and Adobe PhotoShop Elements don't show it.
Edit : Chrome only displays it with the extension you mentioned not written.

netmaestro wrote:Bummer. I have a dozen or so files here of differing sizes and depths and they all encode fine on Windows.

I don't have time right now to look at the code, but can this be related to the color buffer byte ordering on the mac ? BGR on Windows vs RGB on mac (I think) ?

Probably not

Fixed. It turned out to be a small problem caused by the heavily-windows-dependent version getting converted to crossplatform and a different var name was used for the width and height. As a result, the width & height were going into the file as 0's. Some decoders could handle that and some could not. It was just my bad luck to be testing with a decoder that could. Anyway, Idle's excellent macro has been found innocent and the updated code *should* work everywhere now. Mac seems ok from Wilbert, still looking for Linux.

EnableExplicit? What's that?

On OS X it is working now.

It appears transparency isn't supported. Is this true ?
I'm wondering in the encoding part of your code, why you use 4 character strings instead of 2 ?
RSet(Hex(PeekA(*bits8),#PB_Long),4,"0")

Transparency is easy to add and already tested working but not yet implemented.

The codetable has to be four-byte strings to accommodate larger file sizes. I had thought a word would be enough but I fought for hours trying to solve large files getting the colors garbled and in desperation I widened it out to a long. Like magic, the problem disappeared. Both Idle and I thought a word would be long enough for a structured pointer in the SetBits macro and that's how he initially posted it but the same problem cropped up. He changed it to a long and no more problem.

I can say with confidence that four bytes is the ticket, I've paid the dues on this one

netmaestro wrote:Both Idle and I thought a word would be long enough for a structured pointer in the SetBits macro and that's how he initially posted it but the same problem cropped up. He changed it to a long and no more problem.

I can say with confidence that four bytes is the ticket, I've paid the dues on this one

The SetBits macro is different.
The amount to shift the bits to be added varies from 0 to 7. The amount of bits to be added has a maximum of 12.
As a result of this, you need at least a 19 bits variable to work with and this exceeds the 16 bits of a word so a long (32 bits) is needed in this case.

If you say the character strings need to be 4 bytes, I'm sure you are right. It just seems strange since the value you are peeking varies from 0 to 255 which would indicate a two character hex code.
Also when I try 2 bytes instead of 4, even an image of a few megabytes seems to work fine on my computer.

It's not a question of size per se but the complexity of the color bits. Quite large files can never even need a CLR code sent, and other much smaller images have to reset the code size many times. It's that CLR code that causes a problem because when it gets sent the last normal code was 111111111111 and there is no more room for it in the 12 bits. The remaining nibble isn't available to the encoder and so you have to bump the size. You could solve it by sending the CLR at 11 bits (you can send it whenever you want, it's just that when the next code size would be 13, you must send it) but your resulting file size would be larger with more codes in it.

Even if I were convinced that 2 bytes is enough I'd leave it at 4 because it doesn't harm the speed noticeably and I wouldn't trust it not to run into problems later.

Actually if all you're referring to is the string length of the map keys, you're likely right. Could do some testing on that one. I know the type has to be long though.

Here's an example. I made this change to the code, only the string length of the map keys from 4 to 2 and as you point out I'm peeking Ascii bytes and so 2 *should* work: But here is the result, with 4 the image comes out perfect and with 2 this poor girl gets mangled:



But wow doesn't that NeuQuant routine work magic with 256 colors though (slightly OT of course)

I see the difference.
I'll try to create some asm code to speed things up; don't know if I'll succeed.

5.21 b1 Linux-x86
all output .gifs work with image viewer and Firefox
I successfully converted 800x600 & 1600x900 .png, 24 bit .bmp, and 8 bit .bmp.

As an aside I could not get a .tif file to show up in the Choose an image to convert to GIF requester list.
Also while a file named bitmap.png is selectable, if renamed to bitmap.PNG then it is not available for selection on the list.

Thanks for testing! So the code should be fully crossplatform then.

I'm not very good at those file requester patterns

I made this change to the code, only the string length of the map keys from 4 to 2 and as you point out I'm peeking Ascii bytes and so 2 *should* work:

Wonder if there's a bug in maps..