Results 1 to 7 of 7

Thread: Compression benchmarking: 64 bit images and 24 bit codecs

  1. #1
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,611
    Thanks
    30
    Thanked 65 Times in 47 Posts

    Compression benchmarking: 64 bit images and 24 bit codecs

    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.

  2. #2
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 779 Times in 486 Posts
    Why don't you just indicate in your benchmark that the program doesn't support them?

  3. #3
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,611
    Thanks
    30
    Thanked 65 Times in 47 Posts
    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.

  4. #4
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 779 Times in 486 Posts
    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.

  5. #5
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,611
    Thanks
    30
    Thanked 65 Times in 47 Posts
    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.

  6. #6
    Member przemoc's Avatar
    Join Date
    Aug 2011
    Location
    Poland
    Posts
    44
    Thanks
    3
    Thanked 23 Times in 13 Posts
    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).

  7. #7
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 779 Times in 486 Posts
    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).

Similar Threads

  1. Fast Bit I/O
    By encode in forum Data Compression
    Replies: 12
    Last Post: 10th October 2011, 15:17
  2. New lossless compressor for 24-bit images (3 channels, 8 bits per channel)
    By Alexander Rhatushnyak in forum Data Compression
    Replies: 28
    Last Post: 23rd September 2010, 02:43
  3. Replies: 6
    Last Post: 20th August 2010, 00:59
  4. Poor compression of bit-version of PPM
    By Stefan in forum Data Compression
    Replies: 20
    Last Post: 16th March 2010, 17:58
  5. BIT Archiver
    By osmanturan in forum Data Compression
    Replies: 137
    Last Post: 16th January 2009, 20:19

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •