SaveJPG glitch @Petr

[SMcNeill]

@Petr

I was digging around in the demo you sent me, and trying to reproduce the glitch you'd asked about.  As far as I can tell, the issue is down inside the SaveImage.BM file, in the SaveJPG routine itself -- and at a spot that had me completely baffled for the longest time...

In the BM, around line 617 (give or take, as I've did some modification which might shift lines up or down a few spots), there's a small routine which takes our existing screen and converts it over to a temporary screen for SaveJPG to work with, as it's a rather limited routine which expects to save the whole screen to file.  What we're doing is just taking the portion of the screen which we want to save, making it a temp screen, and then saving that whole temp screen, rather than picking and choosing start and end points in the routine for a partial screen...

You'll see where we create the tempimage, and then you'll see where we put the part of the old image we want onto the new image...

And there's where the glitch is! 

Something in that _PUTIMAGE isn't doing what it should be.  We're putting a 256 color image onto a 32-bit screen -- without tossing any sort of error message, which I find rather unbelievable! -- and the only colors that are being transferred properly are the solid white.  Everything else is coming across as a low-to-zero alpha color value, and basically being _PUT as invisible colors.   (I think.  I wouldn't swear at WTH _PUTIMAGE is doing here, but I'm certain it's doing something weird as heck and not working properly in this case.)

To prove it, test the following:

Remark out the _PUTIMAGE (0,0)..., image&,tempimage&, ...  line, and replace it with the following:

Code: QB64: [Select]

1.     _DEST tempimage&
2.     _SOURCE image&
3.     FOR x = 0 TO finishx
4.         FOR y = 0 TO finishy
5.             r = _RED(POINT(x + startx, y + starty), image&)
6.             g = _GREEN(POINT(x + startx, y + starty), image&)
7.             b = _BLUE(POINT(x + startx, y + starty), image&)
8.             PSET (x, y), _RGB32(r, g, b)
9.         NEXT
10.     NEXT
11.     _SOURCE tempimage&: _DEST tempimage&

Here, we're manually reading each point of the 256 color image and converting it to a 32-bit color value, before PSETing it back where it belongs on the 32-bit screen.  And, as far as I can tell, going this route works, whereas the _PUTIMAGE only puts the white value to the image and nothing else.

Make the simple change in your own program, to test it out, and if this is the correction needed, I'll make the change to the SaveImage library and eliminate the glitch for good for us, in the future.  ;)

[Petr]

Hi Steve,

Thank you for your help. Your PSET solution resolved a JPG bug. There's still some bug in PNG format, look. Use the same procedure - insert images, try to save it. The program that creates the images uses a mask, I mean XOR or AND, now I don't know from my head. But that, in my opinion, should not be a source of problems.

[SMcNeill]

I’ll dig into the PNG side of things tomorrow, as they’re usually a bit more complex to sort out just from the way the format saves things in various data chunks.  If one chunk is glitched, the whole thing glitches, so it’s always a bit more of a job to diagnose where the exact glitch is and what’s wrong.  :)

[Petr]

I understand. I'm glad you want to deal with this. I would never say that PUTIMAGE will do this bugs... Thank you, Steve!