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

Started 2 months ago | Questions
CameronCox New Member • Posts: 3
How can I compress in terms of pixels not file size?

Is there a (free and hopefully not too complex) way to compress an image from 'a' x 'b' pixels to 'c' x 'd' pixels?

Context:

I'm trying to take a high-res satellite picture of Earth at 2500x1187px, and lower its resolution by a factor of 1.6 in each dimension.

Satelite images have what is called spatial resolution meaning that every pixel in the image represents some distance on the ground, so a really good camera might have spatial resolution of 1m, and a bad camera might have 3000m. The image I have has spatial resolution of 10m, but the camera that my project's satellite is using will have a spatial resolution of 16m. Hence the need to adapt the original image to a lower resolution so it can better represent what our satellite's images might look like.

So I need a way to change the image dimensions to:

2500/1.6 = 1563px width

1187/1.6 = 742px height

Any help would be greatly appreciated, thanks!

ANSWER:
This question has not been answered yet.
Ysarex
Ysarex Senior Member • Posts: 2,847
Re: How can I compress in terms of pixels not file size?
2

CameronCox wrote:

Is there a (free and hopefully not too complex) way to compress an image from 'a' x 'b' pixels to 'c' x 'd' pixels?

Context:

I'm trying to take a high-res satellite picture of Earth at 2500x1187px, and lower its resolution by a factor of 1.6 in each dimension.

Satelite images have what is called spatial resolution meaning that every pixel in the image represents some distance on the ground, so a really good camera might have spatial resolution of 1m, and a bad camera might have 3000m. The image I have has spatial resolution of 10m, but the camera that my project's satellite is using will have a spatial resolution of 16m. Hence the need to adapt the original image to a lower resolution so it can better represent what our satellite's images might look like.

So I need a way to change the image dimensions to:

2500/1.6 = 1563px width

1187/1.6 = 742px height

Any help would be greatly appreciated, thanks!

Any basic image editor (Photoshop, GIMP, etc.) can do that. Some degree of interpolation will be necessary.

Digital Nigel Forum Pro • Posts: 13,896
Re: How can I compress in terms of pixels not file size?

Any photo editor will do it easily. But if you don't have one, and it's just a single image, post it here and someone will happily do it for you.

 Digital Nigel's gear list:Digital Nigel's gear list
Panasonic FZ1000 Canon PowerShot G7 X Nikon Coolpix P900 Panasonic ZS100 Sony RX10 III +19 more
plain text Senior Member • Posts: 1,805
Re: How can I compress in terms of pixels not file size?
2

Irfanview, Faststone

Both free

 plain text's gear list:plain text's gear list
Fujifilm FinePix S100fs Sony Cyber-shot DSC-R1 Canon EOS 50D Canon EOS 550D Canon EOS 600D
NAwlins Contrarian Veteran Member • Posts: 5,942
Very specific suggestion
4

Is there a (free and hopefully not too complex) way to compress an image from 'a' x 'b' pixels to 'c' x 'd' pixels?

Context:

I'm trying to take a high-res satellite picture of Earth at 2500x1187px, and lower its resolution by a factor of 1.6 in each dimension.

Satelite images have what is called spatial resolution meaning that every pixel in the image represents some distance on the ground, so a really good camera might have spatial resolution of 1m, and a bad camera might have 3000m. The image I have has spatial resolution of 10m, but the camera that my project's satellite is using will have a spatial resolution of 16m. Hence the need to adapt the original image to a lower resolution so it can better represent what our satellite's images might look like.

So I need a way to change the image dimensions to:

2500/1.6 = 1563px width

1187/1.6 = 742px height

As others have said, there are a bunch of pieces of free software that can do this, and a bunch of different ways to do it. Given that maybe you're a newbie and need specific directions instead of general suggestions, I'll be specific with directions for one of the IMO better ones, at least without getting too complicated:

1. Go to the official GIMP downloads page (https://www.gimp.org/downloads/) and download it.

2. Install GIMP.

3. Run GIMP.

4. Do a File -> Open... and find the file you want to work on. Here's one at 2500x1187 pixels:

5. Do an Image -> Scale Image ..., then in the dialog box that appears, next to Width, change the 2500 to 1563, from the Interpolation drop-down choose NoHalo, then click the Scale button.

6. Do a File -> Export As..., by Name type in whatever file name you want (maybe just keep the original and add -rev. or sometime like that), click Export, and then for some file types you may want to adjust Quality (larger number means less risk of artifacts but bigger files sizes--I would not go below 85% unless you really need small files), then click the second (i.e., newer dialog box) Export button.

Your as-reduced file should be in the directory by the original file, under the new name you chose. If you download the files above, you'll see the proper sizes.

By the way, this process is not (here at least) typically called "compression", with "resampling" being maybe the most usual term.

 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
OP CameronCox New Member • Posts: 3
Re: Very specific suggestion

Thank you, yes that was precisely what I was trying to achieve.

One further question: Do you know if it is possible to take a png file and convert it to its raw components? I know its a very messy and roundabout thing to do, but I don't have access to the original raw files, but since png is lossless compression, each pixel should still be the correct colour, and I need a raw version to illustrate how large the file would be initially.

If that didn't make sense, to put it another way, I have a 459.2KB png image of 954x954 pixels. The Bit depth is 4-bits per channel/12-bits per pixel. I need a file that represents the full uncompressed data which would be (954 x 954 x 12)/8 Bytes large, which equates to 1,365KB. My working assumption is that is what the 'raw' file means, but all online png to raw converters either do not work or give a result that is even smaller in storage size

Digital Nigel Forum Pro • Posts: 13,896
Re: Very specific suggestion
1

CameronCox wrote:

Thank you, yes that was precisely what I was trying to achieve.

One further question: Do you know if it is possible to take a png file and convert it to its raw components? I know its a very messy and roundabout thing to do, but I don't have access to the original raw files, but since png is lossless compression, each pixel should still be the correct colour, and I need a raw version to illustrate how large the file would be initially.

If that didn't make sense, to put it another way, I have a 459.2KB png image of 954x954 pixels. The Bit depth is 4-bits per channel/12-bits per pixel. I need a file that represents the full uncompressed data which would be (954 x 954 x 12)/8 Bytes large, which equates to 1,365KB. My working assumption is that is what the 'raw' file means, but all online png to raw converters either do not work or give a result that is even smaller in storage size

You can't convert any other file type into a raw file. Raw files differ in size, based on whether they are compressed or not, lossless or not. The smallest of them (lossy compressed, as used by most Sony cameras) are roughly 1.1MB per megabit. So, your 954x954 would equate to a little over 1MB, though of course no raw files are that tiny, as cameras have much larger sensors than that.

 Digital Nigel's gear list:Digital Nigel's gear list
Panasonic FZ1000 Canon PowerShot G7 X Nikon Coolpix P900 Panasonic ZS100 Sony RX10 III +19 more
NAwlins Contrarian Veteran Member • Posts: 5,942
Re: Very specific suggestion
4

Thank you, yes that was precisely what I was trying to achieve.

You're welcome.

One further question: Do you know if it is possible to take a png file and convert it to its raw components? I know its a very messy and roundabout thing to do, but I don't have access to the original raw files, but since png is lossless compression, each pixel should still be the correct colour, and I need a raw version to illustrate how large the file would be initially.

No, it is categorically impossible to convert a PNG into a raw file. The raw data is not even RGB data, but (typically) R-G-B-G pixels that need to be de-mosaiced and color-balanced. Also, AFAIK the vast majority of PNGs are only 8 bits per channel, but raw files are typically 12 or 14 bits per channel.

If that didn't make sense, to put it another way, I have a 459.2KB png image of 954x954 pixels. The Bit depth is 4-bits per channel/12-bits per pixel. I need a file that represents the full uncompressed data which would be (954 x 954 x 12)/8 Bytes large, which equates to 1,365KB. My working assumption is that is what the 'raw' file means, but all online png to raw converters either do not work or give a result that is even smaller in storage size

You appear to have some misunderstandings about raw files and file sizes. If you have a PNG of 459 KB for a 954x954 pixel image, it is almost certainly compressed, but 8 bits per channel. Just to point out, 4 bits per channel would only give you 4096 possible colors, i.e., very poor image quality by any reasonably-modern standard. If the PNGs are lossless, then very likely you have 8-bit-per-RGB channel data compressed almost 6:1, which I tend to suspect may be lossy.*

As hinted at above, a raw file is something else entirely. It contains (basically) the output of the sensor's analog-to-digital converter for each sensor pixel. But in the vast majority of cameras, each sensor pixel sits behind a red, green, or blue filter, and therefore does not contain full color data. The full color data for each pixel is derived by a process called de-mosaicing, whereby e.g. the red value from the pixel itself is combined with the green and blue values of nearby pixels to estimate the color of that pixel. In the process, the raw converter has to account for the differences in the optical properties of the red, green, and blue filters on different senor pixels. E.g., if you shine a while light on the senor, the ultimate de-mosaiced values for each pixel should all be R = G = B, but the raw data will show different values for each. It's a pretty complicated process, and I'm oversimplifying, but maybe you get the idea why what you want is basically impossible.

*The math works like this: in typical image files like JPEGs and PNGs, the color of each pixel is represented by 1 byte = 8 bits for each of the red, green, and blue channels. For for 954 x 954 pixels x 3 bytes/pixel = 2,730,348 bytes = 2666 KB. If the file size is 459 KB, then there has to be about 5.8:1 compression. My strong suspicion is that any normal image requires lossy compression--albeit not so lossy as to be a big quality problem--to achieve 5.8:1.

 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
OP CameronCox New Member • Posts: 3
Re: Very specific suggestion

Thank you for your detailed insights (and patience! )

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.

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

I understand that the raw file is not what I thought it was, but still, even if I had a highly (losslessly) compressed PNG, 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?)

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)

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.

I apologise if I've just come full circle again and asked the same question but I think this might be a slightly different track I'm on now?

Again thanks for the terrific help!

NAwlins Contrarian Veteran Member • Posts: 5,942
BMP is easy, but may be pointless
2

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 MMy threads