sub savescreenasbmp( file as string ) ?

New to FreeBASIC? Post your questions here.
bluatigro
Posts: 651
Joined: Apr 25, 2012 10:35
Location: netherlands

sub savescreenasbmp( file as string ) ?

Postby bluatigro » Apr 28, 2012 10:15

i want to create animations whit FB

i aready know how to do graphics

what i need to store the pictures is a

savescreenasbmp( file as string ) sub

how ?
Richard
Posts: 3013
Joined: Jan 15, 2007 20:44
Location: Australia

Re: sub savescreenasbmp( file as string ) ?

Postby Richard » Apr 28, 2012 10:47

Use Bsave to save the screen or image buffer, use Bload to get it back.
TESLACOIL
Posts: 1769
Joined: Jun 20, 2010 16:04
Location: UK
Contact:

Re: sub savescreenasbmp( file as string ) ?

Postby TESLACOIL » Apr 28, 2012 16:29

there is a bug/bad behavior that causes the bmp that is saved to be slightly different from the one that was originally loaded


i haven't as yet fully explored the cause and solution , the difference in pallet is small so may not be an issue for you


magnolia/ tan colours seem to be worse effected but that could just be my test files / my eyes ability to pick up pallet changes

pixel by pixel analysis immediately picks this bug up
codeFoil
Posts: 255
Joined: Dec 22, 2011 4:45
Location: United States
Contact:

Re: sub savescreenasbmp( file as string ) ?

Postby codeFoil » Apr 28, 2012 23:38

TESLACOIL wrote:there is a bug/bad behavior that causes the bmp that is saved to be slightly different from the one that was originally loaded


Have you noticed this effecting all color formats or just 8 bit indexed?

Are you refering to this issue: http://www.freebasic.net/forum/viewtopic.php?f=3&t=19282&hilit=palette
bluatigro
Posts: 651
Joined: Apr 25, 2012 10:35
Location: netherlands

Re: sub savescreenasbmp( file as string ) ?

Postby bluatigro » Apr 29, 2012 17:11

i want to store the screen as *.bmp on disc

i m planning animations of more than 1000 bmp's

so i cant use bsave

whit a array of bmp's on disc i can create avi's

on the moment i m creating simple games / animations whit opengl + fb
codeFoil
Posts: 255
Joined: Dec 22, 2011 4:45
Location: United States
Contact:

Re: sub savescreenasbmp( file as string ) ?

Postby codeFoil » Apr 29, 2012 23:08

bluatigro wrote:i want to store the screen as *.bmp on disc
...
so i cant use bsave


BSave can be used to store images as BMP files.
Richard
Posts: 3013
Joined: Jan 15, 2007 20:44
Location: Australia

Re: sub savescreenasbmp( file as string ) ?

Postby Richard » Apr 30, 2012 2:30

@ bluatigro.
You can save the entire screen as a .bmp using Bsave.

You can ImageCreate a small image buffer, write to it, then Bsave that as a small .bmp

You can load an entire screen or just a small part of it with Bload.

Code: Select all

'Load a 48x48 bitmap into an image
ScreenRes 320, 200, 32
Dim myImage As Any Ptr = ImageCreate( 48, 48 )
BLoad "picture.bmp", myImage
Put (10,10), myImage
ImageDestroy( myImage )
Sleep

See the examples in the documentation. Ask more questions.
TESLACOIL
Posts: 1769
Joined: Jun 20, 2010 16:04
Location: UK
Contact:

Re: sub savescreenasbmp( file as string ) ?

Postby TESLACOIL » Apr 30, 2012 4:01

@ codeFoil

it happens in higher bit modes 16 , 32

bload the pic

check a pixel , pixel 123

bsave then bload the saved pic and a small % of pixels have changed colour value...its quite hard to spot just by looking






@ OP original poster i make bmp movies all the time , frame rates of 10 fps + easily achievable
codeFoil
Posts: 255
Joined: Dec 22, 2011 4:45
Location: United States
Contact:

Re: sub savescreenasbmp( file as string ) ?

Postby codeFoil » May 01, 2012 2:11

@TESLACOIL, I was tempted to reply to your original thread http://www.freebasic.net/forum/viewtopic.php?f=3&t=18360&start=15&hilit=bsave, but there was quite a bit of "noise" involved there, so I'll post here instead.

I took a cursory look at the BMP reading and writing code for Bsave and Bload in the git repository. If this ground has been covered already, I apologize.

The first thing to note is that while Bload will read 8 bit palette indexed, 16 bit , 24 bit and 32 bit BMP files; Bsave only writes in the 8 bit or 24 bit formats.
Second, the pixel data format used by the FreeBASIC runtime library is 5 bits red, 6 bits green, and 5 bits blue. The format specified for early BMP files is 5 bits red, 5 bits green, and 5 bits blue. In essence, a 16 bit BMP file is really 15 bit color, and Bload handles such files correctly. There is an alternative BMP format which allows the bit patterns to be specified by individual masks, and it appears from the code that FB handles these correctly as well. Either way, this requires a little bit of conversion. However, this can not be the source of the behavior you have noticed, because FB doesn't write back to a 16 bit BMP format, as you have already detected, and by the time you are examining your pixel data, the conversion has already been made.

Now, when writing a 24 bit color BMP file when the FB image data is in 16 bit color mode, each color component must be converted to an full 8 bit value, and this is the code that does it:

Code: Select all

color = ((unsigned short *)s)[i];
*p++ = ((color & 0x001F) << 3) | ((color & 0x001F) >> 2);
*p++ = ((color & 0x07E0) >> 3) | ((color & 0x07E0) >> 8);
*p++ = ((color & 0xF800) >> 8) | ((color & 0xF800) >> 13);

In this context, p is a char pointer, which in FreeBASIC would be an unsigned Byte ptr.
The bit shifting and logical expressions would look something like this in FreeBASIC:

Code: Select all

((colour and &h07E0) shr 3 ) or ((colour and &h07E0) shr 8)

This, in particular, is the expression that converts the green component value from 6 bits to 8.
These expressions had me a little perplexed, because they are actually copying some of the high bits of the 6 or 5 bit color fields into the low bits of the resulting 8 bit value, and I imagine the purpose of this is to smooth out what would otherwise be visible artifacts that would appear as a "step gradient".

Now, when Bload is used to load a 24 bit BMP file to be used in a 16 bit color mode, the opposite must take place. This conversion is a simple right shift, and for the blue and red channels, we get back that same value we started with, but for the green channel, when the original 6 bit value is greater than 31 AND even, the result is off by one bit (the low bit). This accounts for the difference you have noticed. As you probably know, we are all statistically more sensitive to the intensity of the green channel, which is why it is given twice the resolution in the first place (or so I've been told).

In 32 bit color mode, the Alpha channel is obviously lost, but if alpha transparency is not being used, this should not be visible.

For 24 bit and 8 bit color modes, I have not noticed anything in the source code that would suggest that any information could be lost, but I spent the day with a shovel, and my eyes may have missed something.

Again, if this has all been covered elsewhere, I apologize, for I did not search further than TESLACOIL's previous post on this subject. (or is farther?)
TESLACOIL
Posts: 1769
Joined: Jun 20, 2010 16:04
Location: UK
Contact:

Re: sub savescreenasbmp( file as string ) ?

Postby TESLACOIL » May 01, 2012 4:12

Thanx very very much for the extensive reply and investigation

ref

Bload will read 8 bit palette indexed, 16 bit , 24 bit and 32 bit BMP files;

Bsave only writes in the 8 bit or 24 bit formats.

if this is true then an pixel change issue may occur if im loading in a 32 bit bmp file because bsave saves it at 24 bit throwing away a handful of colours


ideally FreeBASIC should be able to save bmp at 16bit and 32bit, perhaps this should be added to the new feature list


Q Did you write some test code and see the pixel changes yourself ? or is this logical deduction cos you know how it all works in detail ?




FYI my robo vision reads in 32bit? 640x480 bmps at 20fps ( created by other software) , it needs to analyze, and save each bmp and do other stuff with minimal delay. Having to do a pixel by pixel conversion before analysis causes considerable delays. I had to resort to loading saving loading before carrying out analysis and was also pretty peeved at having lost valuable pixel data in the saving process. Basically it screwed with everything i was doing and it took me ages to track down the fault as i was assuming that if was loading a bmp picture it was saving that bmp picture without alteration of any kind
Last edited by TESLACOIL on May 01, 2012 5:37, edited 1 time in total.
TESLACOIL
Posts: 1769
Joined: Jun 20, 2010 16:04
Location: UK
Contact:

Re: sub savescreenasbmp( file as string ) ?

Postby TESLACOIL » May 01, 2012 5:27

>


the code below shows which pixels are changed by the bsave command , hard to see by eye alone ( tan colours change a lot )

screenres 700,600,16 causes lots of pixel values to be changed when the bloaded pic is bsaved to disk and reloaded

screenres 700,600, 24 and 32 do not cause pixels to be changed when the bloaded pic is bsaved to disk and reloaded

Code: Select all




dim p1(1000) as ulongint
dim p2(1000) as ulongint

dim as integer i,ii



screenres 700,600,16



bload "test1.bmp"
for i = 1 to 300 :  p1 (i) =  point (i,0) ' scanline
line ( i,0+1) - ( i,0+10), 12345678 ' marker bar shows where we scanned
next i

bsave "savedtest1.bmp",0 :

locate 5,5 : ? "scanned and saved"
sleep : 'cls




bload "savedtest1.bmp",0

for i = 1 to 300 :  p2 (i) =  point (i,0) : next i

'? " scanned again"

for i = 1 to 300
? i
if p1 (i)< p2 (i) then ?" pixel changed <<<<<<<" ;i 
'if p1 (i)> p2 (i) then ?" >>>>>>>pixel changed "

sleep 1

' p1(i) , p2(i)
next i



? "done"

sleep :end



This png file was loaded into m$ paint and saved as a 24bit bmp called test1.bmp ( according to m$ paint save as option )

Imagetest1.bmp
Last edited by TESLACOIL on May 01, 2012 5:34, edited 1 time in total.
codeFoil
Posts: 255
Joined: Dec 22, 2011 4:45
Location: United States
Contact:

Re: sub savescreenasbmp( file as string ) ?

Postby codeFoil » May 01, 2012 5:33

TESLACOIL wrote:Thanx very very much for the extensive reply and investigation
if this is true then an pixel change issue may occur if im loading in a 32 bit bmp file because bsave saves it at 24 bit throwing away a handful of colours

You shouldn't be losing any actual color information. The RGB information is still 24 bits in 32 bit mode, and written and read straight through in BLoad and BSave routines. The extra 8 bits are application specific, though usually used for alpha transparency and blending. The major advantages of 32 bit color is that pixel data can be aligned properly to optimize CPU reads and writes and you don't need to shift or mask bits. It also simplifies using some of the SIMD features of the processor in assembly language. It is actually a compromise trading a larger data foot print for a faster execution time. That extra eight bits is just padding and gains you nothing in persistent storage.

TESLACOIL wrote:ideally FreeBASIC should be able to save bmp at 16bit and 32bit, perhaps this should be added to the new feature list

I think the BMP compatibility coded into the BLoad and BSave routines was probably the result of someone scratching a particular itch and was never intended as a fully general purpose tool. It wouldn't be a stretch for someone to flesh the routine out a little more, but I don't see the point. If one is doing intensive image processing, there are more general and powerful libraries out there. Otherwise, coding a BMP loader for a specific version of the format is not that difficult. Writing a loader that can handle ALL of the various BMP options is a lot of error prone code. BMP dates way back to OS/2 and has been updated and extended every few years. The current format specifies a method for storing PNG and JPEG compressed data and color space management information. We don't need a language specific routine. We need Microsoft to drop their .NET crusade and start exposing functionality is a language neutral, processor native manner. It drives me nuts to have code packed away in COM objects on my system that I have to do a song and dance to use.

TESLACOIL wrote:Q Did you write some test code and see the pixel changes yourself ? or is this logical deduction cos you know how it all works in detail ?

I started writing a test case, but with so many BMP formats around (keep in mind some software cheats and does not write the file correctly), I decided to look at the actual code to see where I should focus. Once I saw the relevant parts, I didn't really need to test it, though I should. I did test the actual bit shifting expressions. I was too tired to do that mentally.
This shows what happens to the green component.

Code: Select all

For gVal as Integer = 0 to 63
    Print Gval, " ", Bin(Gval),

    Dim as Unsigned Short t = gVal shl 5
    Dim  as unsigned Byte oval =(t shr 3) or (t shr 8 )
    Print Bin(oVal),
    Print Bin(oVal shr 2 )
Next gVal


I assume your vision system is using some sort of capture software. I doubt that the alpha channel is being used, and even if it is, it is probably not relevant to your task (unless you've got an xray camera and a robot that can see naked people at the airport :) ). I don't know much about vision technology, but I imagine it is a number crunching game. I would side step the fb graphics library altogether and go straight for the data. If you know what format your input files are in, and this is not difficult to determine, it is just a matter of a few file reads to pull the data straight into memory. I know you like to share things across different processes, and this is an area where memory mapped files might be a benefit (they end up being cached by the OS much like DLLs and this can seriously reduce access time, even when using a RAM disk. (I say can, not will). Once set up, it is simpler than a text file because there is no parsing or file pointers to manipulate, and your images are small enough that you won't to worry about moving the "view".

MSDN and wikipedia both have decent information on the BMP file format. It's really nothing more than a data structure with usually one or two arrays slapped onto the tail end.

Append: If you are saving as 24 bit color, then you don't even have to worry about losing the alpha channel. There is no good reason to be using a 16 bit color mode. You are going to lose information that way no matter how you do it. The tans suffer because they involve the red and green channels, and green suffers through the conversion. This is true is almost all 16 bit color formats commonly used.
TESLACOIL
Posts: 1769
Joined: Jun 20, 2010 16:04
Location: UK
Contact:

Re: sub savescreenasbmp( file as string ) ?

Postby TESLACOIL » May 15, 2012 19:34

ill have to do more tests to pull up the bload issues i mentioned and confirm exactly what is happening...im sure you are pointing in the right direction

IMHO having easy to use keywords like bload any.jpeg etc or bload any.png bload any.bmp greatly simplifies things

Im all for the computer doing all the work for you 'especially' when that task is a simple common sense instruction (from a humans point of view anyway ) though the technicalities of the png format or a video format means that involves a huge bunch of code to get to the plug n play stage....if M$ paint can do it then so should any decent prog language...here again lack of developer resources prolly being a key issue. Because computer hardware is changing sooo fast no computing language ever created has had a chance to get polished to a high sheen.

We can at last start leaning on the cpu to lighten the programmers load without being accused of wanton bloat....if it was up to me id have that compiler sweating buckets just to save me a single keystroke. But it would be a lot of buckets of sweat for a developer to 'make it so' so i appreciate there will be shortcomings. I can see now how 'bload' was just a handy quick fix. ( i was under the false assumption 'that full handling of bmps had been solved'

Of all the formats to handle directly its the easiest to 'fully solve' as the information within a bmp is almost 1 to 1 data wise so i hope it does get tweaked further some time down the line so end users will be able to bload any bmp and save as any bmp...just as you can do with M$ paint.


Not wanting to knock the developers one cent ( cos i know the blood sweat n tears that goes into it ) ' but if your compiler cant handle basic common multimedia formats with the flick of a coders wrist '...it aint really much use to man nor beast in the year 2012ad....compilers in general have been lagging behind the recent technological rush. Now its HD this and 196kbs that...FreeBASIC just part of that crowd, here the increasing complexity and diversity of formats is the root cause. Dont shoot the develops 'rapid technology advances happening ona near monthly basis are to blame' ....us dumb humans can barley keep up at times....there a phrase for it, its called ' Future shock ' (Alvin Toffler)





Its only when you compare a compilers file format handling capability to M$ paint bundled with win 95 that the short fall is laid bare for all to see. Set a race to convert a bmp from one common format to another common and the fastest FBcoder on the planet is blown into the weeds by a chimpanzee armed with 20 year old M$ paint....if i ever get my sleeves rolled up far enough to wade into the FreeBASIC compiler this will be the first issue i will solve.

> if i wasn't tied up writing a full on HAL9000 style AI i would be committing to building a languadge much like FreeBASIC, indeed FreeBASIC is has the core of my 'idealized perfect language'...its why im here and why im using it to code up my AI

> the purpose of my AI project is to 'kill complexity' ....you talk it creates (does all the heavy lifting) eventually it will get smart enough to write compilers what have you, and if i want a feature added to the compiler all i have to do is ask ' my wish is its command'.... for sure the electric bill will go up, but the AI can/will crunch the far more code per coffee cup boiled than any human being.....the day we code ourselves out of a job is the day we are truly liberated and free to create....off topic somewhat but this (killing complexity) is what gets me outa bed in the morning.








ref AI vision> for execution speed i would ideally read the picture files in some kind of binary format, but the AI system is a great deal of work so i have to use the quick n easy method todo x,y,z ...zero time to polish code when you have a mountain of it to write :-( .....it will all get polished up by superior coders when the project is completes and handed over, for now i have to lean on FBs innards and whatever libraries etc are out there.

Return to “Beginners”

Who is online

Users browsing this forum: No registered users and 5 guests