The BitDepth property of an image file tells you nothing about how the image file represents the data. It does not mean that 24 actual bits were stored for each pixel of an RGB (3 color) image with 8 bits per component. A BitDepth that implies 8 bits per component does not mean that there are at least 129 different component values used in the image. The BitDepth talks about how many bits are required per pixel when the image is fully decoded, such as when you read it in using imread()
To reduce the BitDepth property as you write the image back out, you would have to reduce the number of color channels, or you would have to use a representation that used fewer bits per pixel (possibly losing information as you did so.) For example, if the image were 48 bits per pixel because 12 bits per component were needed for 3 color panes, then if you were to reduce down from 4096 colors to 256 colors you could probably write out an image that had a BitDepth of 24 instead of 48.
Now, I see the "compression" tag on your question, and that tells me that you are confusing some related matters.
Nearly all of the image file formats already do compression. PNG files already do lossless compression (JPEG files normally do lossy compression.)
If the goal were to read in the PNG file and write out an altered matrix in such a way that a new smaller PNG file was the result, then a lot of the time (but not always) you can get that just by writing out the data without change -- because that process would end up removing all of the metadata stored in the PNG such as the exposure values and the date/time and copyright information. This would, however, not be considered image compression.
If you were given a PNG file without any metadata and if the goal were to read in the PNG file and write out an altered matrix in such a way that a new smaller PNG file was the result, then you would have to study exactly how PNG files do their lossless compression and trick it into creating a smaller file. This would, however, probably not be considered image compression either.
Basically, what is considered image compression is to receive image data (somehow!), and to write it out "raw" (or raw plus fundamental information about image size), and look at the size of the binary file created; and then to work out a way of encoding the image data such that when the encoded representation is written out to a binary file, along with any other data needed to decode the image (such as a huffman dictionary) then the total size of the output file is smaller than the size that would be required for the "raw" data.
For example, if you were to analyze an RGB image, and were to notice that only 30 different RGB colors were used, then you could map each pixel into a number from 0 to 29, and then you could write out a stream of 5 bits per pixel, along with the information about the RGB components for those 30 colors; the result would typically be smaller than the original raw data. In such a situation, the compression ratio would become approximately 24 (bits per pixel) : 5 (bits per pixel) in the limit of a "sufficiently large" image. (In very small images, the cost of representing the 30 colors could make a significant difference to the ratio.) In this hypothetical example, the representation would become (slightly worse than) 5 bits per pixel
When you are talking about compression techniques, you are not typically comparing the size of the image file that you read the data in from: you are typically instead doing calculations based upon the best possible representation of binary data that you can come up with.
There are a lot of different techniques available that can reduce the average number of bits written to file per raw input bit. Run length encoding. Huffman encoding. Arithmetic encoding. Zig-Zag encoding with pulse-modulation techniques. LZW compression. And more. Sometimes DCT or wavelet techniques can be made lossless, but those techniques are better suited for lossy encoding.