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.
Comment #1
Posted on Oct 2, 2007 by Quick RhinoJust a question richard, when you say "is not to show all images" what this mean? I'm a little bit confused with it :)
Comment #2
Posted on Oct 2, 2007 by Helpful ElephantNot 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!
Comment #3
Posted on Oct 2, 2007 by Swift BirdI like the way you think, man.
Comment #4
Posted on Oct 2, 2007 by Quick RhinoThat's a nice way to view images on the browser, good work!
Comment #5
Posted on Oct 4, 2007 by Swift RhinoIf 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
Comment #6
Posted on Oct 17, 2007 by Helpful ElephantTo 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.
Comment #7
Posted on Oct 19, 2007 by Happy OxHello 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
- Jfif.txt 14.95KB
Comment #8
Posted on Oct 19, 2007 by Happy Oxonce 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
Comment #9
Posted on Oct 19, 2007 by Helpful ElephantNow 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'. >>
Comment #10
Posted on Oct 29, 2007 by Helpful ElephantI'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!
Comment #11
Posted on Oct 29, 2007 by Helpful Elephant(No comment was entered for this change.)
Status: Fixed-release
Labels:
Type-Enhancement
Priority-Medium
Milestone-0_4
Component-Bunjalloo