Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : PicoMiteVGA: Format of BMP files for LOAD IMAGE
Page 1 of 2 | |||||
Author | Message | ||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
I may need a little more information regarding the format that a BMP file needs to be in to be displayed correctly by the LOAD IMAGE command. I have a 16 colour indexed BMP file that I created in the GIMP (using the palette that was discussed in another thread) and when I load it using LOAD IMAGE, all I get is the black portions of the image displayed in green (though in reality, probably myrtle). The original image is larger than the display, I am in Mode 2, should that matter? I have also tried it in Mode 1 and got the same result, only in Black and White. The image is also corrupted horizontally, staring to display about 1/3 across the screen, and then wrapping back around to the start about 2/3 of the screen across. I've uploaded the bitmap for those that may like to try and re-create the issue. Any help appreciated. Mike. Playing_Cards_32x48_RGB121_V3.BMP.zip |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4253 |
Mode 1 is monochrome. You should get a b/w picture. Mode 1 can only show color like 80's home computers, using tiles (default 8x12 pixels) Volhout P.s. looks like gimp includud the pallette into the bmp file. I think you should use a renderer to render the picture into a 16 color bmp, using this palette. Martin did this before. Edited 2023-04-29 15:49 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
Yeah, in Mode 1 the image was in B/W, but I still only got the same portions of the image from when it was in Mode 2. In Mode 2 those portions were displayed in myrtle. The colour myrtle was not even used in the original bitmap. The image loaded in Mode 1, but without specifying an X,Y location, I would have expected it to be aligned to the top left corner of the display. Again, I'm working from the manual, which may have not been fully updated yet. Perhaps I should try a non-indexed version of a bitmap file. Edited 2023-04-29 15:56 by Hawk |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
The good news is that I found out how to fix my problem. I re-saved my indexed BMP file as an RGB format BMP file and it loaded exactly as expected. So sorry @geoffg and @matherp, I'm not sure if it's a bug, or a feature, but unfortunately the statement in the manual that LOAD IMAGE supports all formats of BMP files doesn't seem to be the case. So it's either a change in code or a change in the manual. No guesses which is easier. Here is the RGB version of the file that worked correctly. The down side of this solution is that my 50K indexed BMP file became a 300K RGB BMP file. Mike Cards_32x48_RGB.BMP.zip Edited 2023-04-29 18:17 by Hawk |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9137 |
The firmware definitely supports indexed files as I've been using them recently and even supports compressed indexed 16 colour files |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
Mmm...interesting. Perhaps you could test the first file I posted and see how your mileage varies. As I said, size wise, it would be much better if I could use indexed BMP files. As mentioned before, these files have been created using the GIMP. |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2140 |
That displays correctly on my VGA. Used save compressed image "Cards_32x48_RGB_4bit.BMP" Cards_32x48_RGB_4bit.zip Now it's 40kB Edited 2023-04-29 19:13 by phil99 |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
Thanks Phil, I'll use the compressed BMPs next time. Did you try the indexed version of the file? |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9137 |
Don't know what gimp has done but I can't read it properly in PaintShopPro let alone the Pico. Just get a black and grey image |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
Thanks for that. How old is your PaintShopPro? Maybe it's a newer BMP format. It's certainly recognised by the Linux viewers. |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2140 |
IrfanView and Paint can display it ok but black & green on the pico. The size is too big, 416 x 240 pixels. 320 x 240 max. For processing your 24 bit images put them on a SD card and use the PicoVGA 'Save Image' to convert them to 4 bit. 'Save Compressed Image' uses run length encoding to shrink them further. |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
The pico is able to display the visible portion (320x240) of the RGB version of the 416 x 240 pixel BMP file. The Pico is misinterpreting the indexed BMP file in multiple ways. First it only displays in two colours, and second, it offsets the reading of the bitmap data. I'll give your file conversion technique a go. |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4253 |
Hi Phil99, Hawk, Phil, your conversion worked. I was able to load the BMP and it shows all cards from Ace to 10, and some rear sides and jokers. It does not show the king, queen and jack. That must be in the par you did not convert... (320...416) Using 5.07.07RC6 on picomite VGA mode 2 load image "Cards_32x48_RGB_4bit.BMP" Volhout Edited 2023-04-30 05:22 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2140 |
To avoid getting '> save image "............."' in the saved image use a terminal and:- OPTION LCDPANEL NOCONSOLE |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
The image is wider than 320, and so it's not displaying those portions that don't fit on the display. If you switch to Mode 1 and then display the image, you will see the whole image, but only the B/W portions. I'm now trying to work out how to display the individual cards. One plan is to load the image into the non-visible framebuffer and copy portions of it to the visible frame buffer. My concern here is that the image will not fit in the framebuffer because it is larger than the display size. A second option is to extract each card into it's own file and then load the cards on demand. This option will suffer a speed penalty, but that may not be an issue in a card game. We'll see what I can come up with today. I felt like I had achieved a goal when I was able to load and display the coloured image in Mode 2. Mike |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
@matherp, I think I've identified the reason that The PicoMiteVGA can't handle the indexed BMP files exported from the GIMP. The GIMP exports colour space information by default. It has the ability to turn this feature off for compatibility with applications that do not support colour space information. GIMP's indexed BMP files work fine if the compatibility option to NOT write colour space information is selected. @geoffg, it may be easier to add this information as a caveat in the manual regarding BMP files than the add the ability to handle them in the firmware. Hawk Oh, as an addendum to that, the PicoMiteVGA doesn't seem to be able to load Indexed RLE compressed BMP files generated by GIMP. Edited 2023-04-30 12:35 by Hawk |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
I tried doing this (I assumed it was on the Pico) but couldn't work out the command you used. I couldn't find an option to save a compressed image. Using the MMBASIC command SAVE IMAGE, I saved my 50k indexed bitmap (now working with compatibility mode) as a 230K RGB bitmap. It didn't help shrink the file. I'm working on PicoMiteVGA MMBASIC Version 5.07.06. Hawk Edited 2023-04-30 13:56 by Hawk |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2140 |
'Save Compressed Image' was added during development of Version 5.07.07. The amount of compression varies wit the amount of detail. Large areas of uniform colour compress very well. The image of the cards has a lot of detail so the size isn't much smaller. I think Version 5.07.06 should however be able to display them. Neither 'Save Image' nor 'Save Compressed Image' can process anything larger than the Frame Buffer which is 320 x 240 pixels in mode 2. 'Load Image' has the same limitation, expect odd results if you over-flow the Frame Buffer. Your oversize indexed image could be cut in two to see if it can display correctly. Edit. I cut off the last 3 columns of cards (using IrfanView) and it displays correctly on the VGA now, though I don't know if it retained the indexing. As all the cards are the same size they can be easily separately displayed using multiples of their dimensions to select them. IrfanView is very flexible and can do batch processing of a large number of files to convert to a specified size, colour depth, aspect ratio etc output to any image type. Once you get it set up it does the lot in one hit. Edited 2023-04-30 14:24 by phil99 |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
Thanks for the update Phil. I'm waiting for the official release of 5.07.07 to drop before upgrading, but for now I've got a workable solution to get to the next stage. As mentioned, with the Compatibility checkbox set in GIMP when I export to BMP, my indexed BMP files are working. Thanks for the warning about the oversized framebuffer image. I wasn't sure whether that would work. Unfortunately I can't re-arrange the cards on the 320x240 image and have them all fit, otherwise that would be another solution. I have a 320x240 title screen displaying correctly. For the cards, I could split them into a file for each suit, or a file for each face value, and read them into the framebuffer like that, then copy them from the non-visible to the visible framebuffer. I was hoping to animate the cards on the table, but I'm not sure that sprites on the PicoMiteVGA work like the old computers that I'm used to. I may need to do the moving more old school...draw-erase-move-repeat. I grew up programming on the Atari 400...overlaying sprites on the playfield is all handled by the Antic chip. Thanks again, Hawk |
||||
Hawk Senior Member Joined: 15/07/2021 Location: AustraliaPosts: 141 |
An update on my SPRITE experiments. I realised that the card game I'm developing does not use the whole deck, so I am able to allocate a sprite to each card. The PicoMiteVGA is limited to 32 sprites. Unfortunately sprites need to be loaded from a 24bit RGB BMP files, which increases the amount of memory required for each sprite. I'm looking forward to the release of 5.07.07 so that I can have some black on my sprites. My next task is to implement Bresenham's Line Algorithm in MMBASIC so that I can move the sprites/cards across the table in a straight line. I'd also like to synchronise the playing of WAV files with the sprite movements, so I will be keen to add audio to my Version 1 PicoMiteVGA board. From what I've seen in some of the threads on this forum, discussing audio for the PicoMites is openning a big can of worms. I'll be looking to find a simple "workable" solution and looking to others for input. I'm not above fitting an Aliexpress module to drive a pair of small laptop speakers. Hawk |
||||
Page 1 of 2 |
Print this page |