QB64 V3.9.0 Pondering what might be there?

[bplus]

_SaveImage - YES!

I've been using your save image routines for some time now. Nice to see they will be incorporated in QB64.

One request for saveimage, some way to preserve transparent backgrounds. I was trying some fonts in bmp for FB (to substitute out the 8x8 default they have) and failed every time with transparent backgrounds could not even persuade Paint nor Paint 3D to help. I think I was able to do something with png files in the past.

BMP files (to my knowledge) don't support transparent backgrounds. PNG files do however.

Yes I was thinking the same but this guy Jeffy, FB developer, managed one??
I was thinking run the BMP through a filter that makes Black transparent. Come to think in JB we had to make masks for sprites

[TerryRitchie]

One request for saveimage, some way to preserve transparent backgrounds. I was trying some fonts in bmp for FB (to substitute out the 8x8 default they have) and failed every time with transparent backgrounds could not even persuade Paint nor Paint 3D to help. I think I was able to do something with png files in the past.

BMP files (to my knowledge) don't support transparent backgrounds. PNG files do however.

Yes I was thinking the same but this guy Jeffy, FB developer, managed one??
I was thinking run the BMP through a filter that makes Black transparent. Come to think in JB we had to make masks for sprites

I ran across a BMP file that had transparency some time ago and thought WTF? Here to find out it was a PNG renamed to BMP and my graphics program was smart enough to see the correct encoding.

[SMcNeill]

BMP files at offset 28 in the header, stores 2 bytes which represent your image type...

"the number of bits per pixel, which is the color depth of the image. Typical values are 1, 4, 8, 16, 24 and 32."

So 32-bit BMPs are supported, which allows you to make any transparency level alpha you want in your image. They're just not very common as 24-bit tends to be used with most BMPs.

[mnrvovrfc]

With "mine" and Galleon's code for "SaveImage", which will soon be obsoleted, I was able to save 32-bit BMP.

Probably it was considered 24-bit, I should look more into it. I wasn't expecting transparency handled from a "common" image format other than PNG. Discovered this year PNG is lossless; I had thought JPEG was the one since that was created by a council of photographers.

"CoderJeff" might not like being called "Jeffy" or something like that. Freebasic is sure slick saving and loading BMP. What a shame the ones "in control of" Linux didn't decide which was going to be the image standard. Should have been XCF, the GIMP document format.

[bplus]

BMP files at offset 28 in the header, stores 2 bytes which represent your image type...

"the number of bits per pixel, which is the color depth of the image. Typical values are 1, 4, 8, 16, 24 and 32."

So 32-bit BMPs are supported, which allows you to make any transparency level alpha you want in your image. They're just not very common as 24-bit tends to be used with most BMPs.

@SMcNeill I am using your SaveImage Bi and BM and modified your demo to my purpose. And I am guessing, no I will bet real money, your setup for .BMP's was for 24 bit.

Is my money safe?

[bplus]

With "mine" and Galleon's code for "SaveImage", which will soon be obsoleted, I was able to save 32-bit BMP.

Probably it was considered 24-bit, I should look more into it. I wasn't expecting transparency handled from a "common" image format other than PNG. Discovered this year PNG is lossless; I had thought JPEG was the one since that was created by a council of photographers.

"CoderJeff" might not like being called "Jeffy" or something like that. Freebasic is sure slick saving and loading BMP. What a shame the ones "in control of" Linux didn't decide which was going to be the image standard. Should have been XCF, the GIMP document format.

jeffy is his name at GotBasic.com Discord where I got drawn into some FB tutoring.

[TerryRitchie]

BMP files at offset 28 in the header, stores 2 bytes which represent your image type...

"the number of bits per pixel, which is the color depth of the image. Typical values are 1, 4, 8, 16, 24 and 32."

So 32-bit BMPs are supported, which allows you to make any transparency level alpha you want in your image.  They're just not very common as 24-bit tends to be used with most BMPs.

Really?? Most interesting. I never realized transparency was possible with BMP but your explanation makes sense. My graphics program, PhotoImpact X3, does not allow the creation of a transparency layer with BMP, so it seems some graphics programs may have avoided this.

Does anyone use GIMP? Does it allow transparency with BMP?

[SMcNeill]

BMP files at offset 28 in the header, stores 2 bytes which represent your image type...

"the number of bits per pixel, which is the color depth of the image. Typical values are 1, 4, 8, 16, 24 and 32."

So 32-bit BMPs are supported, which allows you to make any transparency level alpha you want in your image.  They're just not very common as 24-bit tends to be used with most BMPs.

@SMcNeill I am using your SaveImage Bi and BM and modified your demo to my purpose. And I am guessing, no I will bet real money, your setup for .BMP's was for 24 bit.

  Is my money safe?

Aye.  You can see from the source:

Code: (Select All)

        CASE 4
            temp = SPACE$(3)
            OffsetBITS& = 54 'no palette in 24/32 bit
            BMP.BPP = 24

I remember asking back when I first put out the SaveImage library if anyone wanted/needed the 32-bit version where you could save the Alpha info.  Folks told me to skip it as it'd just add to the complexity of things and would make the image files 33% larger.  Since I also didn't bother to work up the cheesy little RLE compression, files could get a little large with full screen captures, and for some reason QB64 tends to attract a certain crowd where anything larger than 1 byte offends them.   

"I don't need an IDE!  I can make QB64 1.23 bytes smaller without it, and only ever use CLI!"  

"Whut?!  Why don't we support the -compressMyAssOff flag?!  It only takes 3 weeks to compile Hello World, but it can break it down to being 2 bits smaller!"  

"Whuuuttt?!!  Make a flexible library would an user could specify whether they want to save alpha levels, or not?  Require an extra parameter?!!  Add 20 lines of code to ALL my programs?!!  I'll never need that!  It's just BLOAT!!  BLOAT I TELL YOU!!  IT'S AGAIST TEH SPITIRT OF BASIC!!!!!"

And so, I produced the most universal and simplest of interfaces for the greatest majority of folks to use.  Just the ultra bare bones for image saving.

Your money is safe.  My library only does 256 color or 24-bit image saves.  (In BMP mode. PNGs still save the full 32-bits of information.)

[bplus]

BMP files at offset 28 in the header, stores 2 bytes which represent your image type...

"the number of bits per pixel, which is the color depth of the image. Typical values are 1, 4, 8, 16, 24 and 32."

So 32-bit BMPs are supported, which allows you to make any transparency level alpha you want in your image.  They're just not very common as 24-bit tends to be used with most BMPs.

@SMcNeill I am using your SaveImage Bi and BM and modified your demo to my purpose. And I am guessing, no I will bet real money, your setup for .BMP's was for 24 bit.

  Is my money safe?

Aye.  You can see from the source:

Code: (Select All)

        CASE 4
            temp = SPACE$(3)
            OffsetBITS& = 54 'no palette in 24/32 bit
            BMP.BPP = 24

I remember asking back when I first put out the SaveImage library if anyone wanted/needed the 32-bit version where you could save the Alpha info.  Folks told me to skip it as it'd just add to the complexity of things and would make the image files 33% larger.  Since I also didn't bother to work up the cheesy little RLE compression, files could get a little large with full screen captures, and for some reason QB64 tends to attract a certain crowd where anything larger than 1 byte offends them.   

"I don't need an IDE!  I can make QB64 1.23 bytes smaller without it, and only ever use CLI!"  

"Whut?!  Why don't we support the -compressMyAssOff flag?!  It only takes 3 weeks to compile Hello World, but it can break it down to being 2 bits smaller!"  

"Whuuuttt?!!  Make a flexible library would an user could specify whether they want to save alpha levels, or not?  Require an extra parameter?!!  Add 20 lines of code to ALL my programs?!!  I'll never need that!  It's just BLOAT!!  BLOAT I TELL YOU!!  IT'S AGAIST TEH SPITIRT OF BASIC!!!!!"

And so, I produced the most universal and simplest of interfaces for the greatest majority of folks to use.  Just the ultra bare bones for image saving.

Your money is safe.  My library only does 256 color or 24-bit image saves.  (In BMP mode. PNGs still save the full 32-bits of information.)

I am sure before my need for transparent backgrounds was experienced, if polled I wouldn't know WTH any choice of 24 or 32 or both would mean. Of course if you used 32 all the people using 24 would cry it's not the standard for bmp (yet). Now both is the answer but yah no so easy from just the .bmp extension to know. Maybe *32.bmp or *24.bmp so a whole new parameter is not needed. Going to make file names a little funny but seeing 24 or 32 is useful info about the file.

[SMcNeill]

Funniest thing is:  It's *easier* to save 32-bit images than it is 24-bit images.

For 32-bit, all you do is get POINT(x,y) and save that whole value.   For 24-bit, you get POINT(x, y) and then take the _RED, _GREEN, _BLUE values out from it, and only save those 3-bytes of that 4-byte color value.

If I'd known anyone needed 32-bit bmps, I could've added them to the library with all of about 20 minutes work.  Just seems kinda unnecessary now that we'll be adding an actual _SaveImage command into the language though.   

Still, I guess I could go back and expand the library for anyone who doesn't want to upgrade to 3.9+ for whatever reason, I guess?  I suppose expanding the library might be useful for the QB64 Official users, and the hardcore 2.0.2 I'll-never-upgrade users, at the very least.