So here's a head scratcher...

[SpriggsySpriggs]

I'm willing to give a look-see for you as well when I get back home. Which program generated the image?

[Petr]

Hi Steve. I add _CLIPBOARDIMAGE = san  (san is us output image) and then running windows paint. Pressing Ctrl + V and.... the same output as in your PNG format. You alone says, that _PUTIMAGE do something wrong. If you look to my source to row 421, so it is _PUTIMAGE, which create output image. Then again save BMP.... and is correctly, but _CLIPBOARDIMAGE is still wrong... so _CLIPBOARDIMAGE also contains the same bug?

  [ You are not allowed to view this attachment ]  

[SpriggsySpriggs]

I edited the picture using TweakPNG and the header does seem to be amiss. When I changed the header to match the repaired file I downloaded this is the result I got:

  [ You are not allowed to view this attachment ]  

[SMcNeill]

So here's the glitch, fixed:  [ You are not allowed to view this attachment ]  

And, there's good news and bad news with this fix.

Good news:  It doesn't appear that there's an issue with SaveImage which I have to address at all.

Bad news: _PUTIMAGE isn't working here, just as it wasn't working in the JPEG area earlier, either.  You can't simply put a 256 color image onto a 32bit color screen, without things going all goofy.  QB64 has some sort of internal conversion which wants to convert 256 color images to 32-bit images automatically, but...

I dunno what to say about it!

Somehow, we display the proper junk in QB64 with this auto-conversion, but things don't _PUTMAGE properly, or reference properly, for saving to files at all!

In your program, @Petr, make the following change and see if things don't work like you'd expect them to for you:

Code: QB64: [Select]

1.                             san = _NEWIMAGE(ResX * Celkem, ResY, 32)
2.  
3.                             Xps = 0
4.                             _DELAY .5
5.                             D = _DEST: s = _SOURCE
6.                             _DEST san
7.                             DIM p AS _UNSIGNED LONG
8.                             FOR PF = LBOUND(animace) TO Celkem
9.                                 _SOURCE ANIMACE(PF)
10.                                 FOR x = 0 TO ResX - 1
11.                                     FOR y = 0 TO ResY - 1
12.                                         p = POINT(x, y)
13.                                         r = _RED(p, ANIMACE(PF))
14.                                         g = _GREEN(p, ANIMACE(PF))
15.                                         b = _BLUE(p, ANIMACE(PF))
16.                                         PSET (x + Xps, y), _RGB32(r, g, b)
17.                                     NEXT
18.                                 NEXT
19.                                 '_PUTIMAGE (Xps, 0)-(Xps + ResX, ResY), ANIMACE(PF), san
20.                                 Xps = Xps + ResX
21.                             NEXT
22.                             _DEST D: _SOURCE s
23.                             result = SaveImage(soubor$, san, 0, 0, _WIDTH(san), _HEIGHT(san))
24.  
25.                             IF result = -1 THEN
26.                                 info = MsgBox("Oznámení" + CHR$(0), "Vaše práce byla uložena do " + soubor$ + CHR$(0), 0, 4, 1, 4096): EXIT DO '                    Work saved correctly
27.                             ELSE
28.                                 info = MsgBox("Oznámení" + CHR$(0), "Pøi ukládání souboru došlo k chybì:" + STR$(result) + CHR$(0), 0, 1, 1, 4096): EXIT DO '       Some error between saving file
29.                             END IF
30.  

As you can see, I've remarked out the _PUTIMAGE command, and I'm once again manually copying pixel by pixel from one image over to the other -- and this works.

No changes are necessary to SaveImage; just the change to remove that _PUTIMAGE and manually copy the sprites onto the sheet manually.  I'm astounded, once again, that there's no errors being tossed for trying to copy 256-color images onto a 32-bit image, but everything *appears* to work properly -- and, oddly enough, it does, in fact, work in QB64.  WTH it's doing to make things all goofy/glitchy with SaveImage is beyond me, but something certainly doesn't play nice when trying to save the image to file, and I have no clue what it is.

Patch is rather simple though:  Remove the _PUTIMAGE and just manually convert and copy pixels from your 256-color image over to the 32-bit version.


Edit:  And I'd still love to learn how the heck QB64 can read that file and decode it properly, when nothing else in the world can.  Exactly how the heck does our internal auto-conversion junk work?  Why don't we load the file just as glitched as every other program out in the world does??

We may have a fix for the program which generates the image in question, but the whole underlying problem is still a complete head scratcher, as far as I'm concerned. 

[Petr]

So. I'm absolutely surprised. First of all, Steve, thank you very much for solving this problem, and at the same time I apologize for your headache caused by the whispered identification of the problem on my part.

About how the QB64 saves a 256 color image on a 32 bit image - I'm shocked that someone can write this badly (_PUTIMAGE). That is probably not even possible. After all, instead of the number color of each 8-bit color, the index of the palette is inserted, it is perhaps not even possible to write stupidly ...
If the 8-bit image has the color 1, 5, 7, 3, then I'll look in the color palette (which each 8-bit image has different!) And insert the appropriate unsigned long value of the palette at the position of the 32-bit image .... damn, it's a hundred times easier than a dithering from 32bite to 8 bite image.

[SMcNeill]

No worries, Petr.  There’s still something odd going on with the image the program saved before, and I can’t sort it out, for the life of me.  Why does it load in QB64, but no where else??

I still don’t have a clue.  :(

[SMcNeill]

Hi Steve. I add _CLIPBOARDIMAGE = san  (san is us output image) and then running windows paint. Pressing Ctrl + V and.... the same output as in your PNG format. You alone says, that _PUTIMAGE do something wrong. If you look to my source to row 421, so it is _PUTIMAGE, which create output image. Then again save BMP.... and is correctly, but _CLIPBOARDIMAGE is still wrong... so _CLIPBOARDIMAGE also contains the same bug?

Like before, it’s not _CLIPBOARDIMAGE that’s wrong, it’s the _PUTIMAGE.  Whatever it’s doing wrong with SaveImage, it’s doing the same with _CLIPBOARDIMAGE.  As far as the display is concerned, everything looks good and proper, but somehow it’s all goofed up internally as far as reading and saving those pixel values is concerned.

Try CLIPBOARDIMAGE with the manual plotting of those pixels, and see if it’s not correct for you.  _PUTIMAGE just isn’t playing nice when it copies 256-color values over to a 32-bit image.

[Petr]

Damn! Damn! and damn it once again! I'm an idiot! What was I thinking? Steve, I have great news for you, but I'd rather get in a corner myself. It occurred to me that the first frame indicates the color palette in ANI format. When you look at my source. Case 7 inserts images. In its original form, I copied a palette from each image. But since the ANI format only supports 256 colors, this is nonsense. Just take the palette - the same for all images - from the first image. I did it (line 29), the original solution was on line 27, and .... Everything works as it should. _CLIPBOARDIMAGE is already sending the image to microsoft paint correctly, your PNG is attached, it is working properly. This solution does not work for all the files I sent you, but it turns out that this is not a bug anywhere else than in my program.

Oh my god...

Code: QB64: [Select]

1.  
2.                         CASE 7 'otevrit soubor s obrazkem - nejprve vymazat cache s mysi, pak teprve volat opensave dialog
3.                             soubor$ = WINOpenFile$
4.                             'n2a5a: pridana podpora nacitani souboru ANI, tedy je nutno rozlisit priponu oteviraneho souboru pto urceni spravneho loaderu
5.                             pripona$ = LCASE$(RIGHT$(soubor$, 3))
6.                             SELECT CASE pripona$
7.                                 CASE "bmp", "jpg", "png", "gif"
8.                                     test& = _LOADIMAGE(soubor$, 32)
9.                                     IF test& = -1 THEN
10.                                         warn = MsgBox("Výstraha:" + CHR$(0), "Nepodporovaný formát obrázku!" + CHR$(0), 0, 1, 1, 4096)
11.                                         EXIT DO
12.                                     END IF
13.                                     _FREEIMAGE test&
14.                                     warn = MsgBox("Dotaz:" + CHR$(0), "Akceptovat poměr stran?" + CHR$(0), 4, 2, 6, 4096)
15.                                     INSERTIMG soubor$, warn
16.                                 CASE "ani"
17.                                     AniSnimek = LOADCURSOR(soubor$)
18.                                     ANIsnimku = LENCURSOR(AniSnimek)
19.  
20.  
21.                                     Au = UBOUND(animace)
22.                                     REDIM _PRESERVE ANIMACE(Au + ANIsnimku + 1) AS LONG
23.                                     FOR f = 0 TO ANIsnimku
24.                                         cursnim = DECOMPOSECURSOR(AniSnimek, f)
25.                                         ANIMACE(f + Au) = _NEWIMAGE(ResX, ResY, 256)
26.                                         _PUTIMAGE , cursnim, ANIMACE(f + Au)
27.                                         '                                        _COPYPALETTE cursnim, ANIMACE(f + Au)
28.  
29.                                         _COPYPALETTE DECOMPOSECURSOR(AniSnimek, 0), ANIMACE(f + Au)
30.  
31.                                     NEXT
32.                                     REM FREECURSOR AniSnimek
33.                             END SELECT
34.  
35.                         CASE 11 'ulozit animaci do pasoveho obrazku
36.  

  [ You are not allowed to view this attachment ]  

This points to the difference in how _PUTIMAGE treats graphics, where there is no error, and how PSET approaches it. PSET probably sets the palette straight away, _PUTIMAGE reads it but probably doesn't set it.