DOS ain't dead

As requested by Laaca and Zyzzle: DosView, an image viewer/converter cobbled together from DOjS code.

https://github.com/SuperIlu/DosView

I'm taking contributions/suggestions on what to add...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> As requested by Laaca and Zyzzle: DosView, an image viewer/converter
> cobbled together from DOjS code.
>
> https://github.com/SuperIlu/DosView
>
> I'm taking contributions/suggestions on what to add...
Thank you! Does Allegro support 32-bit VESA modes? If so, may I suggest making 640x480x32 the default viewing mode instead, as modern cards and built-in video BIOSes of modern systems don't even support the 640x480x24 mode (no entry in it for the VESA modes in the vBIOS).

> Thank you! Does Allegro support 32-bit VESA modes? If so, may I suggest
> making 640x480x32 the default viewing mode instead, as modern cards and
> built-in video BIOSes of modern systems don't even support the 640x480x24
> mode (no entry in it for the VESA modes in the vBIOS).

Try the "-b" flag as stated by the documentation. That switches to 32bpp...

And I might make that the default, yes...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

I would like you to also offer the compiled executable program for ms-dos (dosview.exe)

> I would like you to also offer the compiled executable program for ms-dos
> (dosview.exe)

uhm, it is right there, on the releases page?
https://github.com/SuperIlu/DosView/releases

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> As requested by Laaca and Zyzzle: DosView, an image viewer/converter
> cobbled together from DOjS code.
>
> https://github.com/SuperIlu/DosView
>
> I'm taking contributions/suggestions on what to add...

For a quick hack, this works rather well. I did a quick test with webp, qoi and png and it worked pretty well.

Some observations:
* Under DOSBoX-X, it requires -b to work
* Large images might be better shown scalled down to the size of the viewable area. Scrolling the image up and down is rather slow under emulator.
* An info line with some basic information about images might be useful. Or, alternatively, the info about the image might be shown under text mode after exit.

Well, everything else would be overkill for what you wanted it to be and do.

> > I would like you to also offer the compiled executable program for
> ms-dos
> > (dosview.exe)
>
> uhm, it is right there, on the releases page?
> https://github.com/SuperIlu/DosView/releases


Thank you very much

Works fine... but in native/real/true/pure MS-DOS 6.00 tests, dosview requires -b to work

Fantastic work! Thank you.
Maybe could be changed the image conversion mode. In this mode is no need to check whether video card supports 24bpp or 32bpp. It shall just convert it without trying to activate or check any videomode.
It would be also good to have an option how to force the input image format.
Lets say I have a WEBP encoded image with extension WBP.
And it would be good to have the possibility to call something like

"DOSVIEW -b -f webp IMAGE.WBP"

---
DOS-u-akbar!

> * Under DOSBoX-X, it requires -b to work
I'll add autodetection to the next version...

> * Large images might be better shown scalled down to the size of the
> viewable area. Scrolling the image up and down is rather slow under
> emulator.
try "Z" and "F" to switch between scaled and full size view

> * An info line with some basic information about images might be useful.
> Or, alternatively, the info about the image might be shown under text mode
> after exit.
I'll check what I can do...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> Fantastic work! Thank you.
> Maybe could be changed the image conversion mode. In this mode is no need
> to check whether video card supports 24bpp or 32bpp. It shall just convert
> it without trying to activate or check any videomode.
I don't know if allegro supports image read/write w/o a video mode, I'll check

> It would be also good to have an option how to force the input image
> format.
sorry, this is not easily supported by allegro. the 'detection' is purely based on the extension...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> Works fine... but in native/real/true/pure MS-DOS 6.00 tests, dosview
> requires -b to work
I'll add autodetection with the next version

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> try "Z" and "F" to switch between scaled and full size view
>
> > * An info line with some basic information about images might be
> useful.
> > Or, alternatively, the info about the image might be shown under text
> mode
> > after exit.
> I'll check what I can do...
I've been using it a lot and have a couple of more (I think, easy to implement suggestions):
1. When invoked with /h or /? print the keybindings as well as the other help you're already printing (ie, pgup, pgdown zoom, Z and F full size and actual, etc)
2. When using the -s option, don't do any autochecking for resolution at all (eg, when I just want to convert from .PNG to .WEB I shouldn't need to specify -b or any valid resolution, the program should just convert to the image format requested without checking for any valid video modes or VESA modes, etc)

2a. The specified keys to "move up or down within the image" don't work on my system. I tried the UP,DOWN,LEFT,RIGHT arrow keys *and* the numlock tenkey equivalents, and I can't scroll the image while in "actual size" mode. Is this what is intended by the "scroll right and left within image" keys you listed?

3. On my systems, the "list known available modes" lists modes which don't exist in my video BIOS, and when tried to change to these modes, I get "mode not supported error". For example, the valid VESA modes on my system are 640x480, 800x600, 1024x768 and 1920x1080, but the detected modes are only 320x240 (doesn't exist in my vBIOS), 640x480,800x600, and 1280x960 (not a valid mode in my vBIOS VESA table!)
4. As you said, I don't think Allegro supports changing to a mode which it thinks is unavailable (eg, 1920x1080x32, which *is* available on my laptop Intel vBIOSes in pure DOS), but is there any way to "fool" Allegro into thinking a user-specified VESA resolution mode may be used? Sort of a "custom" VESA mode, with the assumption that the user knows what he is doing.

Otherwise, your program is very powerful and fast! Its webp images are perfect!

> 1. When invoked with /h or /? print the keybindings as well as the other
> help you're already printing (ie, pgup, pgdown zoom, Z and F full size and
> actual, etc)
done

> 2. When using the -s option, don't do any autochecking for resolution at
> all (eg, when I just want to convert from .PNG to .WEB I shouldn't need to
> specify -b or any valid resolution, the program should just convert to the
> image format requested without checking for any valid video modes or VESA
> modes, etc)
doesn't work, allegro needs a screen mode.

> 2a. The specified keys to "move up or down within the image" don't work on
> my system. I tried the UP,DOWN,LEFT,RIGHT arrow keys *and* the numlock
> tenkey equivalents, and I can't scroll the image while in "actual size"
> mode. Is this what is intended by the "scroll right and left within image"
> keys you listed?
weird, I added the number keys

> 3. On my systems, the "list known available modes" lists modes which don't
> exist in my video BIOS, and when tried to change to these modes, I get
> "mode not supported error". For example, the valid VESA modes on my system
> are 640x480, 800x600, 1024x768 and 1920x1080, but the detected modes are
> only 320x240 (doesn't exist in my vBIOS), 640x480,800x600, and 1280x960
> (not a valid mode in my vBIOS VESA table!)
I added a check in "-l"

> 4. As you said, I don't think Allegro supports changing to a mode which it
> thinks is unavailable (eg, 1920x1080x32, which *is* available on my laptop
> Intel vBIOSes in pure DOS), but is there any way to "fool" Allegro into
> thinking a user-specified VESA resolution mode may be used? Sort of a
> "custom" VESA mode, with the assumption that the user knows what he is
> doing.
maybe later

check out v1.1
https://github.com/SuperIlu/DosView/releases/tag/v1.1

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

I just released an improved version v1.1

https://github.com/SuperIlu/DosView/releases/tag/v1.1

* added TIFF
* added JPEG 2000
* fixed zoom and documentation
* added 24/32bpp autodetection
* added image info
* added num pad keys
* added check to list modes

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

"old" dosview.exe version v1.0 = 911872 bytes

Dosview.exe version v1.1 = 1480192 bytes
( https://github.com/SuperIlu/DosView/releases/download/v1.1/dosview-1.1.zip )

But... with latest UPX and "--ultra-brute"
( https://github.com/upx/upx/releases/download/v4.2.1/upx-4.2.1-dos.zip )

=> dosview.exe version v1.1 = 591164 bytes !!!


In my first tests, I have problems with num pad keys

> Dosview.exe version v1.1 = 1480192 bytes
yeah, the modern codecs are quite something

> But... with latest UPX and "--ultre-brute"
> ( https://github.com/upx/upx/releases/download/v4.2.1/upx-4.2.1-dos.zip )
> => dosview.exe version v1.1 = 591164 bytes !!!
yeah, but the main problem would be the memory consumption during runtime and UPX sadly does not reduce that.

> In my first tests, I have problems with num pad keys
can you elaborate?
I must admit I didn't thoroughly test these(*)...


(*) as I didn't with the whole project

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

Nice!
I wanted to suggest you that it would be cool to somehow merge your code with the JPEG2000 by Khursaw (discussion here) but you already did it!

---
DOS-u-akbar!

> Nice!
> I wanted to suggest you that it would be cool to somehow merge your code
> with the JPEG2000 by Khursaw (discussion
> here)
> but you already did it
I did try OpenJPEG, too. But the API/documentation was atrocious and then I discovered libjasper which seems to work...

Jpeg XL and HEIC are on my list...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> Nice!
> I wanted to suggest you that it would be cool to somehow merge your code
> with the JPEG2000 by Khursaw (discussion
> here)
> but you already did it!
That was on my mind as well, and I didn't want to get "greedy" suggesting more "modern" formats, but SuperIlu read our minds! That JPEG2k discussion was quite the learning experience.

This is turning into quite the killer DOS viewer program.

I didn't even know OpenJPEG had (DOS-compilable) source available. So, it appears that will soon be added (or already has?) along with JPEG2k. Congrats.

I don't have any openJPEG files to test, but will soon remedy that.

> allegro needs a screen mode.

Shouldn't SYSTEM_NONE eliminate the need for that?

> I just released an improved version v1.1
>
> https://github.com/SuperIlu/DosView/releases/tag/v1.1
>
> * added TIFF
> * added JPEG 2000
> * fixed zoom and documentation
> * added 24/32bpp autodetection
> * added image info
> * added num pad keys
> * added check to list modes
Many thanks for all the new options.

Now, both arrow keys and number keys work well for me verses v. 1.0. And, the 8x speed option to move around in the image is very nice indeed.

One other minor point: it appears the -q option is somehow not uniform. It is not linear, at any rate. For .jp2 writing, it appears that anything from -q 50 to -q 100 will write a *lossless* image. -q 1 to -q 49 writes some sort of lossy image with .JP2, but it is not granular. I suggest to change the *default* -q to -q 100 which would be lossless for all three formats: .JPG, .JP2, and .WEB. I know lossless .JPG is a thing, even though it's seldom used.

The -q option for .JPG and .WEB is confusingly more granular than than with .JP2. For JPG and WEB it behaves as you'd expect (ie, -q 5 is a very poor lossy compression, while -q 95 is a very good lossy compression).

If you prefer to keep default -q at -q 95, then write lossy .JP2 by default. It'll avoid confusion. But, personally, I prefer the -q 100 as a pure lossless default to write only lossless images.

> > allegro needs a screen mode.
>
> Shouldn't SYSTEM_NONE eliminate the need for that?

thanks, I'll try that. I was only aware of allegro_init() and not install_allegro().

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> Now, both arrow keys and number keys work well for me verses v. 1.0. And,
> the 8x speed option to move around in the image is very nice indeed.
Try combining the SHIFT, CTRL and ALT keys for even more movement :)

> One other minor point: it appears the -q option is somehow not uniform. It
> [...]
> pure lossless default to write only lossless images.
I don't do anything but pass the -q value to the different encoders. what they do with that is not in my responsibility :)

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> I don't do anything but pass the -q value to the different encoders. what
> they do with that is not in my responsibility :)
OK, fair enough!

> Jpeg XL and HEIC are on my list...
Do you mean this?
https://github.com/libjxl/libjxl

JPEG XL is brand new (2021) image codec, and supports a lossless mode nearly twice as good as .PNG -9. See:
https://old.reddit.com/r/jpegxl/comments/17o43g2/ran_a_few_speed_and_size_tests_now_that_apple/

This github code looks pretty diffcult or impossible to actually compile under DGJPP. But if you can manage it, you're quite the coding god.

> > Jpeg XL and HEIC are on my list...
> Do you mean this?
> https://github.com/libjxl/libjxl
yeah

> This github code looks pretty diffcult or impossible to actually compile
> under DGJPP. But if you can manage it, you're quite the coding god.
I haven't taken a good look at it, just put it on my todo list :)

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> > allegro needs a screen mode.
>
> Shouldn't SYSTEM_NONE eliminate the need for that?

I tried that, but apparently SYSTEM_NONE does not set the '_rgb_X_shift_32' global variables correctly. these seem to be only valid after a screen mode was set.

I'll check some other ideas, but for now my implementation relies on these being set correctly...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

I added RAS and NetPBM formats and you can now scale images by a given factor..
https://github.com/SuperIlu/DosView/releases/tag/v1.2

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

I think it would be good if the program supports the "GIF" graphic format.

And with lower priority, it also supports the graphic formats RLE, CDR, PIC, IMG and CLP.

> I think it would be good if the program supports the "GIF" graphic format.

I would second this request. GIF used to be a standard (in the creaky olden days!), and i have tons of important GIF files collected over the years. It would be quite cumbersome to try and convert them all to some other format. Thanks for considering this.

- Doug B.

As per request:
* added GIF
* added PSD
* added HDR
* added PIC
* added an UPX compressed EXE
* enabled dithering
* added 8bpp display mode
* fixed another scaling error
* fixed error when reading certain PNGs

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> As per request:
> * added GIF
...
> * added an UPX compressed EXE
> * enabled dithering
> * added 8bpp display mode

Great Are arithmetic coding for JPG and all fancy algorithms of TIFF already supported? Or various exotic styles of PCX and BMP?

Thanks for DosView! Eric

---
FreeDOS / DOSEMU2 / ...

> Great Are arithmetic coding for JPG and all fancy algorithms of TIFF
> already supported? Or various exotic styles of PCX and BMP?
if the authors of the codecs did implement it, yes :)

neither of these were done by me, I just plumbed existing stuff together

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> As per request:
> * added GIF
> * added PSD
> * added HDR
> * added PIC
> * added an UPX compressed EXE
> * enabled dithering
> * added 8bpp display mode
> * fixed another scaling error
> * fixed error when reading certain PNGs
Getting better and better with all of these new features, especially scaling. How could we have forgotten .GIF? Glad to see the support of this legacy format. I also request the old .RLE compression format if easy to implement.

Incidently, is the dithering you're doing nearest color, neural net, diffusion-based, or some other algorithm? There are many different types of 24 bit --> 8 bit dithering.

Again, thanks for putting together DosView; it fills a great niche.

> As per request:
> * added GIF
> * added PSD
> * added HDR
> * added PIC
> * added an UPX compressed EXE
> * enabled dithering
> * added 8bpp display mode
> * fixed another scaling error
> * fixed error when reading certain PNGs


Congratulations!!! This new version exceeds our expectations

> ... How could we have forgotten .GIF?

The GIF graphic format can still be very useful for making some web page images "very light".

And it can be seen without problems by some not very modern browsers, such as Arachne and Netscape 3.04

> legacy format. I also request the old .RLE compression format if easy to
> implement.
Do you know of a codec somewhere?

> Incidently, is the dithering you're doing nearest color, neural net,
> diffusion-based, or some other algorithm? There are many different types of
> 24 bit --> 8 bit dithering.
I don't know. I just use the dithering that comes with allegro.

I haven't implemented a single file format or anything related to scaling/dithering myself. I just use whats there :)

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> Congratulations!!! This new version exceeds our expectations

there seem to be some problems with displaying portrait or weirdly sized images.
I need to have a look into that when I find the time...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> > legacy format. I also request the old .RLE compression format if easy to
> > implement.
> Do you know of a codec somewhere?
Not sure if this code can be useful or applied to this DosView project:
https://github.com/powturbo/Turbo-Run-Length-Encoding

There's also an interesting thread (with some other links within) on the Compuserve .RLE image format at VOGONS:
https://www.vogons.org/viewtopic.php?f=5&t=81297&p=1097913&hilit=dos%20do%20rle#p1097913
One of the members in that post actually wrote a DOS program to view .RLE files. Link:
http://brutmanlabs.org/RLE/RLE_Graphics.html

> One of the members in that post actually wrote a DOS program to view .RLE
> files. Link:
> http://brutmanlabs.org/RLE/RLE_Graphics.html
Interesting, I might dive into that when I find the time...

There are several other RLE formats, e.g. the Utah Raster Toolkit. So I was not sure which one we were talking about.

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> > One of the members in that post actually wrote a DOS program to view
> .RLE
> > files. Link:
> > http://brutmanlabs.org/RLE/RLE_Graphics.html
> Interesting, I might dive into that when I find the time...
>
> There are several other RLE formats, e.g. the Utah Raster Toolkit. So I was
> not sure which one we were talking about.

It's a simple format, but I don't think I'd go through the effort to add support for it. There are almost no Compuserve RLE files in the wild; I had to look hard to find the samples that I have on that page. It was fun to add to a Telnet client to try to give a taste of what Compuserve was like, but it really has very limited use.

>
> It's a simple format, but I don't think I'd go through the effort to add
> support for it. There are almost no Compuserve RLE files in the wild; I
> had to look hard to find the samples that I have on that page. It was fun
> to add to a Telnet client to try to give a taste of what Compuserve was
> like, but it really has very limited use.

Kinda' like the waste of effort it would be to
bother adding finger & gopher to a 'modern' browser ?

---
--
http://glennmcc.org/

> >
> > It's a simple format, but I don't think I'd go through the effort to add
> > support for it. There are almost no Compuserve RLE files in the wild; I
> > had to look hard to find the samples that I have on that page. It was
> fun
> > to add to a Telnet client to try to give a taste of what Compuserve was
> > like, but it really has very limited use.
>
> Kinda' like the waste of effort it would be to
> bother adding finger & gopher to a 'modern' browser ?
Well, *converting* existing images to .RLE format might get interesting! Or, implementing a simple Run-length encoding compression to satisfy the .RLE conversion from .BMP, for example.

> Kinda' like the waste of effort it would be to
> bother adding finger & gopher to a 'modern' browser ?


That's why we call this a hobby.

Hi,
I proposed DosView for adding it in a FreeDOS Trial version and got the feedback that he will do this only if it is wished by a lot of users. Reason: CD is almost full. So it is up to you to decide what to do.
Till now I had no time to test it, so I know nothing about it.

Of course, it should be included to FreeDOS CD.
It is a unique program, not big at all and it is actively maintained.

---
DOS-u-akbar!

> Hi,
> I proposed DosView for adding it in a FreeDOS Trial version and got the
> feedback that he will do this only if it is wished by a lot of users.
> Reason: CD is almost full. So it is up to you to decide what to do.
> Till now I had no time to test it, so I know nothing about it.

Since virtually everything on the web no-a-days requires HTTPS access,
I would suggest dropping Arachne from the FreeDos distro.

That would free-up a TON of space for adding DosView
and a whole bunch of other stuff.

---
--
http://glennmcc.org/

> Hi,
> I proposed DosView for adding it in a FreeDOS Trial version and got the
> feedback that he will do this only if it is wished by a lot of users.
> Reason: CD is almost full. So it is up to you to decide what to do.
> Till now I had no time to test it, so I know nothing about it.

It would be nice to have it on the CD alongside DOjS, but I should fix the aspect ratio/zoom bug first and right now I'm not sure when I have the energy to try to understand how to get it working properly...

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> Since virtually everything on the web no-a-days requires HTTPS access,
> I would suggest dropping Arachne from the FreeDos distro.

The web says there is a workaround where Arachne uses curl or wget to fetch HTTPS content, then displays it? With UPX, DosView is quite small, so there should be other ways to fit it on the CD?

---
FreeDOS / DOSEMU2 / ...

> It would be nice to have it on the CD alongside DOjS, but I should fix the
> aspect ratio/zoom bug first and right now I'm not sure when I have the
> energy to try to understand how to get it working properly...
Are you referring to a DosView aspect ratio bug? I did notice when I view very large images that the aspect ratio is incorrect, due to Allegro not detecting my useable 1920x1080 VESA mode (it only detects as high as 1280x1024, which is 1.25:1 stretched on a 1.7777:1 laptop monitor screen). So, if there someway to detect additional VESA modes, will this fix that bug?

Or are you referring to a completely different AR bug? Sometimes large images don't fit completely on screen when Zoom Out mode is selected in DOSView. The bottom is cut off / they only partially display. These large images do display fully when ZOOMed and scrolled, however.

> > Since virtually everything on the web no-a-days requires HTTPS access,
> > I would suggest dropping Arachne from the FreeDos distro.
>
> The web says there is a workaround where Arachne uses curl or wget to fetch
> HTTPS content, then displays it? With UPX, DosView is quite small, so there
> should be other ways to fit it on the CD?

Nope... neither of the wget APMs work anymore for getting Arachne to
'fudge it's way around' grabbing an HTTPS page.
(and neither of them ever worked correctly for submitting forms via HTTPS)

---
--
http://glennmcc.org/