How can I compress in terms of pixels not file size?

Started 2 months ago | Questions thread
NAwlins Contrarian Veteran Member • Posts: 5,966
BMP is easy, but may be pointless

Thank you for your detailed insights (and patience! )

You're welcome and no worries. Hopefully with anyone here I will just bug out before I lose patience--well at least with those not willfully spreading falsehoods.

What you have touched on all makes sense and yes I agree 4-bits per colour channel produces some pretty gnarly images. This is for research to do with a much larger project started long before I joined it and since it is a camera destined for a small Low Earth Orbit satellite I'm guessing the numbers have already been crunched and there must be a good rationale behind why we're going with 12-bit per pixel rather than 24-bit.

That's a pretty specialized application, and there may well be good reasons for the 12-bit color due to e.g. camera hardware (available when the satellite was launched!), achievable image quality (e.g. atmospheric interference issues), communications bandwidth, and/or other issues.

After further digging around, I think the file type I'm trying to extrapolate back to is an uncompressed bitmap (BMP).

Once image data has been subjected to lossy compression--as it appears to me yours has--there is no way to retrieve what was lost. But if for some reason other than needing lossless data you really need a BMP, then you can simply export your scaled image from GIMP as a BMP file instead of a PNG. Just in the export dialog box, select the .png extension and type over it .bmp, and then choose your options (for most general purposes--not sure about yours specifically--I suggest going to Advanced and choosing 24 bits, but the others can work):

And you will end up with a BMP file. I'd insert the BMP version of the previous file here to show / allow for downloading, but DPR won't allow that.

I understand that the raw file is not what I thought it was, but still, even if I had a highly (losslessly) compressed PNG

There is almost no such thing as a highly losslessly compressed photo. At least for photos, high compression is almost always lossy, and lossless compression is almost always low. There's just no free lunch here. OTOH, the compression you have here is fairly low.

x pixels wide, y pixels tall, each of those pixels must be a certain colour when the image is viewed, so surely you could 'uncompress' this image to its pure data form which would be 'pixel one is colour 'a' defined by this 12-bit number, pixel two is colour 'b' defined by this other 12-bit number' and so on, so that this file's size in bits would be the product of number of pixels and pixel bit depth?

(It's an odd idea that you could go from a smaller to larger file size theoretically this way. Unless, of course, it's completely impossible in practice; sort of like violating the first law of thermodynamics?)

Basically once lossy compression has been used, part of the 'signal' has been lost, and going to a higher-quality format simply fills the extra 'space' in the file-format 'container' with 'noise'. You can take the color defined (well, probably not truly defined, due to a lack of color management, but that's a much more complex issue*) by those 12 bits and encode it in a 24-bit (or 48-bit) format. But in doing so you have in no way improved the accuracy or precision of the underlying 12-bit data.

Applied to the 954x954 image referred to earlier, there would be 910,116 pixels, with 12 bits (1.5 Bytes) each to give an overall 'uncompressed' file size of 1.365MB (also assuming we're using the 1,000 per size step, not 1,024)

As a semi-aside, computer memory and file sizes are typically rated in steps of K = 2^10, M = 2^20, etc.; the use of k = 10^3, mm or m = 10^6, etc. does not apply.

I understand that using such an unwieldy, large file is odd, but I'm just trying to get a file that I can use to simulate how our camera and on-board-computer might go about performing its compression regimes and I'd rather not 'feed' a pre-compressed image into that simulation.

All you appear to have are pre-compressed images. You can un-compress them, but the detail lost is gone forever. How that would or may affect your compression simulation is beyond my knowledge.

*Say we have the R,G,B triplet in 8 bits of 147,28,62. What color is that, precisely? The answer depends on what are the R, G, and B primaries, and in many cases those are not defined, and the gamma applied. When an image is encoded in a specific color working space like sRGB, Adobe RGB, ProPhoto RGB, or DCI-P3, that addresses this issue. But it seems somewhat unlikely that your data is so encoded.

 NAwlins Contrarian's gear list:NAwlins Contrarian's gear list
Nikon Coolpix S30 Canon PowerShot S120 Sony Alpha DSLR-A580 Tamron SP AF 90mm F/2.8 Di Macro Tamron SP 70-300mm F/4-5.6 Di USD +5 more
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark MMy threads
Color scheme? Blue / Yellow