Lejos image format

[matejdro]

I want to make program that will scroll large image over NXT screen.

I made 500x64 monochrome image in paint and then converted it into custom format using custom java application (format have pixels stored in columns - so every 8 bytes means 1x64 column). That seems logical, as I would only have to shift whole screen left for 1 column, read 8 bytes from file and insert them at far right.

However, this concept was proven too slow. It took about 700ms per frame and I found out that it spent most time on LCD.setPixel methods, so setting pixels one by one is not good solution.

But I have found another method that might help me: LCD.bitBlt. Idea is that it would read and copy data directy from image file, bypassing slow setPixel methods. But problem is that now I do not know in what format must input byte[] be.

Are there any specifications about how must pixels be arranged in bitBlt input to work?

[skoehler]

Use Graphics instead of LCD. It allows you to draw images and internally it will probably use bitblt.

[gloomyandy]

The leJOS image format is documented in the Image class...
http://lejos.sourceforge.net/nxt/nxj/ap ... Image.html
Handling of images is demonstrated in the graphicssample sample application:
http://lejos.svn.sourceforge.net/viewvc ... iew=markup

Andy

[matejdro]

Use Graphics instead of LCD. It allows you to draw images and internally it will probably use bitblt.

I want to draw part of one long image, and possibly also load it part by part (so whole ram is not filled with just image), so simply loading whole image and displaying it is not an option.

The leJOS image format is documented in the Image class...
http://lejos.sourceforge.net/nxt/nxj/ap ... Image.html

Like that?

(imagine this picture as top left corner of the screen, dotted lines are pixel borders)

[gloomyandy]

Each byte spans eight scan lines (or rows), so the first byte contains the first pixel of row 0-row 7 the least significant bit is row 0, the second byte contains the pixels for the second column rows 0-7 etc.

The image format works with images that are larger (or smaller) than the nxt screen so long as you correctly specify the width and height. leJOS even comes with a program that will convert images from existing formats into this format. Take a look at the sample code it is not that hard, and the bitblt function takes care of most of the hard work... As Sven has already pointed out the Graphics class is what you need. This is not tied to just screen sized items, you can easily use offsets into larger images, or display smaller images on the screen.

If you load your image data into a byte array then wrap it in an Image object using createImage, this will simply reference your byte array and will not copy the data, so you can even change the data after you have created the image (to load new data etc).

If you still do not understand the format, simply create an image and then use the graphics functions to draw a few lines into the image and then dump the contents of the image, that way you can see how the pixels map to the bytes...

Andy

[matejdro]

Main problem with this format is that whole image is loaded into RAM at once. While this might not be a problem for smaller images, it's just wasting ram when you get into 2000x64 or something like that.

Anyway, I have figured it out. Thanks for your help.

[gloomyandy]

What makes you think you need to have the entire image in memory at once? If you have a very wide image there is nothing to stop you from only loading some sub image into memory as a smaller image. Yes you will have to do a little work to just read the parts of the image that you require from the file system, but that is true of any rectangular image format, you can always arrange for the on disk format to be different to the in memory one to make it easier to load sections of the image... The bottom line is that this image format is the format used by the display, and if you want to efficiently update the display then this is the format you will need to use. The BitBlt function lets you manipulate this format much more efficiently than attempting to do it pixel by pixel from Java, it is well worth taking some time to understand what this function can do...

Andy

[matthias]

for me the System.arraycopy function was faster than BitBlt

[skoehler]

for me the System.arraycopy function was faster than BitBlt

That's likely to be the case. arraycopy is a special case of bitblt.

[gloomyandy]

Yes but ArrayCopy will not handle sub byte copies or deal with rectangular areas, BitBlt will. It also deals with non aligned data correctly...