Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Image compression

Image compression

Scheduled Pinned Locked Moved C / C++ / MFC
questiondatabasegraphicsjsontutorial
3 Posts 2 Posters 2 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Offline
    C Offline
    Calin Negru
    wrote on last edited by
    #1

    What is the difference between two images looking the same, if one uses compression and the other one doesn’t. For example we have images made of 12 pixels with all pixels having the same color, except the first three which are different then the rest. If we consider a color depth of 24 bit the bitmap version will have 12*24 bit, 288 bit total. In the compressed image the first 3 pixels will weight 24 bit and the other ones another 24 bit, 48 total. The start and end pixels marking a color sequence need to be considered too, that’s index 0, index 2, index 3 and index 11. Is that correct?

    OriginalGriffO 1 Reply Last reply
    0
    • C Calin Negru

      What is the difference between two images looking the same, if one uses compression and the other one doesn’t. For example we have images made of 12 pixels with all pixels having the same color, except the first three which are different then the rest. If we consider a color depth of 24 bit the bitmap version will have 12*24 bit, 288 bit total. In the compressed image the first 3 pixels will weight 24 bit and the other ones another 24 bit, 48 total. The start and end pixels marking a color sequence need to be considered too, that’s index 0, index 2, index 3 and index 11. Is that correct?

      OriginalGriffO Offline
      OriginalGriffO Offline
      OriginalGriff
      wrote on last edited by
      #2

      Probably not - it depends on the compression method. There are two different types of image compression: lossless and lossy. PNG for example is lossless - when it is decompressed to a bitmap for display, the bitmap is identical to the original input bitmap data. JPG is lossy - when it is decompressed the resulting image is lower quality than the original. You can prove this with any image editor: load a bitmap, save it as a JPG. Open the JPG, save it as a new JPG. Repeat a few times, and watch how the image size drops, the compare the original with the final result. It doesn't take many iterations before the result as very clear to see. Do the same with a PNG file and the result will be identical to the original. There is also the problem that any form of compression adds overhead to the resulting file to manage the compression - and small files or those containing a high degree of randomisation can end up bigger than the uncompressed original as a result! If you really want to know about image compression, Google / Wiki is the place to start: but be warned that the math gets pretty hairy!

      "I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!

      "I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
      "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt

      C 1 Reply Last reply
      0
      • OriginalGriffO OriginalGriff

        Probably not - it depends on the compression method. There are two different types of image compression: lossless and lossy. PNG for example is lossless - when it is decompressed to a bitmap for display, the bitmap is identical to the original input bitmap data. JPG is lossy - when it is decompressed the resulting image is lower quality than the original. You can prove this with any image editor: load a bitmap, save it as a JPG. Open the JPG, save it as a new JPG. Repeat a few times, and watch how the image size drops, the compare the original with the final result. It doesn't take many iterations before the result as very clear to see. Do the same with a PNG file and the result will be identical to the original. There is also the problem that any form of compression adds overhead to the resulting file to manage the compression - and small files or those containing a high degree of randomisation can end up bigger than the uncompressed original as a result! If you really want to know about image compression, Google / Wiki is the place to start: but be warned that the math gets pretty hairy!

        "I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!

        C Offline
        C Offline
        Calin Negru
        wrote on last edited by
        #3

        Thanks Griff

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups