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 ?
sub savescreenasbmp( file as string ) ?
Re: sub savescreenasbmp( file as string ) ?
Use Bsave to save the screen or image buffer, use Bload to get it back.
Re: sub savescreenasbmp( file as string ) ?
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
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
Re: sub savescreenasbmp( file as string ) ?
Have you noticed this effecting all color formats or just 8 bit indexed?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
Are you refering to this issue: http://www.freebasic.net/forum/viewtopi ... it=palette
Re: sub savescreenasbmp( file as string ) ?
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
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
Re: sub savescreenasbmp( file as string ) ?
BSave can be used to store images as BMP files.bluatigro wrote:i want to store the screen as *.bmp on disc
...
so i cant use bsave
Re: sub savescreenasbmp( file as string ) ?
@ 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.
See the examples in the documentation. Ask more questions.
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 )
SleepRe: sub savescreenasbmp( file as string ) ?
@ 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
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
Re: sub savescreenasbmp( file as string ) ?
@TESLACOIL, I was tempted to reply to your original thread http://www.freebasic.net/forum/viewtopi ... ilit=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:
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:
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?)
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);
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)
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?)
Re: sub savescreenasbmp( file as string ) ?
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
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.
Re: sub savescreenasbmp( file as string ) ?
>
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
This png file was loaded into m$ paint and saved as a 24bit bmp called test1.bmp ( according to m$ paint save as option )
test1.bmp
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
Last edited by TESLACOIL on May 01, 2012 5:34, edited 1 time in total.
Re: sub savescreenasbmp( file as string ) ?
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: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
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: ideally FreeBASIC should be able to save bmp at 16bit and 32bit, perhaps this should be added to the new feature list
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.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 ?
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
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.
Re: sub savescreenasbmp( file as string ) ?
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.
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.