Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: SMcNeill on November 04, 2020, 04:42:40 pm

Title: So here's a head scratcher...
Post by: SMcNeill on November 04, 2020, 04:42:40 pm
Step 1: Download the image file below.  (temp.png)

  [ This attachment cannot be displayed inline in 'Print Page' view ]  


Step 2: Open it in Paint, or some other external image viewer.  What you'll see is something like the following:

  [ This attachment cannot be displayed inline in 'Print Page' view ]  

Step 3: Now, run the following code in QB64:

Code: QB64: [Select]
  1. l = _LOADIMAGE("temp.png", 32)
  3.  

What it should look like is the following:

  [ This attachment cannot be displayed inline in 'Print Page' view ]  

Step 4:  Explain to me what the heck QB64 is doing to render all those colorful cursors that Paint and other such programs are failing to do.  This is an image I've saved with the SaveImage library, and I have no idea how the BLEEP it's producing this type of result.  As a QB64 image, it's fine!  (HOW??)  In any other external program, it's not.  Just what the heck is going on here??   

Anyone got any idea at all what's happening so that this *only* seems to work in QB64, and not anywhere else?  What is _LOADIMAGE doing that other programs are failing to do?  Enquiring minds want to know! 
Title: Re: So here's a head scratcher...
Post by: SpriggsySpriggs on November 04, 2020, 04:52:50 pm
I'd be willing to bet it is a corrupted image. The external programs are probably trimming out bad data which just so happens to stop after the first cursor. QB64 probably doesn't care or validate the data too well and displays it anyways. I've downloaded corrupted images before by storing the buffer of an image incorrectly and had a similar problem. QB64 couldn't display it but external programs could, but only part of the image as the rest was lost or corrupted.
Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 04, 2020, 04:55:10 pm
Quote from: SpriggsySpriggs on November 04, 2020, 04:52:50 pm
I'd be willing to bet it is a corrupted image. The external programs are probably trimming out bad data which just so happens to stop after the first cursor. QB64 probably doesn't care or validate the data too well and displays it anyways. I've downloaded corrupted images before by storing the buffer of an image incorrectly and had a similar problem. QB64 couldn't display it but external programs could, but only part of the image as the rest was lost or corrupted.


Running a check on the image, it gets the OK flag, so there's nothing being reported as corrupted with it:

Quote
D:\Temp2>pngcheck temp.png
OK: temp.png (2080x120, 32-bit RGB+alpha, non-interlaced, 99.6%).
Title: Re: So here's a head scratcher...
Post by: bplus on November 04, 2020, 05:01:23 pm
There's something odd about temp.png look how it's (not) centered in my Thumbnail pictures:
  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 04, 2020, 05:06:29 pm
Quote from: bplus on November 04, 2020, 05:01:23 pm
There's something odd about temp.png look how it's (not) centered in my Thumbnail pictures:
  [ This attachment cannot be displayed inline in 'Print Page' view ]

It's centered.  Windows is only displaying the left arrow, and then all the ones on the right are being covered in white.  The whole image is 2000x120 in size, or so, but only the first fragment on the right is displaying any color for the  preview.   Yet, qb64 loads the whole thing properly, and without any issues, displaying all the little colorful cursors for us. 

I have no idea what the heck is going on here.
Title: Re: So here's a head scratcher...
Post by: bplus on November 04, 2020, 05:09:06 pm
Wait, are you saying the colorful cursors are supposed to be there?
Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 04, 2020, 05:35:05 pm
Quote from: bplus on November 04, 2020, 05:09:06 pm
Wait, are you saying the colorful cursors are supposed to be there?

Yep.  They're there in QB64; just not anywhere else.
Title: Re: So here's a head scratcher...
Post by: Dav on November 04, 2020, 06:27:18 pm
Odd, it it an Animated PNG image? 

My old favorite Paint Shop Pro v4.14 loads it like QB64, but others don't seem to.

- Dav

  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 04, 2020, 06:33:25 pm
Quote from: Dav on November 04, 2020, 06:27:18 pm
Odd, it it an Animated PNG image? 

My old favorite Paint Shop Pro v4.14 loads it like QB64, but others don't seem to.

- Dav

So now we have two mystery programs where it works (QB64 and Paint Shop Pro) and a dozen more where it doesn’t.  How the heck am I supposed to debug something like this?  Particularly when it works properly in QB64 itself.

@Petr: I just loves you to pieces for finding this one.  No, honestly!  Where’s my chainsaw?  I’m gonna love you to pieces!  ;D
Title: Re: So here's a head scratcher...
Post by: FellippeHeitor on November 04, 2020, 06:35:44 pm
Look for the extra ancillary chunks to identify it's an animated png: https://en.wikipedia.org/wiki/APNG
Title: Re: So here's a head scratcher...
Post by: bplus on November 04, 2020, 07:35:02 pm
I checked it on Internet doubt if this helps but doesn't say corrupt, it is recognized:
  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 04, 2020, 07:47:33 pm
Quote from: FellippeHeitor on November 04, 2020, 06:35:44 pm
Look for the extra ancillary chunks to identify it's an animated png: https://en.wikipedia.org/wiki/APNG

It’s not an animated file itself.  It’s basically nothing more than a spritesheet of a cursor.  The only issue is that it looks and works as expected in QB64.  Not so, anywhere else (except in Paint Shop Pro).  And I have absolutely no clue how I accomplished such a feat.

In a way, I’m tempted to just say, “It’s a feature, not a bug.  This is the QB64 Secret Image export option!  Save all your porn in QB64, like this, and your wife and children will never be able to bust you with them!”
Title: Re: So here's a head scratcher...
Post by: Cobalt on November 04, 2020, 08:17:39 pm
I think there is multiple things going on here, I copy and pasted the image into my graphics software and saved it as a PNG and this is what I get when I open it in QB64.
Title: Re: So here's a head scratcher...
Post by: Richard on November 04, 2020, 10:12:38 pm
@ Steve

Please advise all the steps you took to obtain your "temp.png" - I see the lollipop cursors as you indicated on my computer.

I have been experimenting (for something else altogether) with an image that was converted using MS PAINT from 32bit to 256 color (.bmp). In the 256 color .bmp file (I know you are referring to a .png) - in the header - after the first 56 bytes - the 1024 byte (=256 colors x 4  bytes) color palette look up table is different from the same 1024 bytes that define my HP display. SO sometimes my image (256 colors) is really messed up (in various program environments) - at present I conclude that "I" must take extra programming precautions of defining what color palette look-up table (256 colors) to use and on which hardware configuration etc.

When I converted (using MS PAINT) your temp.png to a 256 color .bmp file - the header shows the 1024 byte color palette as all chr$(&h00) - (? .png always only works with 32 bit color).

I do not see your lollipop cursors in anything else than screen 0.
Title: Re: So here's a head scratcher...
Post by: Petr on November 05, 2020, 12:37:35 pm
Quote
I just loves you to pieces for finding this one.  No, honestly!  Where’s my chainsaw?  I’m gonna love you to pieces!  ;D

First wait a while, I'm just saving the porn in hidden png format :)

Can't it be related to the fact that the source image is rendered using XOR? See cursors.bm, line 502:

         IF s $ = "1" THEN clr = 15 XOR background ELSE clr = 0 XOR background
         PSET (X, Y), clr

But as i wrote, image, which is returned as output for save seems always right. Maybe - try image, which is in program output for saving transport to _CLIPBOARDIMAGE and then insert it to windows paint, if is displayed correctly, then is really bug in PNG record.
Title: Re: So here's a head scratcher...
Post by: johnno56 on November 05, 2020, 04:44:58 pm
Steve,

I use Gimp as my "go to" editor and I concur with the results of the png checkers. Simple white 'cursor' (160x120) with a black background in the first 'position' of an empty alpha 'strip' (2080x120) consisting of only one layer using a standard sRGB colour profile.

I would be curious to know how Photoshop detected all 13 'frames'.

There is a possibility that the image may be an animated png. A plugin for 'apng' is not currently supported by Gimp 2.8 and 2.10. This may explain why PS4 detected the 'frames' and Gimp did not.
Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 05, 2020, 05:26:34 pm
Quote from: johnno56 on November 05, 2020, 04:44:58 pm
There is a possibility that the image may be an animated png.

I can assure you, that it’s not.  The image in question was created using my SaveImage library in QB64.  It’s nothing more than a sprite sheet, saved in png format.  We don’t create any apng chunks anywhere.

Funny thing is, it saves just fine in BMP, GIF, JPG format, with no issues.  It’s just that it’s somehow saving in an unusual manner in png format.  Worst part of debuggingthis glitch: it works in QB64 itself.  It just doesn’t display properly for external applications.

How the heck do you go about debugging something that’s working?

Tomorrow, I have to go back down and watch over momma again for several days, so I’m just going to let it be and settle until I get back home.  Maybe fresh eyes next week will allow me to sort out what the heck’s wrong with it.

Chances are, it’s something verrrrry simple, as it’s working in QB64 and passes all verification checks.  It may just be writing a wrong color type value, or such, somewhere, in one of the chunks.  Whatever it is, I imagine it’s quite trivial and will require changing a single line of code, or so, once I stumble across the problem area.
Title: Re: So here's a head scratcher...
Post by: Kernelpanic on November 05, 2020, 05:34:56 pm
I have no problem with the picture. Not in Photoshop 7.1, Paint.Net 4.2.14, nor in QB64. The fault must be somewhere else.

Title: Re: So here's a head scratcher...
Post by: SpriggsySpriggs on November 05, 2020, 05:38:37 pm
@Kernelpanic Wrong picture.
Title: Re: So here's a head scratcher...
Post by: Kernelpanic on November 05, 2020, 05:45:21 pm
Once again as a png picture. - I always copied it as a png image.

Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 05, 2020, 06:00:04 pm
Quote from: Kernelpanic on November 05, 2020, 05:45:21 pm
Once again as a png picture. - I always copied it as a png image.

Which is wrong.  It should look like a series of rainbow cursors and not just a single white cursor on a black background.

I’ll dig into again with fresh eyes next week.  I really want to know how it’s wrong, just cause I’d like to be able to replicate the glitch on command.  I kinda like the idea of using it for hidden images.
Title: Re: So here's a head scratcher...
Post by: SpriggsySpriggs on November 05, 2020, 06:03:19 pm
@SMcNeill Did you notice that Kernelpanic downloaded your screenshot rather than the actual cursor image?
Title: Re: So here's a head scratcher...
Post by: Kernelpanic on November 05, 2020, 07:48:19 pm
What I have to do that it do not work? :-;  --  In Photoshop.

Title: Re: So here's a head scratcher...
Post by: SpriggsySpriggs on November 06, 2020, 12:07:41 pm
@SMcNeill It most certainly is corrupted. Run your png through this website and then open it. Yes, it has watermarks but that's whatever. Just look at how it appears after being repaired.

https://online.officerecovery.com/pixrecovery/ (https://online.officerecovery.com/pixrecovery/)

Or, if you grab it before it is expired, grab my job of the repair here and download the image

https://online.officerecovery.com/pixrecovery/job/378433734/ (https://online.officerecovery.com/pixrecovery/job/378433734/)
Title: Re: So here's a head scratcher...
Post by: Pete on November 08, 2020, 03:22:22 am
Corrupted images are interesting in that some viewers will partially display them, where others refuse to display anything. Personally, I love that QB64 can apparently display an entire corrupted image. Hey look, I just put a corrupted png of Joe Biden in QB64, and it came out uncorrupted, so it now looks like Trump! Thanks QB64!

Pete
Title: Re: So here's a head scratcher...
Post by: Cobalt on November 08, 2020, 10:58:50 am
there is nothing corrupted about Steve's image. Somewhere there is just an interesting issue with the way something is saved or loaded. As when the png is saved in my software it seems to double the arrow\black box area. So I'm guessing we could get several variants depending on what is used to save the image.

Wonder if it would do this with other 2 color images? instead of a cursor could you do it with a short word? or other small image?
@SMcNeill Why is the image 2080 wide though? Was that the original screen width or did that happen during the save?

 

Quote from: Pete on November 08, 2020, 03:22:22 am
Hey look, I just put a corrupted png of Joe Biden in QB64, and it came out uncorrupted, so it now looks like Trump! Thanks QB64!
Pete

Funny, for me it came back like a large brown blob, and gave my screen Smell-o-Vision, made my dog get up and leave the room coughing and gagging. Hurray for 4 new years of the shute hitting the fan and spraying on the majority. Clippy must be dancing a jig.

Quote from: SpriggsySpriggs on November 06, 2020, 12:07:41 pm
@SMcNeill Yes, it has watermarks but that's whatever. Just look at how it appears after being repaired.

Guessing that the watermark changes the data stored in the file from just compressed blank area though.

Quote from: Kernelpanic on November 05, 2020, 07:48:19 pm
What I have to do that it do not work? :-;  --  In Photoshop.

Steve stated that the issue\feature wont show in just about all graphics editors, only when loading to QB64.

Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 08, 2020, 01:31:13 pm
I’ll be back home tomorrow again.  I’ll end up taking the time to manually decode the file one byte at a time, to see what’s goofy with it.  I imagine it’s probably something very simple, like the header file reporting a colortype 6 (32-bit color) when it should be colortype 3 (256 color with palette).  QB64 might read it as a 256-color image just by seeng the palette chunk, and then convert up to 32-bit images, while other programs read that COLOR 40 (bright red) as _RGBA(0, 0, 0, 40).... 

Something going on like that could explain the whole mess.  The only question is, which byte, and where, is the value reading/saved wrong?  If QB64 didn’t read the file and render it properly, it’d be a lot simpler to hunt down the glitch.  As it is, I’ll have to look for the error which isn’t affecting us, and try and fix what’s not broken for us, because it’s broken everywhere else.  /sigh
Title: Re: So here's a head scratcher...
Post by: Petr on November 08, 2020, 03:10:18 pm
Hi Cobalt, that picture is the output of my unfinished program. This involves storing several images in a row, resolution is correct. The program allows the combination of 8-bit and 32-bit images into one. I didn't expect to cause such pain to Steve with that. I was definitely taken aback that GIF and BMP were fine. There was also bug in JPG format, but Steve already fixed it, so JPG now works fine.
Title: Re: So here's a head scratcher...
Post by: SpriggsySpriggs on November 08, 2020, 03:44:14 pm
Quote from: SpriggsySpriggs on November 04, 2020, 04:52:50 pm
I'd be willing to bet it is a corrupted image. The external programs are probably trimming out bad data which just so happens to stop after the first cursor. QB64 probably doesn't care or validate the data too well and displays it anyways.

Quote from: SMcNeill on November 08, 2020, 01:31:13 pm
I imagine it’s probably something very simple, like the header file reporting a colortype 6 (32-bit color) when it should be colortype 3 (256 color with palette).  QB64 might read it as a 256-color image just by seeng the palette chunk, and then convert up to 32-bit images, while other programs read that COLOR 40 (bright red) as _RGBA(0, 0, 0, 40).... 
So pretty much along the lines of what I was saying. Bad data that QB64 doesn't care about but other programs do.
Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 08, 2020, 03:48:52 pm
Quote from: SpriggsySpriggs on November 08, 2020, 03:44:14 pm
So pretty much along the lines of what I was saying. Bad data that QB64 doesn't care about but other programs do.

Aye, bad data, but corrupted data.  Everything passes values properly; I’m just guessing something is passing the wrong value.  Problem is sorting out what/where the bad data is.  I’ll start digging back into the issue more tomorrow.
Title: Re: So here's a head scratcher...
Post by: SpriggsySpriggs on November 08, 2020, 03:52:42 pm
I'm willing to give a look-see for you as well when I get back home. Which program generated the image?
Title: Re: So here's a head scratcher...
Post by: Petr on November 08, 2020, 05:06:33 pm
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?

  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: So here's a head scratcher...
Post by: SpriggsySpriggs on November 08, 2020, 06:35:34 pm
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:

  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 08, 2020, 09:15:26 pm
So here's the glitch, fixed:  [ This attachment cannot be displayed inline in 'Print Page' view ]  

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. 
Title: Re: So here's a head scratcher...
Post by: Petr on November 09, 2020, 09:35:18 am
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.
Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 09, 2020, 09:53:52 am
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.  :(
Title: Re: So here's a head scratcher...
Post by: SMcNeill on November 09, 2020, 10:01:29 am
Quote from: Petr on November 08, 2020, 05:06:33 pm
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.
Title: Re: So here's a head scratcher...
Post by: Petr on November 09, 2020, 12:16:09 pm
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.  


  [ This attachment cannot be displayed inline in 'Print Page' view ]  

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.
Text Only | Text with Attachments