Tired of having to convert pictures to proprietary and inconvenient formats to view them on your Prizm? This add-in will certainly help you get rid of that pain! This is a picture viewer that supports the JPEG and PNG formats, which means that you'll be able to view most images on your Prizm without having to convert them to g3p.

It uses TJpgDec for decoding JPEG and zlib+libpng for decoding PNG. The PNG decoding part is based on ProgrammerNerd's great work on making a rudimentary PNG viewer. He also helped getting zlib and libpng to compile.

TJpgDec homepage: http://elm-chan.org/fsw/tjpgd/00index.html
zlib homepage: http://zlib.net/
libpng homepage: http://libpng.org/pub/png/libpng.html

The add-in remembers the last image being viewed, if any, and tries to recall it when the add-in is opened.

Supported files:
Baseline JPEG files with size up to 65520 x 65520 pixels are supported. Progressive or lossless JPEG not supported. Make sure to uncheck the "Progressive" option when exporting from GIMP, for example.

All non-interlaced PNG files should be supported. There are no limits on height (other than 4-byte integer limits and time constraints); for width, one should be fine if it doesn't exceed 5000 pixels.

Controls:
When viewing an image, use the "replay" D-pad for navigating in the image 64 pixels on the selected direction; use the 2,4,6 and 8 keys as a D-pad for navigating a whole screen down, left, right or up (think of the effect of Page Down and Page Up on a computer). Keys 1, 3, 7 and 9 can be used to navigate diagonally in a similar fashion.

When viewing a JPEG picture, press minus to zoom out, and plus to zoom back in.

When viewing a PNG picture, press minus to switch to the fit-to-screen mode, and plus to go back to the no-scaling mode.

eActivity strip mode:
Note that the picture files are not included in the eActivity itself, as it happens with g3p pictures; the strip acts more like a link. So, if you move or delete pictures in the storage memory, the links will break. Same goes if you copy the file to another calculator without keeping the absolute paths for the images.

To select a picture for a strip, open a image viewer strip, view an image and then switch back to the eActivity document (press Shift then the "Store" -> key above AC/On).

Download
Download v1.1 (g3a only): http://tny.im/ivcp
Nice ZIP with read-me and license: http://tny.im/prImageZipDL

The add-in is licensed under the BSD 2-clause license.
Please give feedback.

Screenshots:



---
Original post for historical purposes: http://tny.im/14D

I'm trying to load an image, but it keeps saying "fail 1 - status diff"

The message gets cut off at the end.

Try another image file.

It keeps saying the same thing. With all my pictures.

I'll have a look. Are you sure your pictures are not progressive JPEG?

I tried using jpeg, but it didn't even show up in the files. All of mine are .jpg files.

But they aren't progressive JPEG, do they?
This is an example of a compatible JPEG file: http://s.lowendshare.com/0/1357767852.513.bridge.jpg

I think they were progressive. I got it to work. It is a nice program. What other things are you going to do with it?

I'll try to implement zooming out for a factor of 50%, so people can get a better overview of larger images. This means I'll have to mess with the decoder code, something I'm not very motivated to do. Right now my priority is speed up decoding so it becomes usable at the standard CPU rate of 58 MHz.

Presenting the first eActivity-strip enabled non-Casio-made add-in:
Image Viewer Beta 2!

The only new thing in this new version is the eActivity strip, which lets you embed shortcuts to JPEG images on your eActivity notes.

The add-in does this by saving in the main memory what is the image currently being viewed. Because each eActivity strip has its own main memory, this lets you open a different image per strip. This also means that when accessing the add-in through the main menu, you'll see the image you were seeing at the time you left the add-in (or the file browser if you weren't viewing an image).

Remember that the eActivity strips are just like shortcuts to the images: if you delete or rename an image from the storage memory, it will no longer be available from inside the eActivity file (in case of rename, you can always browse to the image's new location and open it...). It's not like g3p pictures which get embedded in the activity, greatly increasing its size (and doubling and tripling the used memory if you want to have the same image on multiple files).

Now keep in mind that when sharing eActivity files containing JPEG image viewer strips, you'll also need to share the image viewer and the images, and make sure the images are put in the same absolute location as on the calculator you created the activity with.

Ah, and download here: http://tny.im/ivcp

Screenshots:
An activity with some strips...


This is how the strips will look like on a calculator which doesn't have the image viewer add-in installed:

That is beautiful work! I need to find out how you do that; I'd love to make Graph3DP have eActivity-enabled strips that load custom graphs. I don't suppose this is documented anywhere, for example in SimonLothar's elusive CHM file?

Indeed, I'd like to find out how you did it as well. I know you had asked me about mkg3a's eActivity support somewhat recently (and I guess it was able to do what you want?) but it would be nice to document it somewhere and maybe create a few tools to simplify the process.

I modified the source code of the beta1 of mkg3a in order to support eAct strips. No, not even Simon got something as obvious as this right.

Apart from the additional languages and monochrome/3 color icon (turns out it's 3-color even though the OS only uses black) Tari and Simon both documented (in varying degrees of spelling and grammar, and in various mediums, from a C header file to an ancient Windows help file format), there was something very obvious I found out when comparing the headers of Casio's strip-enabled add-ins and our add-ins.
The byte at 0x12b in the header (just before the version number) needs to be set to 0x01 for the OS to know the add-in has a strip... Tari previously thought this was part of some padding, but it isn't. Now, who knows that the remaining "padding" bytes are hiding from us...

My modifications to mkg3a are very hackish, plus they were done on an old source code release. It works for me but it's not something I'd like to see go to the official code tree. So either give me time to implement it properly or implement it yourself.

Apart from that, there's (or at least there was, in the fx-9860Gs) a parameter that says if the add-in is launched from the Menu or from a strip... even though I don't need this for this add-in, it'd be good if someone found out how that works...

Process switching within those strips works just fine without any code modification, you only need to use GetKey. When process-switching, the whole stack is preserved (I know this because I use almost all of it on this add-in, for caching images in memory). Didn't check the heap (as I said before, I really don't like Casio's malloc and friends).

Each strip has its own main memory (and of course setup), which is stored in the eActivity file. Since files have a size limit of about 30 KB (not including g3p pictures), the main memory usage is more or less faked to give the guest add-in the impression 34-36 KB of it are already in use. If you decide to fill the main memory provided to a strip, there won't be any space left for eActivity root content or other strips. This is actually documented in the Prizm's software manual, of course with user friendly terms. There's also a function to see how much of a file the strip is taking with its main memory: when the cursor is on a strip, do File[F1]->Size[F5]

I'm busy with school and I added this strip functionality in a hurry because a friend of mine can't open g3p files embedded inside eActivities with her calculator (the outside says it's a CG-20, the main board has been replaced and when I updated to OS 1.04 the OS version string became 01.04.3200, instead of the usual 01.04.0200 of CG-20s). I also like using JPEG images much more than g3p (unlimited image dimensions, easy to convert...) but they couldn't be pointed to from an eActivity document... here's my solution

Just tried it with 800x600 jpg, works awesome, thank you.
Could you also handle 1,3,7,9 keys to do the diagonal scrolling, please?

Is there a chance for .png suport?
I have several clean, almost pixelart diagrams, that i wanted to have on a calc. After conversion they oncreased in size 3-10 times, plus noticeable jpg artifacts. Still visible and readable, but would be nice to have it natively.

Yes, later.



No. PNG decoding takes too much resources (it can't be read sequentially like JPEG). It's been tried before, and only images under 100x100 fit in memory, which is useless.

this is probably a stupid question, but how can I put this on my calculator (Casio fx-CG 20)?

See http://www.cemetech.net/forum/viewtopic.php?t=7549

Basically, connect the calculator to the computer and copy the .g3a file to it. Then safe disconnect the calculator and the add-in should now appear on the Main Menu.

A new and put together from scratch version of my JPEG viewer is being worked on here: https://github.com/gbl08ma/imageviewer

This new version will use TJpgDec instead of Picojpeg due to compatibility issues of the latter with new GCC versions. Also, my previous source code tree is really messed up and I can't make it work properly anymore. Doing things again is really the best option.

The new project can already do everything the old versions did, including the eActivity strip function. It uses a special on-chip RAM area as working RAM for TJpgDec, in hopes of achieving better speed. This should pose no risk to calculators, but more testing needs to be done. If you want to beta-test, drop me a line.

My Utilities add-in might also see a v1.5 version with built-in JPEG viewing. However, assuming I don't change anything else, there would be no reason to update to it if one doesn't want the JPEG viewing part - as I said before, Utilities is a finished project.

TJpgDec instead of Picojpeg

Are these different libraries of sorts?