So here's a head scratcher...

[johnno56]

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.

[SMcNeill]

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.

[Kernelpanic]

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.

[SpriggsySpriggs]

@Kernelpanic Wrong picture.

[Kernelpanic]

Once again as a png picture. - I always copied it as a png image.

[SMcNeill]

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.

[SpriggsySpriggs]

@SMcNeill Did you notice that Kernelpanic downloaded your screenshot rather than the actual cursor image?

[Kernelpanic]

What I have to do that it do not work? :-;  --  In Photoshop.

[SpriggsySpriggs]

@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/

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/

[Pete]

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

[Cobalt]

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?

 

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.

@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.

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.

[SMcNeill]

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

[Petr]

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.

[SpriggsySpriggs]

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 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.

[SMcNeill]

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.