Quo Vadis JPEG - Another update (2)

[thorfdbg]

Dear friends of compression, lossy and lossless, please find another update of the JPEG HDR demo software on https://github.com/thorfdbg/libjpeg. It seems the last update broke something, at least hierarchical coding did not work anymore (not that anyone ever missed it). This should be hopefully fixed. Besides a massive code cleanup that removed a lot of almost identical classes, this release also features a much simplified residual coding engine based on the progressive mode, and a new coding mode for "hidden refinement scans" that allows 12bpp DCT coding hidden in an 8bpp DCT image. For the latter, use the -R option to specify the number of "hidden" bits (between 0 and 4). The residual coding performance went down a very tiny bit (about 1%) but scalability to lossy coding improved a lot, especially residual coding of lower quality is considerably better now. As already said, this is all still experimental and I'm not saying that this is what the JPEG will do in the end (we'll be discussing this in the next meeting in Shanghai mid October), but feel invited to participate by testing the software or adding new ideas. As before, this version is verified by the 10918-2 (official ISO) test streams, except for hierarchical where we simply don't have streams. So long, Thomas

[Stephan Busch]

I would test it if there was a compiled win version, because I don't care about linux.

[thorfdbg]

I would test it if there was a compiled win version, because I don't care about linux.

Sorry, but you misunderstand. This is *not a product* I'm trying to sell. This is not an application software, and I'm not a software vendor nor an application developer. In that sense, I'm very happy about feedback concerning the compression algorithm, I'm happy to talk about new ideas, I'm open to discuss details of the code if you want to, but I'm not so interested in messages as in "it doesn't compress my BMP images" - simply because it doesn't. It doesn't take TIFF either, and I don't see why this demo frontend *should* actually take BMP in first place. This is not the point - it is not your "compression solution". It is a demo software if you are interested in the field. Thus, at this early point, I would believe "being able to use a compiler" is quite a good indicator of "being able to help". If you don't want to help - that's ok. But I'm not wasting my time by providing binaries - at this point. For any operating system, BTW. That includes Linux, if that makes you feel any better. If you want to help and have only windows: Please install cygwin, and from there install autoconf, g++ and the C++ headers, make. Everything else is "configure" and "make". Or use Knoppix. Or whatever compiler you have. If you don't - well, you don't. Too bad.

[jethro]

Sorry, but you misunderstand. This is *not a product* I'm trying to sell. This is not an application software, and I'm not a software vendor nor an application developer. In that sense, I'm very happy about feedback concerning the compression algorithm, I'm happy to talk about new ideas, I'm open to discuss details of the code if you want to, but I'm not so interested in messages as in "it doesn't compress my BMP images" - simply because it doesn't. It doesn't take TIFF either, and I don't see why this demo frontend *should* actually take BMP in first place. This is not the point - it is not your "compression solution". It is a demo software if you are interested in the field. Thus, at this early point, I would believe "being able to use a compiler" is quite a good indicator of "being able to help". If you don't want to help - that's ok. But I'm not wasting my time by providing binaries - at this point. For any operating system, BTW. That includes Linux, if that makes you feel any better. If you want to help and have only windows: Please install cygwin, and from there install autoconf, g++ and the C++ headers, make. Everything else is "configure" and "make". Or use Knoppix. Or whatever compiler you have. If you don't - well, you don't. Too bad.

I think actually making a build would take less effort for you than writing this post...

[Alexander Rhatushnyak]

I would test it if there was a compiled win version, because I don't care about linux.

+1
I could test on LPCB images if a win32 executable was provided.

If you want to help and have only windows: Please install cygwin, and from there install autoconf, g++ and the C++ headers, make. Everything else is "configure" and "make". Or use Knoppix.

My experience shows it may take hours if only concise instructions are given, with no URLs. Can you imagine this page compressed to two sentences?

[Stephan Busch]

Dear Thomas,

I'm completely aware about this LIBJPEG variation being something experimental rather than a product.
There was no word about BMP; there are a bunch of other raster formats around
The lack of provided binaries reduces also chances to find bugs and I don't see why people without compiler knowledge can't help.

Isn't that ironic. Every lossy and lossless image format created after JPEG has been buried in the meanwhile because most software
and hardware don't support it or licenses were not friendly. All of them were full of hope, were so proud with their head held high.
And here we are again; the past repeats.

[thorfdbg]

Dear Thomas, Isn't that ironic. Every lossy and lossless image format created after JPEG has been buried in the meanwhile because most software and hardware don't support it or licenses were not friendly. All of them were full of hope, were so proud with their head held high. And here we are again; the past repeats.

Except that the goal here is an ISO standard (which is this good for - it is a demo software and a proof of concept for the upcoming standard), actually by the JPEG. Specifications aren't stable, the software will change, and the streams it will create will change until we reach a stable point which won't happen until probably next year. At that point it might make sense to provide binaries, but not now. I'm addressing developers, not end users. If you're too lazy to run configure - chances are better than even are you're too lazy to look at the algorithm. And this is what would help right now, not "testing on some images". I'm doing that all by myself with our test infrastructure anyhow.

[thorfdbg]

Dear Thomas, I'm completely aware about this LIBJPEG variation being something experimental rather than a product. There was no word about BMP; there are a bunch of other raster formats around The lack of provided binaries reduces also chances to find bugs and I don't see why people without compiler knowledge can't help.

Ok, here's an offer: Go to the next store, buy a Microsoft Windows-"whatever you seem appropriate" DVD/Licence and ship it to: Thomas Richter Rechenzentrum Allmandring 30A 70550 Stuttgart - Germany Only legal copies, please. Once that is done, I'll prepare a binary for you. I don't charge for my time. I don't charge for the installation time, and the setup time to install Visual Studio - I believe there is an express edition I may use. Or cygwin. I don't charge for that either. Otherwise, I'm sorry, but I really don't see why I should pay Microsoft to get you something for free. I hope you understand. No, I don't have windows here, as I already said.

[Black_Fox]

cygwin, and from there install autoconf, g++ and the C++ headers, make. Everything else is "configure" and "make"

I have that environment, ran ./configure:

checking whether ...(...)
configure: creating ./config.status
config.status: creating automakefile
config.status: error: cannot find input file: `autoconfig.h.in'

I checked whether there was any update for my cygwin packages and they seem up to date. I may be missing something else, though, I don't use cygwin unless it's really needed.

[thorfdbg]

I have that environment, ran ./configure: checking whether ...(...) configure: creating ./config.status config.status: creating automakefile config.status: error: cannot find input file: `autoconfig.h.in' I checked whether there was any update for my cygwin packages and they seem up to date. I may be missing something else, though, I don't use cygwin unless it's really needed.

I'd say, "make autoconfig.h.in" will do. (-; That's generated by "autoheader". In almost all cases, just typing "make" will also do.

[Black_Fox]

I have probably still incorrectly configured Cygwin, because neither command helps. I guess that disqualifies me

[thorfdbg]

I have probably still incorrectly configured Cygwin, because neither command helps. I guess that disqualifies me

So what happens if you type "make" on the command line?

[Black_Fox]

Many errors
"gcc: error trying to exec 'cc1plus': execvp: No such file or directory"
After some time and errors make gives up, it's probably called once per file, I don't know. "make autoconfig.in.h" said "Nothing to do".

[thorfdbg]

Many errors "gcc: error trying to exec 'cc1plus': execvp: No such file or directory" After some time and errors make gives up, it's probably called once per file, I don't know. "make autoconfig.in.h" said "Nothing to do".

Sounds to me as either the installation is corrupt, or you did not install g++ (which is required). If "make autoconfig.in.h" says "nothing to do", then it is already updated, and there was nothing to do. Note that the gcc and the g++ compilers are in two separate files. Let me know how that goes - thanks for trying. Thomas

[load]

i'm getting this:

Compiling codestream/hiddenrefinementscan.cpp
hiddenrefinementscan.cpp:68: Fehler: Prototyp f&#252;r ?HiddenScan<BaseScan>::HiddenS can(Frame*, Scan*, ResidualMarker*, UBYTE, UBYTE, UBYTE, UBYTE, bool, bool)? pas st zu nichts in Klasse ?HiddenScan<BaseScan>?
../codestream/hiddenrefinementscan.hpp:118: Fehler: candidate is: HiddenScan<Bas eScan>::HiddenScan(Frame*, Scan*, ResidualMarker*, UBYTE, UBYTE, UBYTE, UBYTE, b ool, bool)
hiddenrefinementscan.cpp:68: Fehler: Template-Definition eines Nicht-Templates ? HiddenScan<BaseScan>::HiddenScan(Frame*, Scan*, ResidualMarker*, UBYTE, UBYTE, U BYTE, UBYTE, bool, bool)?
../Makefile.template:90: recipe for target `hiddenrefinementscan.o' failed
make[3]: *** [hiddenrefinementscan.o] Error 1
../Makefile.template:145: recipe for target `subdebug' failed
make[2]: *** [subdebug] Error 2
Makefile:123: recipe for target `codestream.build' failed
make[1]: *** [codestream.build] Error 2
Makefile:197: recipe for target `debug' failed
make: *** [debug] Error 2
make: *** Keine Regel, um ?bindist? zu erstellen. Schluss.

[thorfdbg]

i'm getting this:

How did you pull this from git? I'm using a "git clone https://github.com/thorfdbg/libjpeg", followed by a simple "make", which does all I need. Which version of the compiler do you use? I'm running here g++-4.3, 4.4 and 4.7, all of which work. If you check the error message you see, then there's something wrong with the compiler (the function fits perfectly to the candidate). Please let me know. Thanks, Thomas

[thorfdbg]

i'm getting this:

Checked. This only happens with very ancient versions of the GNU compiler (g++-3.3 does this here) by not implementing class lookup correctly for templated classes or functions. I'll add a workaround for the next release, but please upgrade to a more recent version of cygwin. Thanks, Thomas

[load]

thank you. well, i'm pretty much a noob. there must be a good number of people here that could
easily compile it, i don't know why they don't bother.