Add Images

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by richard.quirk on 1 Oct 2007 at 9:15

[GoogleCodeExporter]

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

Original comment by danielro...@gmail.com on 2 Oct 2007 at 1:12

[GoogleCodeExporter]

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!

Original comment by richard.quirk on 2 Oct 2007 at 7:04

[GoogleCodeExporter]

I like the way you think, man.

Original comment by abem...@gmail.com on 2 Oct 2007 at 8:14

[GoogleCodeExporter]

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

Original comment by danielro...@gmail.com on 2 Oct 2007 at 10:11

[GoogleCodeExporter]

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

Original comment by coolk...@gmail.com on 4 Oct 2007 at 12:03

[GoogleCodeExporter]

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.

Original comment by richard.quirk on 17 Oct 2007 at 7:16

• Changed state: Started

[GoogleCodeExporter]

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

Original comment by mul...@gmail.com on 19 Oct 2007 at 12:59

Attachments:

• Jfif.txt

[GoogleCodeExporter]

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

Original comment by mul...@gmail.com on 19 Oct 2007 at 1:22

[GoogleCodeExporter]

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'. >>

Original comment by richard.quirk on 19 Oct 2007 at 5:20

[GoogleCodeExporter]

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!

Original comment by richard.quirk on 29 Oct 2007 at 9:06

[GoogleCodeExporter]

Original comment by richard.quirk on 29 Oct 2007 at 9:06

• Changed state: Fixed-release