SaveImage

[SMcNeill]

Since [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] is down, and nobody knows when it might be back up, I thought I'd take time to post some useful little routines on the forums here so people can find and make use of them. 

First up is my SaveImage library.

Inside is a couple of quick demos which illustrate how to save a QB64 screen image in either BMP or PNG format, how one can easily turn a text screen into a 256 color graphic screen with one simple command, and how to compress and inflate strings or programs quickly and easily. 

Commands should be simple enough that everyone can figure them out without any real effort involved.

To Deflate/Inflate a string/file:

Code: QB64: [Select]

1. '$include:'saveimage.bi'
2. text$ = "Whatever the heck it is that we might want to compress, be that a long string of input, a binary file (just load the whole file into a single string and then deflate it), or whatever else is wanted)."
3. de$ = Deflate(text$) ' <-- This is how simple it is to deflate the string
4. t$ = Inflate(de$) '  <-- This is how simple it is to inflate that deflated string
5. '$include:'saveimage.bm'

To turn a text screen into a graphic screen:

Code: QB64: [Select]

1. '$include:'saveimage.bi'
2. PRINT "Hello World.  This is a SCREEN 0 screen which I'm printing on."
3. x = TextScreenToImage256(0) 'And a quick example of how to turn a text screen into a 256 color image screen
4. SCREEN x 'swap screens
5. CIRCLE (320, 240), 100, 40 'And draw a circle on it
6. LOCATE 2,1: PRINT "And now it's been converted to a 256 color graphical screen.  See the circle on it??"
7. '$include:'saveimage.bm'
8.  

To save an image (from any QB64 screen mode -- even SCREEN 0 text screens work!):

Code: QB64: [Select]

1. '$Include:'SaveImage.BI'
2. SCREEN _NEWIMAGE(1280, 720, 32)
3. InitialImage$ = "Volcano Logo.jpg"
4. exportimage1$ = "testimage.png"
5. exportimage2$ = "testimage.bmp"
6.  
7.  
8. l& = _LOADIMAGE(InitialImage$)
9. _PUTIMAGE , l& 'And this line
10.  
11. Result = SaveImage(exportimage1$, 0, 0, 0, _WIDTH, _HEIGHT)
12. IF Result = 1 THEN 'file already found on drive
13.     KILL exportimage1$ 'delete the old file
14.     Result = SaveImage(exportimage1$, 0, 0, 0, _WIDTH, _HEIGHT) 'save the new one again
15. END IF
16. PRINT Result
17. PRINT "Our initial Image"
18. IF Result < 0 THEN PRINT "Successful PNG export" ELSE PRINT "PNG Export failed.": ' END
19.  
20. SLEEP
21.  
22.  
23. Result = SaveImage(exportimage2$, 0, 0, 0, _WIDTH, _HEIGHT)
24. IF Result = 1 THEN 'file already found on drive
25.     KILL exportimage2$ 'delete the old file
26.     Result = SaveImage(exportimage2$, 0, 0, 0, _WIDTH, _HEIGHT) 'save the new one again
27. END IF
28. PRINT Result
29. PRINT "Our initial Image"
30. IF Result < 0 THEN PRINT "Successful BMP export" ELSE PRINT "BMP Export failed.": END
31.  
32. SLEEP
33.  
34.  
35.  
36.  
37. CLS
38. zz& = _LOADIMAGE(exportimage1$, 32) 'Even though we saved them in 256 color mode, we currently have to force load them as 32 bit images as _LOADIMAGE doesn't support 256 color pictures yet
39. IF zz& <> -1 THEN
40.     SCREEN zz&
41.     PRINT "Image Handle: "; zz&, exportimage1$
42.     PRINT "Successful Import using _LOADIMAGE"
43. ELSE
44.     PRINT "ERROR - Not Loading the new image with _LOADIMAGE."
45. END IF
46.  
47. SLEEP
48.  
49.  
50. CLS
51. zz& = _LOADIMAGE(exportimage1$, 32) 'Even though we saved them in 256 color mode, we currently have to force load them as 32 bit images as _LOADIMAGE doesn't support 256 color pictures yet
52. IF zz& <> -1 THEN
53.     SCREEN zz&
54.     PRINT "Image Handle: "; zz&, exportimage2$
55.     PRINT "Successful Import using _LOADIMAGE"
56. ELSE
57.     PRINT "ERROR - Not Loading the new image with _LOADIMAGE."
58. END IF
59.  
60.  
61. SLEEP
62. CLS
63.  
64. SYSTEM
65.  
66. '$INCLUDE:'SaveImage.BM'

[STxAxTIC]

Hiya Steve,

Thanks a lot for sharing the goods. I believe we have your saveimage library, or a version of it, flaunted up at https://qb64.org/samples/.

This re-opens a long-standing question for Odin: Should we urge him to deploy a publicly-curated Samples section? That would allow users to maintain their own uploads, but the micromanagement would go through the roof if we just have *whoever* put *whatever* they want into /samples/. It won't work if we don't ask for the right thing...

[SMcNeill]

Here's a process Odin might consider.

1) Create a forum to apply for "Forum Contributor Status".
2) Folks who Odin approves (via previous posts, samples, recommendations in the other forums), can have a sub-folder created inside a FORUM CONTRIBUTED SAMPLE forum.  Grant those users moderator rights for that corresponding sub-folder only.  Then they can have one place in particular to highlight their work and gather it up, without it all getting lost in a backlog of thousands of posts by hundreds of users in the future.

Basically it'd be:

FORUM CONTRIBUTED SAMPLES
  -- APPLY HERE  (subforum)
  -- Luke (subforum)
  -- SMcNeill (subforum)
  -- STxAxTIX (subforum)

Shouldn't be much work to create a series of subforums in such a manner, and then folks can sign up for an easy way to archive and highlight their work here in the future. 

[FellippeHeitor]

I find Steve's suggestion extremelly efficient.

[Petr]

1) I also agree with Steve's proposal
2) I add a slightly modified program from Artelius to the theme, it is a modified makejpg.bas program so that every image format supported through _LOADIMAGE will convert to JPG. At the time I edited it, I did not know about the possibility of connecting BI files to the source, so I put it here so as I edited it. I named it BMPTOJPG, for using is first saved the screen to BMP using SaveImage (the original version from Galleon) and this program then convert this BMP to JPG.

Please Odin to make higher characters limit for messages, because some sources are bigger than 20000 characters.

[STxAxTIC]

Meh. That solves *a* problem, but not *the* QB64 samples problem. The idea of approved or otherwise specially favored users is simply adding a layer to the Captcha sequence at sign up. "Congratulations, you're not a robot" becomes "congratulations, you have gained sympathy the moderators, so you are free to create a reality show on your own personal thread, where we can inherit and then spread ALL of our old problems." You know the problems I mean: Is the newest version at the top or at the bottom? Oops, the images you need to download are on some other page. Where's the download button? What if someone just routinely deletes everything Clippy says in their thread for no reason? What if one guys lets you say "fuck" but another doesn't? Too slippery. Steve's suggestion could allow every poster to become AJoyfulProgrammer. Do ya feel me?

I think It will work like this:

First of all, the actual database containing the sample programs shouldn't be trusted to forum software/mechanics. Forums aren't databses. The actual data should be in an intuitive structure that we can move around, back up, etc., - completely independent of these forums. What about when [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] comes back, and then we have this weird hybridized forum thing? Nope, nope, nope.

Second, if we layer things right, and if the projects aren't too large, we can get double-duty out of this structure and replace the "samples" folder that comes with qb64.

So then:

There will be a Samples section, just like there is now, but it should be renamed to Archives to better describe its function. It will be curated by the same select few that Steve just named. (But don't forget Fellippe.) The programs that are uploaded there, along with their descriptions/tags, will be done by hand, by the mods, period. No broken English, no caps lock, no bullshit. It will be considered as a kind of museum, a place for finished projects that need minimal maintenance. This is true for most QB works out there - the authors are mostly gone.

As for the true "Samples" section, we clearly need a new thread for those on the forums. New and developing programs can be "hot" in the forums for months or even years. Once the novelty of a program wears off, it gets migrated to the Archive. If the program was never novel in the first place - if its a blatant reinvention of what's already there, then... the coder will have to make it unique enough to stand out. I don't want 5000 identical broken calculators cluttering our page.

Anyway, I'll "ask" Odin what he thinks about all this.

[SMcNeill]

Library has been updated to version 1.6. (Found at the bottom of the first post in this topic, so new folks to the forums here will always get the latest version.)

Changes are rather simple as they mainly involve a small correction for converting text coordinates into graphic coordinates when saving a SCREEN 0 image.  (I got an email of the program crashing after a few runs, and it all had to do with saving a text screen from 0,0 to _WIDTH, _HEIGHT, which of course, can't be right as we can't start at 0 and go to _WIDTH without going off the screen and corrupting the save file...)

Also fixed the glitch in the DECLARE LIBRARY which should've been DECLARE DYNAMIC LIBRARY for 64-bit users, so you'll no longer need to go in and manually correct that yourself.

Otherwise, it's all the same as normal.  These changes are all under the hood and don't change syntax or anything of else, and this library can be extracted wherever you have the old version and replace it without any issues.

[SMcNeill]

And a quick demo for Odin, in case he wants to add this little routine into the Toolkit section:

Code: QB64: [Select]

1. '$INCLUDE:'SaveImage.BI'
2. FOR c = 1 TO 25
3.     COLOR c
4.     FOR i = 1 TO _WIDTH
5.         PRINT _TRIM$(STR$(i MOD 10));
6.     NEXT
7. NEXT
8.  
9. x = SaveImage("temp.bmp", 0, 10, 10, 20, 20)
10. PRINT
11. PRINT
12. PRINT "IMAGE Saved as 'temp.bmp'.  View it in on your drive to verify."
13.  
14.  
15. '$INCLUDE:'SaveImage.BM'

[STxAxTIC]

Sweet.

A little bit of stuff to sift through before the Librarian picks this up. Because I lack testing systems right now, what's the scoop with compatibility across different systems? I see a dependence on zlib.dll which seems to bind better to Windows than other OS's... but then again, I have a vague memory of running this under Linux. As I scan the code, it looks like BMP works across both Windows and Linux but PNG will pitch a fit for non-Windows. Any comments on how this runs on an Apple product as well?

As for the whole range of outputs for the SaveImage function, it seems to borrow from PNGExport:

'PNGExport results:
        '-1   All is good.  We think we exported a proper PNG file.
        ' 0   Compression failed.  File is probably corrupt.
        ' 1   File Already Exists.  As these are Binary files, we probably don't want to just overwrite the same file.
        ' 2   Incorrect Alpha settings.  Check for Alpha mode, and Color mode, and look for conflicts.
        ' 3   Bad GrabMode
        ' 4   Bad x1 coordinate
        ' 5   Bad y1 coordinate
        ' 6   Bad x2 coordinate
        ' 7   Bad y2 coordinate
        ' 8   x2 < x1 -- correct this to proceed
        ' 9   y2 < y1 -- correct this to proceed
        '10   Bad color mode.  Either use 256 or 32 color mode.
        '11   Attempted to export a text screen which will not work.
        '12   PNG save is impossible on non-Windows systems.  Can only use BMP

Looks good, and what is case 13?

EDIT

*self-facepunch* ..... duh, there it is right at the top of the file:

Error Code 13 is for invalid extension, or lack of extension

.... Okay, I think our collective heads are wrapped around this...

SECOND EDIT

What's the deal with the string compression demos, and is the run-time error on line 27 in String Compress Demo.bas supposed to occur?

[SMcNeill]

If someone can get Linux to work with library files (.so is the extension, I think), then PNG exporting could work for them.  As it is, I just can’t get my virtual Linux setup to find and use the files, no matter how I try and DECLARE them or use them.  PNG and the ZLIB Library simply wont work with them.

The BMP export is 100% native QB64 number/pixel crunching and works on all platforms — windows, Linux, and Mac.

Since PNG files are compressed by nature, ZLIB.DLL is packed as an external compression library, rather than me trying to write one from scratch.  (It used to come packaged with the SDL version of QB64, and when I first worked up the PNG exporter waaaaay back in the day, it just made sense to use the existing toolset rather than reinvent the wheel.  As I’m primarily a Windows user, I’ve never had a need to personally change it out either.)

The String Compress demo uses the same library files as the PNG Export routines, and should run without issues.  I’ll check later this afternoon and see why line 27 is glitching out for you, and report back with any troubleshooting problems/solutions then.

[SMcNeill]

Glitch is fixed in v1.6a.

The issue was simple: The TextScreenToImage routine was basically replaced with a better set of options for users — TextScreenToImage256 (to turn Screen 0 images into 256 color images) and TextScreenToImage32 (to turn Screen 0 images into 32-bit color images).

I just hadn’t updated the demo to use the new syntax, so it just needed that 256 to the end of the Function name.