DOS ain't dead

Hi,

I finished working on a new version of DUGL Viewer.
This is a prerelease version for test, and if there is no complains/bugs or small modification proposal, I will take it as an official release.

What's new :

- Redisigned the GUI.
- Added support for png image format using zlib and libpng
- Added three viewing mode : fit width, fit view and "As Is"(100% zoom)
and keyboard shortcut F6 to switch between viewing modes.
- Added support for better quality downsizing images.
- Added better image navigation using mouse drag, and mouse wheel (require CTMouse)
- Added about button and dialog
- Added more parameters inside the duglview.cfg
- ....


Can be downloaded from :
DUGL VIewer 0.4 prerelease (DOS compatible link)
DUGL Viewer 0.4 prerelease (mediafire link)

a beautful screenshot


As usually I'm waiting for tests and feedbacks small modifications can be done before the official release.

> I finished working on a new version of DUGL Viewer.

COOOOOOOOOOOOOOOOOOOOOOOOOOOOOL

> - Added support for png image format using zlib and libpng

(WeBP as next in 0.5 ?)

> - Added support for better quality downsizing images.

What exactly ? Gamma-correct Lanczos ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> COOOOOOOOOOOOOOOOOOOOOOOOOOOOOL



> (WeBP as next in 0.5 ?)

Why not ? what about GPL licensing issue ?

> > - Added support for better quality downsizing images.
>
> What exactly ? Gamma-correct Lanczos ?

Just a DUGL home-made algorithm

Image is blured with the same size then simply resized as usually
here a screenshot of the good enough result we can get.

> Why not ? what about GPL licensing issue ?

NO: http://groups.google.com/a/webmproject.org/group/webp-discuss/browse_thread/thread/5b8fe3ed39687eff

http://en.wikipedia.org/wiki/WebP

http://code.google.com/speed/webp/

http://jafile.com/uploads/dos386/dscn2350.wep
http://jafile.com/uploads/dos386/testtiny.wep

needs latest Opera :

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

hey !!!

Lot of improvements since last version!!
I was testing and the program is very complete now. Probably the unique DOS image viewer with "image fit on screen modes"

I was testing the quality downsizing images and also the images are much clear now (the old version without that feature was unusable for reading comics)

I just miss 2 features.... One is in queue ( full screen)

the other feature is:

Start the program with a full screen file navigator. Up/down/enter to browse and just press enter over a pic to star viewing it. (At moment I need to press lot of keys to open the file browser and load images)

make a fast GUI is necessary to make the program more user friendly


Anyway at moment this is my fav image viewer. I can delete Sea and other ones, because they lack on "fit modes" and "quality downsizing"

> NO:
> http://groups.google.com/a/webmproject.org/group/webp-discuss/browse_thread/thread/5b8fe3ed39687eff
>
> http://en.wikipedia.org/wiki/WebP
>
> http://code.google.com/speed/webp/
>
> http://jafile.com/uploads/dos386/dscn2350.wep
> http://jafile.com/uploads/dos386/testtiny.wep
>
> needs latest Opera :
>
>
>

Good thanks, seems that adding support for WebP is not hard for next version 0.5

>
> I was testing the quality downsizing images and also the images are much
> clear now (the old version without that feature was unusable for reading
> comics)

Good, according to my tests, we have a good quality downsize between 70% and 30% downsizing. what about your comics pics ?

>
> I just miss 2 features.... One is in queue ( full screen)
>

Yes.

> the other feature is:
>
> Start the program with a full screen file navigator. Up/down/enter to
> browse and just press enter over a pic to star viewing it. (At moment I
> need to press lot of keys to open the file browser and load images)
>
> make a fast GUI is necessary to make the program more user friendly
>

Not a small projet, it require as I guess a completely new dialog to allow this. I guess also if it should be enough for you to make a new file dialog with a preview image capability ?

>
> Anyway at moment this is my fav image viewer. I can delete Sea and
> other ones, because they lack on "fit modes" and "quality downsizing"

Great, you are the first DUGL Viewer customer
and thanks for all your suggestions and hints with DOS386 that helped me to make a more useful image viewer.

I try to run duglviewer in a Windows XP DOS Box and I always get "DUGL init error".

My suggestion is to tell the user what kind of error occured.

Georg

> I try to run duglviewer in a Windows XP DOS Box and I always get "DUGL init
> error".
>
> My suggestion is to tell the user what kind of error occured.
>

I agree, this is already on todo list of DUGL Core library to provide detailed error codes, but it has a very low prority as the user can already read on documentation that he require a DOS or 100% compatible OS, and this isn't the case of the dosbox of Windows XP.

> Good, according to my tests, we have a good quality downsize between 70%
> and 30% downsizing. what about your comics pics ?

they are readable.. and Im using a very tiny 7" wide screen ;)


> > Start the program with a full screen file navigator. Up/down/enter to
> > browse and just press enter over a pic to star viewing it. (At moment I
> > need to press lot of keys to open the file browser and load images)
> >
> > make a fast GUI is necessary to make the program more user friendly
> >
>
> Not a small projet, it require as I guess a completely new dialog to allow
> this.

Hey .. try opening the file dialog on program start and made it full scree size. Maybe thats easy to implement and its similar feature

>I guess also if it should be enough for you to make a new file dialog
> with a preview image capability ?

preview would be cool too ;) anyway at moment I would center into speed-up the image loading/resize time instead visual goodies (if possible)

> > Good, according to my tests, we have a good quality downsize between 70%
> > and 30% downsizing. what about your comics pics ?
>
> they are readable.. and Im using a very tiny 7" wide screen ;)
>
>
> > > Start the program with a full screen file navigator. Up/down/enter to
> > > browse and just press enter over a pic to star viewing it. (At moment
> I
> > > need to press lot of keys to open the file browser and load images)
> > >
> > > make a fast GUI is necessary to make the program more user friendly
> > >
> >
> > Not a small projet, it require as I guess a completely new dialog to
> allow
> > this.

Hey .. as workarround... can you set opening the file dialog on program start and made it full screen size?. Maybe thats easy to implement and it is a similar feature

> >I guess also if it should be enough for you to make a new file dialog
> > with a preview image capability ?

preview would be cool too ;) anyway at moment I would center into speed-up
the image loading/resize time instead visual goodies (if possible)

> > >I guess also if it should be enough for you to make a new file dialog
> > > with a preview image capability ?
>
> preview would be cool too ;) anyway at moment I would center into
> speed-up
> the image loading/resize time instead visual goodies (if possible)

How much time it takes for you to load/resize a picture ?
What if you disable [SmoothDownSize], by setting first value to '0' ?

> I try to run duglviewer in a Windows XP DOS Box and I always get "DUGL init
> error".
> My suggestion is to tell the user what kind of error occured.

I tried it and got this error too (even in DosBox emulator) but I don't care a lot, for DOS programs it's important how they work in real DOS. We know it's hard to fight against winnt restrictions so such erros is not a surprise. Maybe for correctness it should simply print that winnt is not supported.
In DJGPP I use this simple check
if (_os_trueversion==0x532)
// WinNT/2k/XP/Vista/7

BTW mouse wheel doesn't work for me in open dialog. I use
ctmouse.exe /3 /O
and wheel works in Arachne (i'll check if still do).

---
DOS gives me freedom to unlimited HW access.

> > > >I guess also if it should be enough for you to make a new file dialog
> > > > with a preview image capability ?
> >
> > preview would be cool too ;) anyway at moment I would center into
> > speed-up
> > the image loading/resize time instead visual goodies (if possible)
>
> How much time it takes for you to load/resize a picture ?
> What if you disable [SmoothDownSize], by setting first value to '0' ?

Nothing to worry about the speed. DUGL viewer is the fastest.

I was testing DUGL vs SEA.. SEA is very fast displaying images but it uses a trick:

- In DUGL the image is not displayed after it is fully rendered.
- In SEA the image appears instantly and you can see how image is being rendered from up to down.

Maybe this option to display the image while is being rendered in screen instead wait for the full render to finish would be nice addition :)

I think its better to show an image being rendered instead to wait with the "freezed" previous screen until the new image appear. (People can be confused and think that program is slow.. ) ;)

my computer: P166mmx 32MB ram

> I tried it and got this error too (even in DosBox emulator)

I guess the error on DosBox should be that DUGL Miss the MMX support and VESA 2.0

> In DJGPP I use this simple check
> if (_os_trueversion==0x532)
> // WinNT/2k/XP/Vista/7
>

Yes nice/simple check to add outside DUGL Core, on each application.

> BTW mouse wheel doesn't work for me in open dialog. I use
> ctmouse.exe /3 /O
> and wheel works in Arachne (i'll check if still do).

The GUI objects still do not support the mouse wheel, (it should be a nice addition to the GUI)
however, you can use the mouse wheel to scroll a big picture up/down, or to scroll a big picture left,right by pushing the left mouse button.

>
> Maybe this option to display the image while is being rendered in screen
> instead wait for the full render to finish would be nice addition :)
>
> I think its better to show an image being rendered instead to wait with the
> "freezed" previous screen until the new image appear. (People can be
> confused and think that program is slow.. ) ;)
>
> my computer: P166mmx 32MB ram

Don't laugh, this is a reasonable suggestion, even for modern computers. Even showing my aunts some pics on Facebook was fairly slow (on their AT&T DSL "Lite"). Perhaps the resolution was big, but it felt very reminiscent of old days using 2400bps modems and interlaced GIFs! Honestly, though, not sure what DUGL supports, but perhaps DOS386 can enlighten us, does PNG support interlacing? JPEG? BMP? (I think at least one of those also does.)

> > I tried it and got this error too (even in DosBox emulator)
>
> I guess the error on DosBox should be that DUGL Miss the MMX support and
> VESA 2.0

Presumably the (lack of) MMX since it already has VESA 2. Of course, since they already emulate FPU, it can't be too hard to extend to MMX. IIRC, there is a Linux MMX emulator's sources they could glean from. (Unlikely they will do this, of course, at least not soon, but who knows.) Their excuse will probably be something like, "Not enough games use it" or such.

> > In DJGPP I use this simple check
> > if (_os_trueversion==0x532)
> > // WinNT/2k/XP/Vista/7
>
> Yes nice/simple check to add outside DUGL Core, on each application.

Beware hardcoded version checks. I'm not saying you're wrong in this instance, but there's no easy way to override this (that I know of, does SETVER change this on WinXP??) in case whatever assumption is faulty (or would work with specific video drivers).

I'd rather you did strcmp(getenv("OS"),"Windows_NT") or similar. At least then the user could set / unset it manually if needed. Kludgy but better than nothing.

> >
> > Maybe this option to display the image while is being rendered in screen
> > instead wait for the full render to finish would be nice addition :)
> >
> > I think its better to show an image being rendered instead to wait with
> the
> > "freezed" previous screen until the new image appear. (People can be
> > confused and think that program is slow.. ) ;)
> >
> > my computer: P166mmx 32MB ram
>
> Don't laugh, this is a reasonable suggestion, even for modern computers.
> Even showing my aunts some pics on Facebook was fairly slow (on their AT&T
> DSL "Lite"). Perhaps the resolution was big, but it felt very reminiscent
> of old days using 2400bps modems and interlaced GIFs! Honestly,
> though, not sure what DUGL supports, but perhaps DOS386 can enlighten us,
> does PNG support interlacing? JPEG? BMP? (I think at least one of those
> also does.)

It's seems that both libjpeg and libpng allow to load images Progressively (not only for enterlaced images).
But as on my 5 years old system, it took only 3 seconds to load a huge jpeg image of ~ 11500x4500 I guess it's a very low priority modification.

>
> > > In DJGPP I use this simple check
> > > if (_os_trueversion==0x532)
> > > // WinNT/2k/XP/Vista/7
> >
> > Yes nice/simple check to add outside DUGL Core, on each application.
>
> Beware hardcoded version checks. I'm not saying you're wrong in this
> instance, but there's no easy way to override this (that I know of, does
> SETVER change this on WinXP??) in case whatever assumption is faulty (or
> would work with specific video drivers).
>
> I'd rather you did strcmp(getenv("OS"),"Windows_NT") or similar. At least
> then the user could set / unset it manually if needed. Kludgy but better
> than nothing.

Why we shoud have a way to overide WiNT check ? Any hope to get true VESA 2.0LFB in such OS ?
Any way, I can easily add a parameter on CFG file to enable/disable this check.

> Why we shoud have a way to overide WiNT check ? Any hope to get true VESA
> 2.0LFB in such OS ?

In this case, it's probably moot, but it probably depends on the driver quality (which varies). So unless you can be 100% sure that no driver supports VESA 2 under WinXP etc., I would make it optional.

> Any way, I can easily add a parameter on CFG file to enable/disable this
> check.

Just a friendly warning against hardcoded version checks. They always come back to bite you (e.g. MS-DOS 5 utils).

> > >
> > > Maybe this option to display the image while is being rendered in
> screen
> > > instead wait for the full render to finish would be nice addition :)
> > >
> > > I think its better to show an image being rendered instead to wait
> with
> > the
> > > "freezed" previous screen until the new image appear. (People can be
> > > confused and think that program is slow.. ) ;)
> > >
> > > my computer: P166mmx 32MB ram
> >
> > Don't laugh, this is a reasonable suggestion, even for modern computers.
> > Even showing my aunts some pics on Facebook was fairly slow (on their
> AT&T
> > DSL "Lite"). Perhaps the resolution was big, but it felt very
> reminiscent
> > of old days using 2400bps modems and interlaced GIFs!
> Honestly,
> > though, not sure what DUGL supports, but perhaps DOS386 can enlighten
> us,
> > does PNG support interlacing? JPEG? BMP? (I think at least one of those
> > also does.)
>
> It's seems that both libjpeg and libpng allow to load images Progressively
> (not only for enterlaced images).
> But as on my 5 years old system, it took only 3 seconds to load a huge jpeg
> image of ~ 11500x4500 I guess it's a very low priority modification.

3 secs is a lot of time!!! serious. The feeling is totally different if you have to wait or the image is loaded progressively.
* for comic reading its not an bad feature.. you can start reading the first lines without need to wait the 3 secs :)

>Their excuse will probably be something like, "Not enough games use it" or such.

Hehe, they told the same about CPUID, if I remember well, and now DOSBOX have CPUID instruction :) So wait some years and you'll get the MMX :)

---
DOS gives me freedom to unlimited HW access.

> Why we shoud have a way to overide WiNT check ? Any hope to get true VESA
> 2.0LFB in such OS ?
> Any way, I can easily add a parameter on CFG file to enable/disable this
> check.

I think so. It would have a sense if you have also VESA 1.2 bankswitch support that can (sometimes) run under NT OS and use it as fallback. Instead of autodetection I do it via cfg file.

---
DOS gives me freedom to unlimited HW access.

> It's seems that both libjpeg and libpng allow to load images Progressively
> (not only for enterlaced images).
> But as on my 5 years old system, it took only 3 seconds to load a huge jpeg
> image of ~ 11500x4500 I guess it's a very low priority modification.

BTW in case of viewing large images from a digital camera, there is usualy an embedded thumbnail - a small JPEG (maybe 320x200 or bigger) in EXIF header that can be displayed very fast while loading full image on background. But when image is processed in varius editors they usually remove thumbnails. It's just an idea for this specific case...

---
DOS gives me freedom to unlimited HW access.

> I think so. It would have a sense if you have also VESA 1.2 bankswitch
> support that can (sometimes) run under NT OS and use it as fallback.
> Instead of autodetection I do it via cfg file.

VESA 1.2 bankswitch do not allow normally high-speed rendering.
Any way, I have an idea to very fastly support bank switch !
just render into a memory Surf, and then just write a new function that copy the memory surf, to the bank switched video mode.
I guess like this we will not lose much speed !

What about the mouse wheel ? did it worked for you ? I was waiting for your final test to release the final DUGL Viewer 0.4.

> I try to run duglviewer in a Windows XP DOS Box
> and I always get "DUGL init error
> My suggestion is to tell the user what kind of error occured

if (Detect_DOS_Now()==false) /* then */ {
printf ("This program must be run in DOS mode");
abort();
}

> Honestly, though, not sure what DUGL supports, but perhaps
> DOS386 can enlighten us, does PNG support interlacing?

YES (2-dimensional) ... RTFS ("S"=spec)

> JPEG?

only rarely used ???

> BMP?

NO

> (I think at least one of those also does.)

GIF does (1-dimensional)

> Beware hardcoded version checks.

Why ???

> Why we shoud have a way to overide WiNT check ?
> Any hope to get true VESA 2.0LFB in such OS ?
> Any way, I can easily add a parameter on CFG
> file to enable/disable this check.

IMHO no point 3 x

> would have a sense if you have also VESA 1.2 bankswitch
> support that can (sometimes) run under NT OS

IMHO no point. VESA B***S*** 1.2 might be useful for 80386 compatible stuff, but not if DUGL needs MMX.

> JPEG (maybe 320x200 or bigger) in EXIF header that can
> But when image is processed in varius editors
> they usually remove thumbnails

Danger!!! Bad editors change main image and keep thumbnail. Malicious editors even allow to place a deliberately false thumbnail.

Tests:

+ it works

+ PNG works (interlace not tested ... 16 bppc not tested ... other silly stuff not tested)

- multiple masx works partially only, "see only JPG" is preselected (why?), there is no "see all supported files" (DUGLPLAY has same problem)

- shot feature is "old" - only one shot, only JPG, inherently lossy:



- buttons "prev" "next" "earliest" and "last" are "messed up"

- "multi-image" mode is strange and too complicated, idea to fix:

+ + Remove F3-vs-ALT-F3 and CFG entry on them
+ + Whenever loading an image, always remember full directory (all supported files, clamp to some reasonable value (10'000?))
+ + Add 4 modes (selectable besides "Fit View")
+ + + See all images by Ext-Name (default) BLAH.BMP -> XXX.GIF -> H0.PNG -> H2.PNG -> ZZZ.PNG -> ATOMBOMB.WEP
+ + + See all images by Name-Ext ATOMBOMB.WEP -> BLAH.BMP -> H0.PNG -> H2.PNG -> XXX.GIF -> ZZZ.PNG
+ + + See multiple images by number C8.PNG -> C9.PNG -> C10.PNG -> C11.PNG (no C13.PNG if C12.PNG not present)
+ + + See just 1 image (lock the 4 buttons then)

- strange dotty rectangle (partially visible in the shot)

Wishlist (highest priority on the top):

### Update shot feature (from DUGLPLAY)

### Fix multiple masx

### Fix multi-image

### Add "This program must be run in DOS mode" without override

## WebP

## Add "Save image as 24 bpp BMP"

# Fix strange dotty rectangle (partially visible in the shot)

# More zoom strategies (see older post)

# More zoom algo's (gamma-correct Lanczos)

# Display Metadata (EXIF in JPG, comments in GIF and PNG, ??? in WebP)

# Warn about AGIF and APNG

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> VESA 1.2 bankswitch do not allow normally high-speed rendering.
> Any way, I have an idea to very fastly support bank switch !
> just render into a memory Surf, and then just write a new function that
> copy the memory surf, to the bank switched video mode.
> I guess like this we will not lose much speed !

I do it same way, I have one FB and 2 different functions that copy FB to VRAM. You can also little speed up bank switch if you use far call of window function instead calling int10h (if PM vbios support it).

> What about the mouse wheel ? did it worked for you ? I was waiting for your
> final test to release the final DUGL Viewer 0.4.

It behaves strange.
Only the wheel do nothing but when I press left button and wheeling it scrolls diagonally (down+right or up+left). I also found that buttons for next/prev. image and also pgup/down, home/end keys doesn't work. Key-scrolling works OK.

I tested under MSDOS 7.1 and MSDOS 6.22 with CuteMouse v2.1 beta4 [FreeDOS], ps/2 KB and ps/2 intelli mouse explorer 3.0A, on FAT16 disk, browsing a directory with camera images:

Directory of H:\106CANON
. <DIR> 08-17-11 11:31p
.. <DIR> 08-17-11 11:31p
IMG_0667 JPG 1,450,884 08-16-11 9:46p
IMG_0669 JPG 1,018,090 08-16-11 10:14p
IMG_0676 JPG 1,511,297 08-16-11 10:31p
IMG_0679 JPG 1,641,470 08-16-11 10:31p
IMG_0680 JPG 1,365,623 08-16-11 10:32p
IMG_0681 JPG 1,465,105 08-16-11 10:32p
IMG_0683 JPG 2,333,914 08-16-11 10:42p
IMG_0685 JPG 1,708,294 08-16-11 10:44p
IMG_0686 JPG 1,713,865 08-16-11 10:44p
IMG_0689 JPG 1,545,546 08-16-11 10:50p
IMG_0691 JPG 1,478,690 08-16-11 10:51p
IMG_0694 JPG 1,365,651 08-16-11 10:51p
IMG_0695 JPG 1,964,421 08-16-11 10:52p
IMG_0696 JPG 1,951,358 08-16-11 10:52p
OFFSPR~1 JPG 386,159 08-17-11 2:10a
17 file(s) 22,900,367 bytes
135,479,296 bytes free

As I told Arachne and few other wheel-enabled apps works for me.

---
DOS gives me freedom to unlimited HW access.

> > I try to run duglviewer in a Windows XP DOS Box
> > and I always get "DUGL init error
> > My suggestion is to tell the user what kind of error occured
>
> if (Detect_DOS_Now()==false) /* then */ {
> printf ("This program must be run in DOS mode");
> abort();
> }

I do prefer the message "WinNT/2k/XP/Vista/7 not supported!\n", As it run also on Windows 9x/Me.

>
> IMHO no point. VESA B***S*** 1.2 might be useful for 80386 compatible
> stuff, but not if DUGL needs MMX.
>

If I support VESA 1.2 BS, DUGL will run under WindowsNT/XP and maybe on Vista/7.

> Tests:
>
> + it works
>
> + PNG works (interlace not tested ... 16 bppc not tested ... other silly
> stuff not tested)
>
> - multiple masx works partially only, "see only JPG" is preselected (why?),
> there is no "see all supported files" (DUGLPLAY has same problem)

Ok, I added "All supported Images", multi-filer, "*.jpg|*.png|*.bmp|*.gif|*.pcx"

>
> - shot feature is "old" - only one shot, only JPG, inherently lossy:
>
>

Ok, replaced by the DUGL Player alt+S and searching not used screenshot file name.

>
> - buttons "prev" "next" "earliest" and "last" are "messed up"
>

Why ? ugly images ? not working ?

> - "multi-image" mode is strange and too complicated, idea to fix:
>

I don't see how it's complicated, but maybe it's not adapted to all needs.
for example if you choose "pic0005.jpg", he will search for all "pic*.jpg" on the same directory and then sort them.

> + + Remove F3-vs-ALT-F3 and CFG entry on them
> + + Whenever loading an image, always remember full directory (all
> supported files, clamp to some reasonable value (10'000?))
> + + Add 4 modes (selectable besides "Fit View")
> + + + See all images by Ext-Name (default) BLAH.BMP -> XXX.GIF -> H0.PNG ->
> H2.PNG -> ZZZ.PNG -> ATOMBOMB.WEP
> + + + See all images by Name-Ext ATOMBOMB.WEP -> BLAH.BMP -> H0.PNG ->
> H2.PNG -> XXX.GIF -> ZZZ.PNG
> + + + See multiple images by number C8.PNG -> C9.PNG -> C10.PNG -> C11.PNG
> (no C13.PNG if C12.PNG not present)
> + + + See just 1 image (lock the 4 buttons then)
>

I guess with those four modes we will fit most users needs.

> - strange dotty rectangle (partially visible in the shot)

The strange dotty rectangle is the Focus marker. I removed it, you are right

Did the mouse-wheel scrolling worked for you ? at least correctly on "Fit Width" mode.

>
> Wishlist (highest priority on the top):
>
> ### Update shot feature (from DUGLPLAY)
DONE.

>
> ### Fix multiple masx
DONE.

> ### Add "This program must be run in DOS mode" without override
DONE.

>
> ## Add "Save image as 24 bpp BMP"
DONE

>
> # Fix strange dotty rectangle (partially visible in the shot)
DONE. REMOVED the focus marker
>

The others have to wait for futur versions.

>
> I do it same way, I have one FB and 2 different functions that copy FB to
> VRAM. You can also little speed up bank switch if you use far call of
> window function instead calling int10h (if PM vbios support it).
>

I used your vesatest utility to do a test, and there is a big performance loss with BS over LFB

LFB has a 1000MB/sec over only 60MB/sec on my system.
Any way it should be nice to be able to run under a windowsNT OS.

> > What about the mouse wheel ? did it worked for you ? I was waiting for
> your
> > final test to release the final DUGL Viewer 0.4.
>
> It behaves strange.
> Only the wheel do nothing but when I press left button and wheeling it
> scrolls diagonally (down+right or up+left).

Yes I fixed this bug, but if you try the "fit width mode" the scrolling should be be fine.

> I also found that buttons for
> next/prev. image and also pgup/down, home/end keys doesn't work.

the GUI buttons or keyboards buttons which do not work ?
did the open gui button worked for you ?

Hi,

What's new :

- Changed screenshot from jpg to bmp and keyboard from Ctrl+Shift+tab to Alt+'S', screen shot will be named "duglvew[r]->[z].bmp".
- Added error message at start-up if we are running WindowsNT/XP/Vista/7
- Removed displaying Focus when image view get it.
- Added multiple image mask to filter all images formats supported.
- Fixed the mouse-wheel scrolling bug on "As Is" view mode.


can be downloaded from :

DUGL VIewer 0.4 prerelease 2(DOS compatible link)
DUGL Viewer 0.4 prerelease 2(mediafire link)

I hope this one is enough good to be officially released,
Thanks for all bug reports and feedbacks

> I try to run duglviewer in a Windows XP DOS Box and I always get "DUGL init
> error".
>
> My suggestion is to tell the user what kind of error occured.
>
> Georg
you have tried it with
Videoport driver patch for VESA in NTVDM
?
http://dukertcm.com/knowledge-base/downloads-rtcm/general-tools-dosxp/

> LFB has a 1000MB/sec over only 60MB/sec on my system.
> Any way it should be nice to be able to run under a windowsNT OS.

Yes but on some intel integrated graphics the BS is implemented very fast (LFB maybe slower there)
e.g. on i865G I got this strange result:
BS: 535 MB/s
LFB: 66 MB/s

> Yes I fixed this bug, but if you try the "fit width mode" the scrolling
> should be be fine.

OK I'll test this evening...

> the GUI buttons or keyboards buttons which do not work ?
> did the open gui button worked for you ?

Only the open button works.

---
DOS gives me freedom to unlimited HW access.

> Only the open button works.

This mean, I guess, that you missed to enable multi-images load and that DUGL Viewer loaded only the choosed image in file dialog.
You can enable multi-images load by :
- Pressing Alt+F3
- Alt + Open button
- Modify the value of [EnableDefaultMultiLoad] to 1, inside config file, this will remove the requirement of Alt + to enable multi-images load.

> This mean, I guess, that you missed to enable multi-images load and that
> DUGL Viewer loaded only the choosed image in file dialog.

Aha, missed that. Why not to have it enabled by default?

Wheel scrolling now works. Only maybe I'd rather use right+wheel for horizontal scroll, could you enable it for left|right or make configurable?

Under win98 ctmouse don't work for me but other things works well.

---
DOS gives me freedom to unlimited HW access.

Tests / discoveries:

0. Added source code

1. The new overrideable "true-TNT" check works (see shot #0 )

> > ### Add "This program must be run in DOS mode" without override
> DONE.

It's with override ...

> you have tried it with Videoport driver patch for VESA in NTVDM

NO :shock:

> Under win98 ctmouse don't work for me but other things works well

MEVDM still comptetes against NTVDM :shock:

2. Increased bloat 233'668 -> 292'044 | 590'848 -> 752'128 - does the overrideable "true-TNT" check really cost 160 KiB ???

3. Minor BUG: "All supported files" works, just PCX missing

4. Flaw: directory cursor sits on dirs, not on files (see shot #3)

5. Flaw: Rat wheel doesn't work on directory

6. Silly "H" and "S" files visible OK

7. Multishot in BMP format seems to work (see 1'000'000'000 shots)

8. Save BMP doesn't work / not present (see below #76 and #78)

> > ## Add "Save image as 24 bpp BMP"
> DONE

COOL ... for shot only so far ...

9. Interlace not tested

10. Some PNG color models (binary) tested and OK

11. BUG : PNG with trans index "tRNS" is messy (PNG with Alpha seems less bad) (see file "TREETRAN.PNG")

12. Subminor flaw: some BMP's and GIF's don't work (not critical, but see below #73)

13. File format autodetection OK, but ... (see below #69 to #73)

14. Buttons are still messed (see below #78)

Wishlist:

## 66. Multifile modes, delete ALT-F3 (see 1'000'000'000 posts above)

> > This mean, I guess, that you missed to enable multi-images load and that DUGL
> > Viewer loaded only the choosed image in file dialog.
> > You can enable multi-images load by :
> > - Pressing Alt+F3
> > - Alt + Open button
> > - Modify the value of [EnableDefaultMultiLoad] to 1, inside config file, this will
> > remove the requirement of Alt + to enable multi-images load.
> Aha, missed that. Why not to have it enabled by default?

## 67. Warn/inform about AGIF and APNG

## 68. Warn/inform about transparency 3-state: NONE INDEX/TRNS ALPHA (with or without support, or make support and background switchable)

## 69. Warn about missnamed files

## 70. Inform about file format & Co :


Name       : "BLAH.BMP"
Bloat      : 999'999 Byte's
Type       : PNG (missnamed)      (detect by Sigi)
Status     : OK                   (or "ERROR" if broken or unsupported)
Dimensions : 640x480              (only if "OK")
Details    : c2 d16               (only if "PNG" and "OK")
Animation  : NO                   (risk on GIF and PNG)
Trans      : NO                   (risk on GIF and PNG)
Colors     : 999'999              (only if "OK", count unique ones)


## 71. Detect supported file types and switch, rather than BRUTE-FORCE

## 72. Detect some more (unsupported) file types (TIFF, TGA, JPEG3000, PPMD, AVI, OGG, ...)

## 73. Instead of "Error loading image File" (see shot #4), give some more useful info:


'File "SELFSHOT.BMP" is unsupported and file type
could not be identified, try "GT2" or "MediaInfo"'

'File "SELFSHOT.TIF" was identified as TIF -
unsupported, try NCONVERT'

'File "SELFSHOT.BMP" was identified as GIF (missnamed), but
could not be decoded - broken or unsupported flavor, try NCONVERT'


## 74. Z O O O O O O O O O O O O O O O O O O O O O M algo's

## 75. Z O O O O O O O O O O O O O O O O O O O O O M strategies

## 76. New feature: Save picture as 24bpp BMP (besides shot, exactly as loaded, just always as 24bpp BMP)

## 77. Show (and possibly export into a file) metadata: EXIF in JPEG, comments in GIF and PNG, ??? in WeBP

## 78. Fix the buttons (see file http://jafile.com/uploads/dos386/duglicon.zip 3'722 Byte's) : better sorting (as numbered), BEGIN-vs-BACK NEXT-vs-END better distinguishable, removed "Open" (where did you pirate it from ? Windaube ??? ), replaced by "Load", added "Save" (see also ## 76.)

## 79. Replace the CWSD-stub (whines, see shot #0) by D3X

## 80. WebP

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > This mean, I guess, that you missed to enable multi-images load and that
> > DUGL Viewer loaded only the choosed image in file dialog.
>
> Aha, missed that. Why not to have it enabled by default?

IMHO it's more natural that an image viewer open a single image.
Any way, this can be changed on config file.

> Wheel scrolling now works. Only maybe I'd rather use right+wheel for
> horizontal scroll, could you enable it for left|right or make
> configurable?

Yes, I tried more left,right scrolling with left mouse button, and it's not very confortable, so I will make it configurable on the coming 0.4 release ASAP.


>
> Under win98 ctmouse don't work for me but other things works well.

Seems that ctmouse isn't able to detect mouse wheel under win98. I tested and it didn't work on my side too

>

You can use F5 to smooth a little this ultra-zoomed pic,

> Tests / discoveries:
>
> 0. Added source code

Yes, but still no one can compile DUGL View, as I haven't released yet DUGL core 1.16 and DUGL+ 0.31. But if any one wish I can upload WIP versions.

> 2. Increased bloat 233'668 -> 292'044 | 590'848 -> 752'128 - does the
> overrideable "true-TNT" check really cost 160 KiB ???

Previous version was compiled with DJGPP 2.03, the last one with DJGPP 2.04 !
And yes !! the cost of true-TNT is about 160KiB

>
> 3. Minor BUG: "All supported files" works, just PCX missing

OK added.
>
> 4. Flaw: directory cursor sits on dirs, not on files (see shot #3)

Focus return always on dirs, to help those who don't have mouse installed, to reach faster the wanted directory. Any way this is a DUGL+/GUI subject, ...

>
> 5. Flaw: Rat wheel doesn't work on directory

Yes, DUGL+/GUI do not support yet mouse wheel

>
> 6. Silly "H" and "S" files visible OK
>

You mean Hidden and System, I guess no problem as we filter only images pic.

> 8. Save BMP doesn't work / not present (see below #76 and #78)
>
> > > ## Add "Save image as 24 bpp BMP"
> > DONE

Yes sorry I thinked it was about shots

>
> COOL ... for shot only so far ...
>
> 9. Interlace not tested
>

Interlace isn't supported in PNG neither on GIF

> 10. Some PNG color models (binary) tested and OK
>
> 11. BUG : PNG with trans index "tRNS" is messy (PNG with Alpha seems
> less bad) (see file
> "TREETRAN.PNG")
>
> 12. Subminor flaw: some BMP's and GIF's don't work (not critical, but see
> below #73)

Yes only uncompressed 8/24bpp BMP works
and only 8bpp not interlaced GIF

>
> 13. File format autodetection OK, but ... (see below #69 to #73)
>
> 14. Buttons are still messed (see below #78)
>
> Wishlist:
>
> ## 66. Multifile modes, delete ALT-F3 (see 1'000'000'000 posts above)

I guess, this require on new File/Directory dialog customized for DUGL Viewer

>
> ## 78. Fix the buttons (see file
> http://jafile.com/uploads/dos386/duglicon.zip 3'722 Byte's) : better
> sorting (as numbered), BEGIN-vs-BACK NEXT-vs-END better distinguishable,
> removed "Open" (where did you pirate it from ? Windaube ??? ),
> replaced by "Load", added "Save" (see also ## 76.)
>

No the "Open" is available for free on the web, like all others.
I like your new buttons order, but the new "Open" isn't very beautiful

> IMHO it's more natural that an image viewer open a single image.
> Any way, this can be changed on config file.

I'm used to from other image viewers like SEA, QPV, Acdsee...

---
DOS gives me freedom to unlimited HW access.

> IMHO it's more natural that an image viewer open a single image

Not for me ... consider an APNG ... I decompose it into 1'000'000'000 frames and want to see them all without searching every single one within the directory. This brings up another idea: multi-view with a short delay instead button click BTW, it might be a good idea to close every single image file just after loading it ... consider cca 15 handles limit in DOS.

> And yes !! the cost of true-TNT is about 160KiB

> > 6. Silly "H" and "S" files visible OK
> You mean Hidden and System, I guess no problem as we filter only images

Who said every discovery has to be a problem ?

> guess, this require on new File/Directory dialog customized for DUGL Viewer

possible ...

> No the "Open" is available for free on the web, like all others

Maybe true ... pirated in sense of copyright and criminal law or just "pirated"

> I like your new buttons order, but the new "Open" isn't very beautiful

My new icon is Load, not Open (who had invented this nonsense ??? Macro$oft ???) ... but why don't you just open a challenge - contribute nice original icons unique to DUGL Player & Viewer

BTW, there is a potential problem with my "Save image as BMP" - if you use only 16bpp internal buffers, the conversion will be lossy

The most critical problem for now is IMHO the tRNS-BUG ... most of the others can wait for 0.5

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Added the viewer to the ugly dugl website DUGL Viewer

What's new according to the last prerelease 2 :

- Changed the order of navigation buttons and update and update gfx of two buttons.
- improved up/down zoom display quality
- Horizontal scrolling using mouse wheel, will require left or right mouse button clicker over the pictures
- Added the missed PCX on global supported images filter.
- Added more parameters on config file.
- Bug fixes and improvements on source code.
- ...

can be downloaded from :

DUGL VIewer 0.4 prerelease 2(DOS compatible link)
DUGL Viewer 0.4 prerelease 2(mediafire link)

Thanks for all who helped me to improve this small soft

> BTW, it might be a good idea to close every
> single image file just after loading it ... consider cca 15 handles limit
> in DOS.

Currently DUGL Viewer keep only one picture in memory, and even for this picture its file is opened and closed just after decoding.


> My new icon is Load, not Open (who had invented this nonsense ???
> Macro$oft ???) ... but why don't you just open a challenge -
> contribute nice original icons unique to DUGL Player & Viewer
>

DUGL Viewer is open for any contrubution. Well I do not guarantee that I will accept any contribution, But as it's a free software, any one can make his own version and redistribute it freely.

>
> BTW, there is a potential problem with my "Save image as BMP" - if you use
> only 16bpp internal buffers, the conversion will be lossy
>

Yes the image has to be reloaded then stored in the new BMP format.

> The most critical problem for now is IMHO the tRNS-BUG ... most of
> the others can wait for 0.5

I made a some researchs and I was not able to fix this bug. So it can wait for next versions. I hope that I will release soon both DUGL Core, and DUGL+, So it will be easier for any one to help me to fix this.

> DUGL Viewer 0.4 final released

What's new:

- renamed "player" to "viewer" in source
- renamed "Aout" to August" (no YYYY-MM-DD yet )
- added PCX (untested)
- sorted buttons

> Currently DUGL Viewer keep only one picture in memory, and even for this
> picture its file is opened and closed just after decoding



> > The most critical problem for now is IMHO the tRNS-BUG ... most
> I made a some researchs and I was not able to fix this bug





BUG's:

- tRNS
- interlace
- mouse wheel is reversed

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

>
>
>

> BUG's:
>
> - tRNS
> - interlace
> - mouse wheel is reversed

You can swap the wheel direction on config file,
just change the value of [MsWheelScrollDir] from 1 to -1.

.

..

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> You can swap the wheel direction on config file,
> just change the value of [MsWheelScrollDir] from 1 to -1

Thanks ... I had known ... but why behave wrongly by default ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

FFK, if you could add the autorotation according EXIF information from JPG files generated by digital cameras, it would be a beautiful improvement and DUGLViewer would be the only DOS program capable for this thing.

---
DOS-u-akbar!

> > You can swap the wheel direction on config file,
> > just change the value of [MsWheelScrollDir] from 1 to -1
>
> Thanks ... I had known ... but why behave wrongly by default ?

I thinked that there is no standard mouse wheel direction, so i just chooses one by default.

> FFK, if you could add the autorotation according EXIF information from JPG
> files generated by digital cameras, it would be a beautiful improvement and
> DUGLViewer would be the only DOS program capable for this thing.

libjpeg could extract exif information ?
I will make some research, but it will be faster if you give me a chunk of source code that do this extraction.

> I thinked that there is no standard mouse wheel direction, so i just
> chooses one by default.

Al non-DOS programs but also Arachne use the same one ... just DUGLViewer is "backward" ...

> FFK, if you could add the autorotation according EXIF information from JPG files
> generated by digital cameras, it would be a beautiful improvement and DUGLViewer

+0.999'999

make sure this can be disabled in program ... add rotate menu:

[ ] no rotation
[ ] 90 deg right
[ ] 90 deg left
[ ] 180 deg
[*] look into EXIF, otherwise none

At this occasion you could support displaying and extracting the EXIF stuff.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

>
> Al non-DOS programs but also Arachne use the same one ... just DUGLViewer
> is "backward" ...
>

Ok then I have to swap this for next version.

>
> +0.999'999
>
> make sure this can be disabled in program ... add rotate menu:
>

Yes it should be enabled/disabled using the cfg file.

> [ ] no rotation
> [ ] 90 deg right
> [ ] 90 deg left
> [ ] 180 deg
> [*] look into EXIF, otherwise none
>

Yes.

> At this occasion you could support displaying and extracting the EXIF
> stuff.

I guess that displaying EXIF is useful only on the case that we want to provide a preview before loading the original image ? You have already reported that this preview is some times not up to date ?