Screen Grabs

[steve4690]

I've been developing a screen grab facility for Picaso (specifically the 32028-P1(T), but there's not reason it won't work for other displays) and I think it's about time to share it!

I'd be interested in knowing what devices it works on.



Code attached is;

snip_scrgrab.4dg
Just cut and paste the const/global section into the program to have it's screens grabbed, and the code section above your main(). In main() you'll need to call ScrGrab_Init... to initialise and then call ScrGrab wherever you want to grab the screen.

Whilst grabbing a flickering pixel scans down the screen just to let you know something is happening. The grab will be saved to SD card with the name IMGnnnnn.RAW (150KB per grab.)

The screen size is set in the const section. Just alter it to match your screen size. (I've only tested on my uOLED-32028-P1T in portrait mode.)

Now you have to use my other program, which runs on Windows...

RawConv.zip
Unzip this to RawConv.exe and copy anywhere convenient (on a Windows PC.) This will allow you to browse your RAW files copied (from your 4D SD card) and to convert them to BMP format.

Once the prog. has started click on 'Load Images' to browse your *.RAW files. When you click on 'Convert and Save' all images in the left-hand panel will be saved as BMPs in the same directory as the RAW files. You can highlight individual images and delete then from the view by pressing the Delete key (the underlying RAW file is left unharmed!)

It uses .Net framework. I have v3.5 installed but I suspect that .Net redist. version 2.0 will be sufficient to run it.


Windows RawConv screenshot:


Regs
Steve Attached files RawConv.zip (6.9 KB) snip_scrgrab.4dg (3.2 KB)

[kevingill]

Top work Steve - it's good to share!
I've just tried it at home with a Goldelox but forgot that they don't support the file system :-(
I'll give it a go on the 2.4" P1T when I get back to work, but I'm sure it'll be OK.

This program really helps me alot cos I've developed several displays for work (around 10), but the only pictures I have of the displays are from a camera - it just doesn't look as good as a bitmap.

This needs posting on the CodeBase 4D Systems!

[steve4690]

Thanks Kevin.

I'm also finding it useful to convert a static drawn screen (where it takes up too much code) to a bitmap that can be brought back in to the display using graphics composer.


Another way of using the code if you just need a final, single, screen shot is to compile (to say GRAB.4XE) a version of the code that simply grabs a screen when started. Put it on the SD card and whenever you need a quick screen grab just add the following to the program to have its screen grabbed.

file_Mount();
file_Run("GRAB.4XE");


Regards
Steve

[Atilla]

Excellent work Steve, well done!!

Kevin I agree, this should be on the Codebase. We hope to have the facility in Codebase soon so that members themselves can post their works.

[steve4690]

v1.06 PmmC now accepts Word pointers to file_Exists() and file_Open() and so the workrounds I had in the screen grab (4DGL) code can now be removed.

Attached, updated, version should only be used on v1.06 PmmC onwards.


Regs
Steve Attached files snip_scrgrab.4dg (3.2 KB)

[steve4690]

I have done a further update to the 4DGL screen grab code. Since I posted a version this morning I don't plan on posting another one right away unless there's demand for it. I'll try the reworked version and post when I'm happy that it works reliably.

The changes I've implemented are;

1) Move from an individual Word write to a buffered write. This is localise file IO, so that recovery processing can be implemented with significantly affecting performance. (I also thought it would improve performance but it doesn't)
2) Added return code checking on all file operations and retry processing when a recoverable error is encountered.
3) Removed progress indicator - side effect of moving to a buffered approach.

Regards
Steve

[kevingill]

After trying this code on a 2.4" P1T, I occassionally get write errors at the start of random sectors on my uSD card. I've tried two different types of card and get the same problem.
It seems as though rapid calling of the ScrGrab routine is the cause. If I leave a gap of 10 seconds or so between calling the grab routine, it works OK. Call it repeatedly and the write errors occur.

I'm not sure if this is related to the repeated file_Mount/file_Unmount calls? Is there an issue in the firmware/Workshop with regard to this? Can someone at 4D Systems check this out please?

On the postive side, when this works, it works very well and has allowed me to grab all my custom made screens.

I'm using the latest 1.06 PmmC and 2.3 Workshop BTW.

[steve4690]

Hi Kev,

It's the same when issuing a single file_Mount() in main. I've just posted a report in uOLED forum.

Steve

[thomasW69]

Is there also a program available that converts the files into the other direction? I need to convert a lot of JPG files into raw files.
Where can I found a documentation of the RAW format?

[steve4690]

I'm not aware of one.

I wrote the code to go in the one direction for the sole purpose of handling captured 4DGL screens. The format of the images in the the RAW format (which is not the same as the RAW format created by digital cameras etc.) is almost identical to GC format. The GC version is documented on the forum... somewhere.

The raw format is of my own making, but is nothing special, just;
* File signature (Word = 0x4690)
* Width of image in pixels (Word)
* Height of image in pixels (Word)
* Image data (Height lots of Width-sized rows, each Word is the standard 4DGL 565 colour Word)
(It makes no allowance for the 8 bit format.)

mvanders, I think, has kindly offered to pull something together for you. It would be neater though if GC could also be run from the command line to create a .DAT and .GCI file from a directory full of images. Having a single program would ensure proper (or at least consistent - which in my book is as good!) handling of the 4DGL file format and its variants (e.g. 8 bit, 16 bit) and would allow the format to change over time without breaking peoples' code.

Regards
Steve

[muckm]

thank you so much!

it works very well on my uLCD-28PT ...