John Costella schrieb:

> This might not make sense until you've had a look at what I'm on about
> with the format. It does lossless compression (pretty well) and lossy
> compression (ok, but could probably be tweaked a lot more), but
> that's
> not the fundamental issue, which is that the format stores images in
> a
> top-down manner, in such a way that you get damn good progressive
> download performance and antialiased thumbnails, as an intrinsic and
> inherent part of the compressed file.

Of course, the natural respond to this question then would be: If you
want progression by resolution and a very good compression performance,
pick JPEG2000 which does that. (-: Actually, flexibility is probably the
 main argument why you want something beyond JPEG. For *this* type of
target application, that is.

> That then begs the question: what can I compare *that* to? Maybe
> Adam7 for PNG. Maybe I pull out some progressive modes for
> other formats. But if you've run the simulator I posted (sorry, the
> simulator is Windows only),
> 
> http://www.assassinationscience.com/johncostella/jpegclear/code/win_gui_jpc_progressive.exe
> 
> then please tell me if JPEG-LS or the other formats can provide
> comparable performance.

Ok, compiled this with -m32 on my machine, now that it works, and
applied that to the shipbig test image. I assume that with no further
options, I get lossless compression?

Ok, here we go:

The original:
thor@rusime04:~/src/jclear> ls -l s.bmp
-r--r--r-- 1 thor users 3932214 23. Nov 09:21 s.bmp

With your compressor:

thor@rusime04:~/src/jclear> bmp_to_jpc s.bmp s.jpc
thor@rusime04:~/src/jclear> ls -l s.jpc
-rw-r--r-- 1 thor users 3072488 23. Nov 13:09 s.jpc

With jpeg2000, lossless (thus, the "-l" switch):

thor@rusime04:~/src/jclear> transcoder -l s.bmp s.j2k
thor@rusime04:~/src/jclear> ls -l s.j2k
-rw-r--r-- 1 thor users 2246765 23. Nov 13:09 s.j2k

With jpeg-ls (aka "loco"):

thor@latraviata:~/src/jpeg_ls_v2.2/Encoder> locoe
/store/pics/shipbig/shipbig_o.ppm -os.loco

=============================================
SPMG/JPEG-LS COMPRESSOR V.2.1
=============================================
These programs are Copyright (c) University of British Columbia.
All rights reserved. They may be freely redistributed in their
entirety provided that this copyright  notice is not removed.
They may not be sold for profit or incorporated in commercial
programs without the written permission of the copyright holder.
Each program is provided as is, without any express or implied
warranty, without even the warranty of fitness for a particular
purpose.

=========================================================
THIS SOFTWARE IS BASED ON HP's implementation of jpeg-ls:
=========================================================
(c) COPYRIGHT HEWLETT-PACKARD COMPANY, 1995-1999.

Input  file: /store/pics/shipbig/shipbig_o.ppm
Output file: s.loco
Image: cols=1280 rows=1024 alpha=256 comp=3 mode=1 (line intlv)
Parameters: T1=3 T2=7 T3=21 RESET=64 limit=23
Marker segment bytes: 37
Total bits out: 18331096  Symbols in: 3932160  4.662 bps  (1.716 : 1)
Time = 1.330 secs : 2887 KSymbols/sec
thor@latraviata:~/src/jpeg_ls_v2.2/Encoder> ls -l s.loco
-rw-r--r-- 1 thor users 2291387 23. Nov 13:19 s.loco

On this specific image, jpeg2000 even seems to outperform loco, which
does not typically happen. I haven't picked the image for this specific
purpose, though.

For PNG:

thor@latraviata:~/src/jpeg_ls_v2.2/Encoder> pnmtopng
</store/pics/shipbig/shipbig_o.ppm >s.png
thor@latraviata:~/src/jpeg_ls_v2.2/Encoder> ls -l s.png
-rw-r--r-- 1 thor users 2423448 23. Nov 13:22 s.png

For HDPhoto:

thor@latraviata:~/src/HDPhoto> WmpEncApp -i
/store/pics/shipbig/shipbig_o.bmp -o s.wdp -c 9 -q 0
***************************************************************************
* Perf Report
***************************************************************************

Image Width = 1280, Height = 1024, total MegaPixels = 1.3 MP
m_ptEncDecPerf (excl I/O): 1802.458 milliseconds, 0.727185 MP/sec
m_ptEndToEndPerf (incl I/O): 1839.614 milliseconds, 0.712497 MP/sec
thor@latraviata:~/src/HDPhoto> ls -l s.wdp
-rw-r--r-- 1 thor users 2313737 23. Nov 13:23 s.wdp

> (If so, then why aren't they being used
> for web pages today?)

The popularity of a compression scheme is not in direct relation to its
compression performance, that's how the world is. There are many many
other factors much more relevant to market success. JPEG-LS aka Loco
also found its implementation in the Mars rover, IIRC: Very very low
complexity and very high efficiency for what it does. For the web, you
need a company that has sufficient impact to really drive a format.

> You'd then have to somehow quantify the question: How much is
> this progressive downloading (or equivalently the thumbnails)
> "worth" to you, relative to compression ratio? I doubt that it makes
> sense to have a single number that answers this, for all users and
> all
> uses. In other words, how do you perform the sum
> 
> A * ( progressive performance ) + B * ( thumbnail performance )
> + C * ( compression performance ),
> 
> if you don't know A, B and C?

Its the purpose of a metric to define those. But how to compare to
anything else if neither A,B or C is known? Basically, it means "I deny
to compare", but that's not an answer, it just denies the question.

> I guess what I'm saying is that you're used to measuring
> apples and I'm giving you an orange, and it's not obvious to me
> how you compare them. The "storage paradigm" is different.

Ok, so what's it? (Note well: I'm again playing devil's advocate, I
don't want to spoil the fun doing it) I've no problem at looking from
different angles at the problem, just that I need to know how.

> As for improving the lossy compression parameter estimation,
> I agree with you completely. The "multiple pass" method that
> is in there at the moment is a poor one, but it is at least a
> starting point. There is a significant amount of further research
> that needs to be done, but I decided that I could not do it alone
> (not least of which because I am colorbind).
> 
> I did my comparisons against PNG because that is widely
> supported. As stated, the format is optimised for "consumers"
> of images, especially images to be posted to web pages. I
> agree that it would be good if I could compare it to every other
> format on the planet, but there is only so much you can get
> done on the commuter train every morning and evening. :)
> 
> I'll endeavour to do more testing, but at the moment I'm flat
> out getting the animation/video format coded up. I decided
> that it would be better to put out what I had, than spend three
> years tying down every loose end (and indeed it is more
> likely that I will get better ideas for improvement from others
> than trying to continue on alone).
> 
> As for colorspaces, I take whatever RGB values are fed in
> (if they are fed in as RGB) as naively as BMP or JPEG
> does, with the expectation that the metadata will provide
> sufficient information for the interpretation of those values.

As for JPEG, it only (historically) defined a toolbox, not a complete
file format. This is referred to as "codestream", where no color space
information is stored. JPEG2000 does the same, but in addition also
defines a file format where this is defined. It's probably a useful
paradigm to separate the issues.

> I consciously decided to go for a "pragmatic" design
> (concentrating on those things that are needed for most
> boring real-world applications) rather than an "elegant"
> design like JPEG-2000 (which appeals to me as a
> physicist but, in practice, has many more degrees of
> freedom to tie down).
> 
> In other words, I look at web pages full of JPEG and PNG
> images, and photo folders full of JPEG images, and
> aim to better than the status quo. 

Absolutely nothing wrong with that. All I say is "it's hard to do better
unless you know what 'better' means".

>I don't try to compete
> with the J.P.E.G. (If I wanted a format designed by a
> committee, I'd use one...)
> 
> I didn't realise that the J.P.E.G had asked for submissions.
> That's an interesting idea, but at the moment I have enough
> on my plate to keep me busy for a while. :)

Please, do! As said above, I absolutely don't want to spoil the fun
(it is fun! for me it is, at least), so please keep working. I'm just
providing a "reality check" here. Don't be disappointed, there's much to
discover, and keep working.

So long,
	Thomas