The planned implementation for 0.4 is not to show all images, but when you click an image to show it on a new screen.

If the image is a link, then you get - show image/follow link.

Images are to be scaled to the screen size and will require on-"disk" caching.

Just a question richard, when you say "is not to show all images" what this mean? I'm a little bit confused with it :)

Not show all the images that a page contains, just the image that the user clicks, one at a time. It's a bit low quality, but easier to implement :-) Once that's working I can think about improving things!

I like the way you think, man.

That's a nice way to view images on the browser, good work!

If you can use ram expansions like dslinux and opera for caching it would be great...many slot2 flashcarts have it, some 32MB other 16MB (opera expansion only has 8MB). See http://dslinux.org/wiki/Running_DSLinux

To keep people posted: No release yet, but the code in subversion now can show images using the "poor-man's image viewer" as mentioned in comment 2. gifs and pngs are not too bad, but I've used the tinyjpeg library http://www.saillard.org/programs_and_patches/tinyjpegdecoder/ for jpegs and it is not very compatible. I think I'll try the small jpeg decoder library too - http://www.voicenet.com/~richgel - that also has decoding per row, which means less total memory needed.

I've not implemented scaling yet, which is pretty vital for visibility and memory. Currently big images leave the browser KO'd.

Hello Richard,

I looked through your code and found in Class for Images this part:

"static bool isJpeg(const char * filename) { // this is crap. Have to read in the whole file to see if it a JPEG. nds::File f; f.open(filename, "rb"); if (f.is_open()) { "

I found on the net some descriptions about the jpeg format:

http://www.wotsit.org/list.asp?page=3&fc=1&search=&al=

It seems, that (quite) all jpeg files start with sequence "ÿØÿà..JFIF." HEX: 00000000h: FF D8 FF E0 00 10 4A 46 49 46 00

For a fast scan you just have to check the first 20 or so bytes like in your other detection routines for gif/png for the occurence of hex[00 10 4A 46 49 46 00] wich is the block marker.(see attached file)

But im not sure about it.have to read more about jpeg-format.

greetings david

once again me, i found an interesting function for changing color depth without a big buffer. look for "Floyd Steinberg Dithering".There are a lot of code samples around. It seems it can be used also line by line.

The RAM problem reminds me of my 386 with 4MB RAM...coding in QuickBasic... 64 kb of addressable ram.I tried image processing...it sucks!

david

Now that is handy. I'm updating just that bit of code no to use a different jpeg library. Thanks!

It also says: << you can identify a JFIF file by looking for the following sequence: X'FF', SOI, X'FF', APP0, <2 bytes to be skipped>, "JFIF", X'00'. >>

I've just uploaded 0.4-beta1 which has image support as described in comment #2!

Re: bit depth - the images are stored/rendered as RGB15 (15-bit RGB, NDS native format in mode 5) and are shrunk-to-fit on a per-row basis. The actual rendering "widget" only ever knows about the shrunk image. As such, there's currently no way to "zoom" an image, which is a bit lame but it was easier to do it this way.

Feedback's always welcome!