Legacy ImageMagick Discussions Archive

I have taken a grayscale TIFF that measures 92160 x 46080, converted it into MPC format, and created 32 tiles from that image, converted into PNG format. Each tile is a square 11.520 px on a side.

But the tiles are only between 6 and 11 MB each. GIMP reports they are indeed 16-bit grayscale, and they look right when open, but their size doesn't make sense.

I also took that same MPC and resized it as a PNG measuring 65,536 x 63,768 px, and cut that image into 32 tiles, 8192 px on a side. Those tiles are between 23 and 64 MB in size, which is what i'd expect.

I've taken the same tile in each set and looked at them together in GIMP. Both are reported as 16-bit grayscale images. Both look fine to the naked eye. When uploaded to the server, they take the amount of time you'd expect for the file size shown. I downloaded one of the small ones again, and it opened fine and looked the same.

But something is not right here.... All i can figure is, the PNGs that are 11,520 px in width and height have actually been downsampled to 8 bit and GIMP is lying to me when it says they are 16-bit. How can i correct this, and get those tiles in 16-bit grayscale? Or is there some other issue?

An example of the mysteriously small files is at https://www.moonwards.com/downloads/LOL ... les-22.png. It's 12 MB.

This was done with IM 7.0.7 Q16 on Ubuntu 18.04.

PNG is a compressed format. So the file size will be smaller than WxHxBytes= WxHx2 = 11520x11520x2 = 265420800 = 265 MB (16bits=2bytes). So I would guess that the compression is working well for that image.

If I convert to non-compressed tif:

convert LOLA-fullRes-tiles-22.png -compress none tmp.tif
identify tmp.tif
tmp.tif TIFF 11520x11520 11520x11520+0+0 16-bit Grayscale Gray 253.125MiB


Note that 1 MB = 1,000,000 bytes and 1 MiB = 1,048,576 bytes

See https://blog.digilentinc.com/mib-vs-mb- ... ifference/

Yeah, but they are ALL around that size, while the images that are 8192 px on a side are ALL around 40 MB

I am listing in MB in all cases, as reported by my file system. Compression levels weren't set in any of these operations.

What types of images? Photographic or graphic? Compression can vary depending upon the type of images and its content.

The source is in both cases the same GeoTIFF file, which is a grayscale image depicting a heightmap of the Moon.

The only difference is in one case i scaled that file down to 65536 x 32768 before slicing it into tiles - let's call it image A, while in the other case, image B, i left it it's original size, which was 92160 x 46080. So, the source is the same, there is the same number of tiles in each case, but the tiles from image B are on average a fifth of the size of the ones from image A.

I didn't set compression anywhere. But image A is a PNG created from the original TIFF, while image B is an MPC taken from the original TIFF

I'm inclined to do it again, cutting the original TIFF into tiles, instead of using the MPC, though i will lose use of my computer for a few hours.

I would continue to use MPC, since it is memory mapped and will process faster. I am not sure what is going on, but the rescaling could be adding more colors and causing different compression in the final PNG.

Perhaps one of the other expert ImageMagick users will have some further thoughts.

Well, an experiment where i created one tile from the original TIFF yielded a file even smaller than the one taken from the MPC, 6.1 MB versus 7.3 MB - so no explanation there. And it took over half an hour.

You are right that the rescaling added colors. Lots of them.

Tile from image B, derived by simple cropping of the MPC:


Same tile from image A, which was resized from the original TIFF:

briligg wrote:GIMP reports they are indeed 16-bit grayscale ...

Beware that an image may have 16 bits/channel, but be made from an image with fewer bits/channel. In such cases, it will have a "comb" histogram such as the one you show from image B.

I wish i knew how to resize this image without changing the gray tones. The file sizes have ballooned up tremendously in the tiles from the resized image, but the tile dimensions taken from the image of original size are problematic for use in 3d models. They are really supposed to have dimensions that are powers of 2 so all the different GPUs, devices, OSs, and software they will run on don't have problems with them.

Is there maybe a way to resize without resampling? Some way to index the colors or something like that?

briligg wrote:Is there maybe a way to resize without resampling?

Perhaps you want "-sample" instead of "-resize". Then no new colours will be added.

Ah, looking at the explanation of -sample revealed the method i'd prefer, though it takes longer:

The results are thus equivalent to using -resize with a -filter setting of point (nearest neighbor), though -sample is a lot faster, as it avoids all the filter processing of the image. As such it completely ignores the current -filter setting.

I had asked around and been told nearest neighbor interpolation was what i wanted, but i didn't find it when i looked initially. I didn't realize that's what 'point' means. -Sample eliminates entire rows and columns of pixels, and as this is for creation of a 3d terrain, where close in each pixel in this image is about 200 meters, that sounds like there are situations where it would create distortion i really don't want.

https://www.imagemagick.org/script/comm ... php#sample

briligg wrote:I had asked around and been told nearest neighbor interpolation was what i wanted, but i didn't find it when i looked initially.

Yes, that's what "-sample" does. For each output pixel, it uses the closest (in x-y coordinate distance) input pixel.

Yes, a consequence of nearest-neighbour is that entire input rows and columns will be omitted.

If you need to ensure no new colours are added, an alternative method is to "-resize" and then "-remap" to the original input. For example: I expect the result would be more technically correct than "-sample" gives.

Nearest neighbor does the same thing? Heck. This was not mentioned, and is rather important. Processing that way has completed, and to the naked eye doesn't have problematic artifacts, after a quick inspection, but that certainly doesn't mean there aren't any. There are indeed sudden tonal changes that are visible especially in the flats of the lunar maria, but that could be smoothed in Blender.

The method you suggest does really sound better. I am going to run the process again with that command.

This first try reduced file size from 1.46 GB to 168 MB, a pretty great improvement.

I have now done both operations. The image that was processed with -filter point seems to have the same number of colors as the original. I can't open the full original image, but an image that combines two tiles from it with especially bright and dark points has 153 shades, while the resized image has 157.

The image that was resized with -remap has 41 colors. So no new colors, but most colors removed. That's too much. I'm going to work with the image done with the point filter.

Reducing the depth to 8 bits trimmed that file a little more. It is now 146 MB, a tenth of the size of the resized image without the filter.