PNGView

By Grauw

Ascended (9500)

Grauw's picture

03-02-2018, 20:26

Hi all,

Since I showed a couple of people at the Nijmegen fair, I might as well publicly release the code for my PNG viewer:

http://www.grauw.nl/projects/pngview/

It’s actually a year-old project, and still in an alpha state, but nice to get it out there anyway. It currently supports PNG files which are stored progressively (most of them), including those with transparency. Since no scaling is applied to the output, it works best with images of size 256x212 or smaller. Beware that because it first decompresses the PNG fully before showing it, it can be very memory hungry.

TODO / wishlist:

  • Support PNG “interlaced” storage mode (to be fully spec compliant)
  • Reduce memory requirement to 64K
  • Support screen modes other than screen 8
  • Scale large images (currently shows top left corner)
Login or register to post comments

By Grauw

Ascended (9500)

Grauw's picture

03-02-2018, 20:57

Oh, and it requires DOS2.

(So memory requirement can never be reduced to 64K Big smile, but aiming for 128K.)

To elaborate a little on the memory requirement; since PNG uses deflate compression I could reuse the gunzip decompression code, but since that code was built to decompress the entire file in one go, it’s not set up to decompress it in smaller chunks. So that’s why it needs enough memory to fully decompress the file before it can show it. I plan to use continuations[1] to allow me to decompress the file on the fly so that it doesn’t first need to read it fully, which would mean just the standard TPA space of 64K would be enough, but I focused first on getting it to work rather than optimising memory usage :).

[1] As for using continuations to stream the data decompression, it means to give the decompression routine its own stack pointer and heap, and when I request a block of data from it, it will populate the output buffer until it reaches its capacity, at which point the decompressor state is stored on the stack and it switches back to the normal program stack, which will read from that buffer until it’s empty, etc.

By Meits

Scribe (6141)

Meits's picture

03-02-2018, 20:58

My dad once said (32 years ago when he bought our first MSX) that it was the computer with (this is what he said) "The connections to the future"... Dunno who told him this fancy line since he's nothing like that...

But here you have it... He was right all along...

By Manuel

Ascended (17328)

Manuel's picture

03-02-2018, 23:14

I think that was one of the Philips MSX marketing punchlines Smile

By sd_snatcher

Prophet (3401)

sd_snatcher's picture

04-02-2018, 14:24

In a word: A-W-E-S-O-M-E! One of the things I really missed when I was making the Pixel Art Preservation Collection was a good PNG viewer, to store special MSX images in a efficient manner, and also be easily used/edited on a modern PC without special viewers or plug-ins.

Here are some requisites and use cases for graphic formats I gathered when creating the collection. Hope it helps:

(Note: They're not specific to the PNG, but for any image format like MAG, MIF or MIG. I'm aware that not all requisites are viable on PNG.)

- Support to store/view native MSX images, without doing any resizing/stretching when this is the case. Proper screen-8 support is necessary too
- Automatic selection of the most suitable screen mode (plus interlace) to be used based on the bit depth and Pixel Aspect ratio of the image
- Store/View images smaller than the screen. Because .SCx requires you to save an entire screen even for a 32x32 image, and .GLx+.PLx has no MSX-DOS viewer
- Store/View images bigger than the screen, allowing vertical/horizontal scroll when needed
- Support for wildcards, so the images can be viewed as a slideshow. Better yet if it has recursive search too.
- Support for AcidSee-like pre-loading of the next image while the current image is being viewed
- Sprite support
- Map the transparent color to the color-0. This way the superimpose can be used on machines that have this feature.
- Background color support (used in the border and to fill unused areas)
- Export the image in the .SCx format (interlace support with .SCx+.S1x)
- Support to store/view some metadata like the author name and a text description

And some more advanced features:
- SCR10 & SCR12 support
- Multi-palette support, similar to .SRx+.PLx
- Animation support
- V9990 support
- MA-20 support

The viewer that currently support most (but not all) of these requisites nowadays is DMAG.COM

Screen-10 and Screen-12 support on MAG files was implemented using a clever idea, that is suitable to be reused for either GIF or PNG files. In a nutshell:

- There's a custom field in the header to indicate the MSX screen mode to be used (for GIF files, a GIF Application Extension could be used. And PNG files have support to store GIF Application Extensions)
- Screen-10 images are stored/loaded as screen-7 images, then YAE is activated after it's loaded
- Screen-12 images are stored/loaded as 256 color images, then YJK is activated after it's loaded. A palette is stored so the image can be viewed on machines that don't support YJK. Traditionally, the screen-8 palette was used, but I created a specially crafted palette that allows the YJK images to be viewed as grayscale on machines that don't have YJK. This is the result for a well-known screen-12 image: