Compression benchmarking: 64 bit images and 24 bit codecs

[m^2]

I have a problem. I am preparing a benchmark. It contains some 64-bit images and I don't want to get rid of them. Nevertheless I'd like to test some codecs that support 24 bits only and I don't know what to do with it.
Transparency is not a problem, I can split it out to a separate file. But having 16 bits/colour is.
I think that the best thing that I could do would be to split the image into 2. Is it really? And if yes, then how?
Also, if that's the best thing then I am looking for a worse solution. I certainly don't want to spend a day or a couple coding just to get a bit better results. I spent 5 days on the benchmark already and have at least 2 of work left. Well, it's more of a computer's work, but I am occupied with it and won't move on to the next major thing w/out having it done.
What I'm considering it penalizing codecs that are limited in such way by leaving the images uncompressed (or rather, compressed as PNGs, exactly the same way that I got them). Actually for some it wouldn't be a penalty.

[Matt Mahoney]

Why don't you just indicate in your benchmark that the program doesn't support them?

[m^2]

I intend to indicate it, but I need some summary size that would allow direct (even if not perfectly accurate) comparison of competitors. The benchmark is about web PNGs, which makes me kinda like the solution of using PNGs when a codec doesn't work - after all that's something one could always do.

[Matt Mahoney]

For web images, it doesn't make any sense to have more than 8 bits per pixel because that's all a monitor can display or your eye can see. I would just remove the others from the data set or strip out the low bits.

[m^2]

As a tester I'm not to judge peoples' decisions, but to look at what they do and reflect it in my tests as accurately as possible.
Even though personally I totally agree that it's pointless.

[przemoc]

As for splitting images with high depth per color (16-bit, 24-bit or more) to test them with compressors supporting only 8-bit per color, I would go with round-robin way, to make output images still "hopefully readable", i.e. image with 16-bit per color channels would give two images, each one with 8-bit channels, first image's channels would have odd bits (15, 13, ..., 1) and second one's - even bits (14, 12, ..., 0). Similarly with 24-bit, there would be 3 images with channels having (23, 20, ..., 2), (22, 19, ..., 1), (21, 18, ..., 0) bits from original ones accordingly.

Or go with obvious sequential way: (23, 22, ..., 16), (15, 14, ..., , (7, 6, ..., 0).

[Matt Mahoney]

That doesn't seem like a realistic test to me. (The images would not look like anything you would actually encounter). It would be more realistic to just throw away the low bits. The low bits are mostly not compressible anyway.

That's assuming the image was gamma corrected. Sometimes high bit depths are used to represent true brightness values over a wide dynamic range, like http://www.openexr.com/samples.html Normally a pixel value represents (brightness)^0.45 and then the monitor displays (pixel value)^2.2 to reduce the dynamic range. This partially compensates for the fact that the eye is sensitive to brightness on a logarithmic scale. (That is why star magnitudes use a log scale, for instance).