DOS ain't dead

I could not find one. NConvert v. 5.88 from 5-1-16 looked promising, and I found the DOS version some years ago. It even has a couple of options which mention "JPEG2k compression" but I could neither convert a PNG to or from a .jp2 file. The program simply froze when I tried to do so.

Programs such as the DOS Mplayer, Quickview Pro v. 2.61 did not recognize JP2 files, either.

Display, SEA, QPV, etc are too old, ImageAlchemy their last versions released before the format existed. ImageMagick claims to support the format, but there was never any DOS DJGPP version that I could find.

Does Blocek support JP2 files? Or is there any other DOS program that does?

Ditto for the new JPEG XL format...

> I could not find one. NConvert v. 5.88 from 5-1-16 looked promising, and I
> found the DOS version some years ago. It even has a couple of options which
> mention "JPEG2k compression" but I could neither convert a PNG to or from a
> .jp2 file. The program simply froze when I tried to do so.
>
> Programs such as the DOS Mplayer, Quickview Pro v. 2.61 did not recognize
> JP2 files, either.
>
> Display, SEA, QPV, etc are too old, ImageAlchemy their last versions
> released before the format existed. ImageMagick claims to support the
> format, but there was never any DOS DJGPP version that I could find.
>
> Does Blocek support JP2 files? Or is there any other DOS program that
> does?
>
> Ditto for the new JPEG XL format...

I'm not aware of DOS image viewer that supports jpeg2k or jpeg-xl, but you might find a port of jpeg2k in DJGPP repos.

Anyway, why do it in DOS, why not convert them to a DOS friendlier format in Linux, Windows or Mac?

Or if it has to be in DOS (why?), can't you use HX to run Windows command line executables?

> Anyway, why do it in DOS, why not convert them to a DOS friendlier format
> in Linux, Windows or Mac?
>
> Or if it has to be in DOS (why?), can't you use HX to run Windows command
> line executables?

Well, for the "completeness" and mental exercise. But, you're right, I forgot about HX. I suppose some repositories (github?) may exist of compilable code in simple C or such, of JPEG-2000 readers. However, I've also heard that there are royalty / licensing problems which would be one reason why no such DOS viewer was ever put out. I'm more concerned with "proof of concept" than I am with royalty issues, especially since this is for personal use only. A quick look didn't bring up anything in simple C, which could be compiled with Watcom.

The intention is to read "books" / magazines of .jp2 images posted on archive.org in DOS (downloaded to disk), since these scanned images are higher-quality than the PDFs which only use regular JPEG images.

> ImageMagick claims to support the format, but there was never any DOS DJGPP version that I could find.

This is probably too old to work (2008), but you can try anyways:

* https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/magick/

For next few days I will not have a opportunity to try it but what about HX-DOS with some newer version of NConvert (commandline Win32 executable, unfortunately there no DOS builds anymore)

---
DOS-u-akbar!

If libjpeg (that has DJGPP DOS port) supports this format then it wouldn't be problem to make simple viewer, it's also part of libjpeg samples.
I didn't care about JPEG2k as it is not much widespread and even in windows env. I didn't meet it as long as I remember. In the past I did some comparison for digital photos compression but I found wavelet compression (as expected) performed worse on sharp edges while it had smoother color gradients. So I stayed with classic lossy JPEG...

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

> For next few days I will not have a opportunity to try it but what about
> HX-DOS with some newer version of NConvert (commandline Win32 executable,
> unfortunately there no DOS builds anymore)
Latest DOS version of Nconvert I found was 6.88 and it doesn't support JPEG 2000 format, either. I couldn't get a Windows commandline version of v. 7.32 to work with HX.

Also, thanks for posting a DOS version of ImageMagick. All such DOS versions seem completely erased from internet (the same goes for Nconvert DOS versions, but I had downloaded 6.88 years ago when they still had the DOS compiles. Why "erase" DOS utility software when some may still get use out of it. Even if it's deemed "deprecated" don't just nuke it from your site!).

I also didn't try the DOS versions of Pixel (0.996b and 1.0 alpha), as they've never run satisfactorily on system I've owned, are crippled, and buggy.

That is quite interesting for ImageMagick. Although it doesn't support JPEG 2000, either. It has interesting options and serves well as a converter and does some commandline effects.

> If libjpeg (that has DJGPP DOS port) supports this format then it wouldn't
> be problem to make simple viewer, it's also part of libjpeg samples.
> I didn't care about JPEG2k as it is not much widespread and even in windows
> env. I didn't meet it as long as I remember. In the past I did some
> comparison for digital photos compression but I found wavelet compression
> (as expected) performed worse on sharp edges while it had smoother color
> gradients. So I stayed with classic lossy JPEG...

Yes, I see libjpeg here:
https://github.com/winlibs/libjpeg/blob/master/readme.dos

and here:
https://github.com/mitsuba-renderer/libjpeg

specific DJGPP compile makefile
makefile.dj jconfig.dj MS-DOS, DJGPP (Delorie's port of GNU C)

Not sure which of these two to attempt to compile. The second one seems more "current" for libjpg.

Hm, it seems that in JibJPEG is no support for JPEG2000.
Definitely not in the current 6b release but also not in the upcoming 7 release which is in the GitHub.
There exists also OpenJPEG library which does support the JPEG2000 but it would be difficult to compile it for DOS as it uses not standard MAKE utility but CMAKE utility which (as far I know) does not have the DOS port. Maybe only via some crosscompilation.


I also tried the newest NConvert 7.154.
It does not run "normaly" with HX-DOS. However if you set the envorinment variable DPMILDR=128 than it works.
However for JPEG2000 is necessary an external plugin. It is possible to get it as it is included in the XnView package.
But then it crashes with fatal error...

---
DOS-u-akbar!

> All such DOS versions seem completely erased from internet (the same goes for
> Nconvert DOS versions

NConvert v6.88, 2016-05-02, is still available on the XNView download site (search for "NConvert-dos.zip"):

https://download.xnview.com/

There are also older DOS and Win versions in the "old_versions" directory:

https://download.xnview.com/old_versions/NConvert/

> I couldn't get a Windows commandline version of v.7.32 to work with HX.

Perhaps some of the older Win versions of NConvert there (between v6.88 and the latest) might work under HX (haven't tried, don't know when it stopped working under HX).

- Doug

> Hm, it seems that in JibJPEG is no support for JPEG2000.

No, I see it doesn't

> There exists also OpenJPEG library which does support the JPEG2000

Yes, this might be a way. I tried to compile some older version of OpenJPEG 1.5 (2013) that doesn't need cmake under Mingw32 so there's a chance it could be compiled under DJGPP with some effort...

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

> > There exists also OpenJPEG library which does support the JPEG2000
>
> Yes, this might be a way. I tried to compile some older version of OpenJPEG
> 1.5 (2013) that doesn't need cmake under Mingw32 so there's a chance it
> could be compiled under DJGPP with some effort...

Is this the OpenJPEG project you refer to:
https://github.com/uclouvain/openjpeg/

I see version 2.5 is newest, with only a CMAKE file and no reference to DOS or DJGPP.

I see no DOS makefile there, and only passing reference to 1.5 version in the changelogs, but no way to download it or its makefile.

Did you have any luck with (cross) compiling a DJGPP binary of v.1.5?

> Did you have any luck with (cross) compiling a DJGPP binary of v.1.5?

Yes. But, sigh, after all effort that crap just crashes :(

C:\openjpeg\APPLIC~1\codec>j2k_to_image.exe -i sample.j2k -o sample.bmp

[INFO] tile 1 of 1
realloc: memory fouled
Exiting due to signal SIGABRT
Raised at eip=00034695
eax=000cca94 ebx=00000120 ecx=00000000 edx=00000000 esi=0000360c edi=000e09b0
ebp=00003610 esp=000cca80 program=C:\OPENJPEG\APPLIC~1\CODEC\J2K_TO~1.EXE
cs: sel=01a7  base=029f0000  limit=000effff
ds: sel=01af  base=029f0000  limit=000effff
es: sel=01af  base=029f0000  limit=000effff
fs: sel=017f  base=000067f0  limit=0000ffff
gs: sel=01bf  base=00000000  limit=0010ffff
ss: sel=01af  base=029f0000  limit=000effff
App stack: [000cfe78..0004fe78]  Exceptn stack: [0004fdb4..0004de74]

Call frame traceback EIPs:
  0x00034695


It fails somewhere in function j2k_decode, in the for loop, states before crash:
>dbg j2k.state: 01h
>dbg j2k.state: 02h
>dbg j2k.state: 04h
>dbg j2k.state: 04h
>dbg j2k.state: 04h
>dbg j2k.state: 04h
>dbg j2k.state: 10h
>dbg j2k.state: 08h
[INFO] tile 1 of 1

typedef enum J2K_STATUS {
J2K_STATE_MHSOC = 0x0001, /**< a SOC marker is expected */
J2K_STATE_MHSIZ = 0x0002, /**< a SIZ marker is expected */
J2K_STATE_MH = 0x0004, /**< the decoding process is in the main header */
J2K_STATE_TPHSOT = 0x0008, /**< the decoding process is in a tile part header and expects a SOT marker */
J2K_STATE_TPH = 0x0010, /**< the decoding process is in a tile part header */
J2K_STATE_MT = 0x0020, /**< the EOC marker has just been read */
J2K_STATE_NEOC = 0x0040, /**< the decoding process must not expect a EOC marker because the codestream is truncated */
J2K_STATE_ERR = 0x0080 /**< the decoding process has encountered an error */
} J2K_STATUS;

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

The code I built with MinGW32 works fine.
Maybe I do linking wrong way because it uses some .lo and .la files that my DJGPP couldn't handle so I replaced library target recipe simply by this:
# $(AM_V_CCLD)$(libopenjpeg_la_LINK) -rpath $(libdir) $(libopenjpeg_la_OBJECTS) $(libopenjpeg_la_LIBADD) $(LIBS)
ar rvs libopenjpeg.a $(libopenjpeg_a_OBJECTS)

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

Does the MinGW build work via HX-DOS?

---
DOS-u-akbar!

> Does the MinGW build work via HX-DOS?

I didn't tested yet. I got idea to change CFLAGS to -O0 recompiled but still the same.

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

> > Does the MinGW build work via HX-DOS?
>
> I didn't tested yet. I got idea to change CFLAGS to -O0 recompiled but
> still the same.


Maybe the problem is related to DJGPP's new malloc, it is advisable to replace it in libc with the old one (please see e.g. https://groups.google.com/g/comp.os.msdos.djgpp/c/YNjaTt8zS3g/m/fn-n8LVVDAAJ, in the past I also got into similar problems which were solved by doing this).

---
Glory to God for all things

> Maybe the problem is related to DJGPP's new malloc, it is advisable to
> replace it in libc with the old one (please see e.g.
> https://groups.google.com/g/comp.os.msdos.djgpp/c/YNjaTt8zS3g/m/fn-n8LVVDAAJ,
> in the past I also got into similar problems which were solved by doing
> this).
Good advice, thanks for the hint. I tried also and got same segfault (malloc failure) as RayeR, but I found source for v. 1.5 which may be different from RayeR's source.

Looks like getting OpenJpeg library (and therefore JPEG2000 format converter) compiled in DOS is a tricky proposition.

> Good advice, thanks for the hint. I tried also and got same segfault
> (malloc failure) as RayeR, but I found source for v. 1.5 which may be
> different from RayeR's source.
>
> Looks like getting OpenJpeg library (and therefore JPEG2000 format
> converter) compiled in DOS is a tricky proposition.

You are welcome. Have you replaced the new and buggy malloc from DJGPP 2.05's libc.a with the old one and still get the crash?

---
Glory to God for all things

> You are welcome. Have you replaced the new and buggy malloc from DJGPP
> 2.05's libc.a with the old one and still get the crash?

I attempted replacing libc.a from both DJGPP version 2.03 and 2.04 and recompiling (version 1.6) of OpenJPEG and still have memory allocation problems (segfault). Not sure if reverting to 2.03 helped. I think I may have something else wrong in my compilation chain / options. I'm almost ready to give up. Going all the way back to DJGPP 2.01 probably won't help, either.

Perhaps RayeR had more success with replacing the old memalloc code...

> > You are welcome. Have you replaced the new and buggy malloc from DJGPP
> > 2.05's libc.a with the old one and still get the crash?
>
> I attempted replacing libc.a from both DJGPP version 2.03 and 2.04 and
> recompiling (version 1.6) of OpenJPEG and still have memory allocation
> problems (segfault). Not sure if reverting to 2.03 helped. I think I may
> have something else wrong in my compilation chain / options. I'm almost
> ready to give up. Going all the way back to DJGPP 2.01 probably won't help,
> either.
>
> Perhaps RayeR had more success with replacing the old memalloc code...

Well, I've had a little spare time today and I built for DJGPP OpenJPEG v2.5.0 from GitHub (that is, the latest version), I quickly tested both opj_compress.exe and opj_decompress.exe (I left the long file names unchanged) with a few image files and I didn't encounter any problems. No modification to the sources was needed, you can get the package from https://filebin.net/fo5djsm1itn8hq83

---
Glory to God for all things

> Well, I've had a little spare time today and I built for DJGPP OpenJPEG
> v2.5.0 from GitHub (that is, the latest version), I quickly tested both
> opj_compress.exe and opj_decompress.exe (I left the long file names
> unchanged) with a few image files and I didn't encounter any problems. No
> modification to the sources was needed, you can get the package from
> https://filebin.net/fo5djsm1itn8hq83
Your compiled version worked for me. The decompressor was tested on a few sample .jp2 files and successfully converted to .bmp

This has been a very interesting and educational exercise. Thanks for posting your package of 2.5

It is always wonderful to learn new things. The vicissitudes of compilation woes can work out!

How did you do it?
You did use a crosscompilation?

---
DOS-u-akbar!

> How did you do it?
> You did use a crosscompilation?

I built it with the latest MinGW DJGPP cross compiler from https://github.com/andrewwutw/build-djgpp.

---
Glory to God for all things

> > How did you do it?
> > You did use a crosscompilation?
>
> I built it with the latest MinGW cross compiler from
> https://github.com/andrewwutw/build-djgpp.
That is the same crosscompiler I use, and it is fantastic (except in the present case of OpenJpeg 2.5, I could not solve memory allocation problem, like you did).

> > > How did you do it?
> > > You did use a crosscompilation?
> >
> > I built it with the latest MinGW cross compiler from
> >
> https://github.com/andrewwutw/build-djgpp.
> That is the same crosscompiler I use, and it is fantastic (except in the
> present case of OpenJpeg 2.5, I could not solve memory allocation problem,
> like you did).

I told you that the new malloc from DJGPP 2.05's libc.a is buggy and you have to replace it with the old one, apart from that I didn't make any change (EDIT: except that I disabled the building of the shared library), I just ran cmake and make.

---
Glory to God for all things

> I told you that the new malloc from DJGPP 2.05's libc.a is buggy and you
> have to replace it with the old one, apart from that I didn't make any
> change (EDIT: except that I disabled the building of the shared library), I
> just ran cmake and make.

Have you reported the malloc bug somewhere?
Good place is the DJGPP Google Group
here

---
DOS-u-akbar!

> Have you reported the malloc bug somewhere?
> Good place is the DJGPP Google Group
> here

It wasn't discovered by me, it is a well-known bug, in fact if you actually browse the link you pointed to above you will find it mentioned more than once. Unfortunately it seems that there is no one interested in fixing it and to be honest I don't really care about it either.

---
Glory to God for all things

Sorry, I hadn't more time to mess with it.
But Khusraw had a good luck. Please could you provide a package with preconfigured sources so that I could try rebuild it on my DJGPP toolchain?

Zyzzle mentioned he tried older DJDEV/Libc and it still crashed so wouldn't be malloc problem? I also tried to link with old libc.a taken from v2.03 but it failed for some incompatability. I don't know how to simply replace only the malloc in latest libc without recompiling all the stuff.
BTW what kind of malloc use that crosscompiler you used? Should DJGPP oficial libC use this code if it's less buggy?

BTW2 there's opj_malloc.h that's related to malloc but seems only a wrapper

BTW3 openjpeg 2.5.0 seems to have incompatible API wit 1.5.0, also the library name is different. I cannot compile 1.5.0 programs with 2.5.0 library (renamed).

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

Hm, the problem seems not be malloc() itself but memalign().
I followed opj_malloc.h and there's section:

#ifdef HAVE_MEMALIGN
        extern void* memalign(size_t, size_t);
        #undef opj_aligned_malloc
        #define opj_aligned_malloc(size) memalign(16, (size))
        #undef opj_aligned_free
        #define opj_aligned_free(m) free(m)
#endif

where HAVE_MEMALIGN is defined some lines above:

#else /* Not _WIN32 */
        #if defined(__sun)
                #define HAVE_MEMALIGN
        /* Linux x86_64 and OSX always align allocations to 16 bytes */
        #elif !defined(__amd64__) && !defined(__APPLE__)
//              #define HAVE_MEMALIGN
                #include <malloc.h>
        #endif

I commented HAVE_MEMALIGN out and viola, it works then!

also replacing malloc() with valloc() (page aligned) works.

UPDATE: _mm_malloc works fine too so I modified opj_malloc.h to use it (HAVE_MM_MALLOC). My build + sources are here:

https://sourceforge.net/projects/ffmpeg-x264-dos/files/libOpenJPEG-1.5.0-dos-12-09-2023.zip/download

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

Re: no enought memory under win xp (2013)

So they did change memalign() arguments to match Linux.

> Re:
> no enought memory under win xp (2013)
>
> So they did
> change
> memalign() arguments to match Linux.

But this is not the problem. Current libc declares:
void *memalign(size_t _align, size_t _amt);

and OpenJPEG uses the right argument order

#ifdef HAVE_MEMALIGN
extern void* memalign(size_t, size_t);
#undef opj_aligned_malloc
#define opj_aligned_malloc(size) memalign(16, (size))
#undef opj_aligned_free
#define opj_aligned_free(m) free(m)
#endif

The problem is if align is > 8, then it crashes :\

Maybe this is the cause why x264/ffmpeg crashed with enabled some inline asm optimized mmx/sse code that I disabled, long time ago, don't remember exactly...

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

> The problem is if align is > 8, then it crashes :\
>
> Maybe this is the cause why x264/ffmpeg crashed with enabled some inline
> asm optimized mmx/sse code that I disabled, long time ago, don't remember
> exactly...

Doesn't DJGPP's COFF only support 4-byte alignment anyways?

> Doesn't DJGPP's COFF only support 4-byte alignment anyways?


There was already some discussion about it in the DJGPP Google Group: here.

---
DOS-u-akbar!

> But this is not the problem. Current libc declares:
> void *memalign(size_t _align, size_t _amt);
>
> and OpenJPEG uses the right argument order
>
> #ifdef HAVE_MEMALIGN
> extern void* memalign(size_t, size_t);
> #undef opj_aligned_malloc
> #define opj_aligned_malloc(size) memalign(16, (size))
> #undef opj_aligned_free
> #define opj_aligned_free(m) free(m)
> #endif
>
> The problem is if align is > 8, then it crashes :\
Good catch / debugging. With the change of memalign to 8 in MALLOC of the libc I was able to successfully (cross)compile version 2.5 also. My compiled executables now work well without crashes.

Thanks to all for this great discussion.

> Hm, the problem seems not be malloc() itself but memalign().

Indeed, it seems that in this case the problem had nothing to do with the new malloc (something which, of course, doesn't make it any less buggy), I built the library with HAVE_MEMALIGN undefined, so I couldn't get into it.

---
Glory to God for all things

> With the change of memalign to 8 in MALLOC of the
> libc I was able to successfully (cross)compile version 2.5 also. My
> compiled executables now work well without crashes.

Yes it works some way but may not be correct solution. In this case the alignment may be just for some performance reason but somewhere else it really must be 16 (e.g. SSE?) and then 8 would not be OK. So use rather _mm_alloc - well' I didn't check the pointers if they are really aligned but should be, it seems use malloc, align the pointer by mask and store original pointer for free () call.

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