Legacy ImageMagick Discussions Archive

Applying a curve (or two) to a standard Hald 16 png of 172kb gives me a new - saved - file of nearly 7mb. Why the huge difference in size? Am I missing something?

s.

You applied a curve to a Hald using IM or something else? Is the new file also 8-bit png? Have you tried increasing the compression?

It is not surprising that the new file is larger, but that does seem huge.

Sorry about the lack of detail.

I'm using ImageMagick-6.8.8-1-Q16-x86-dll.exe

The curve(s) were applied using PhotoShop but saved via XnView. And yes, 8-bit.

Even the max compression only gets the file size down to 5mb.

This isn't a complaint, I should say, just a question about the wild difference in size. I've just tried a couple of other apps and get similar results: huge, huge files.

Thanks for the response, though.


Edit:

IM = 96 dpi
Other apps = 299 dpi

Possibly the answer?

I just looked at my last post. I must be going soft in the head: dpi!

Still can't get filesize down. Does anyone know the compression settings for IM's internal production of the hald CLUT?

s.

Can you post your input image and the command you are running?

If you compress the hald image, you lose information and the results may be significantly different.

What image format are you using to save the hald image before and after the processing?

You're all wandering off the point.

I use this: convert hald:16 IDENTITY.PNG and I get an identity image of 172kb. If I change around the colors and save, the file size is bumped to megabytes even with heavy compression. The question is why should changing a few colors increase the file size to that degree. Or if you prefer, how is the original hald CLUT compressed to 172kb? I'm not suggesting there's anything wrong with IM, this is just a query.

s.

You can see the compression method with: identify -verbose identity.png. What are you using the change the color and save the file?

stupid wrote:You're all wandering off the point.

I use this: convert hald:16 IDENTITY.PNG and I get an identity image of 172kb. If I change around the colors and save, the file size is bumped to megabytes even with heavy compression. The question is why should changing a few colors increase the file size to that degree. Or if you prefer, how is the original hald CLUT compressed to 172kb? I'm not suggesting there's anything wrong with IM, this is just a query.

s.

The original HALD image is 24-bit color with zip compression.

I am running IM 6.8.8.1 Q16 Mac OSX

If I do

convert hald:16 IDENTITY.PNG

I get a filesize of 177KB zip compressed (via identify -verbose ...)


If I then do

convert IDENTITY.PNG -gamma 1.5 IDENTITY2.PNG

I get filesize of 173KB zip compressed


If I do

convert IDENTITY.PNG -channel rgb -equalize IDENTITY3.PNG

I get filesize of 177KB zip compressed


So I do not see any significant change in filesize.

1) What processing are you doing on the HALD image? What is the exact command line or what tool are you using the apply the curves?

2) What is your IM version and platform?

3) How are you measuring the file size -- what tool?

1) Application of curves in Photoshop, XnView.

2) ImageMagick-6.8.8-1-Q16 on Windows (XP SP3, Vista)

3) I'm measuring the file size with IM identify.

Since you are applying the curves in another tool, it is likely getting decompressed and not recompressed. Check the compression of the file using IM identify -verbose and see if it is still zip compressed after modifying it in the other tools.

If that is the case, then after you bring it back to IM, try convert ... -compress zip ...

and see if that reduces the file size.

Yup. Still zip compressed. This time the file size is 10.36MB using stock settings in XnView.

Here is the entire dump from identify.

Image: h16.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
Geometry: 4096x4096+0+0
Resolution: 28.34x28.34
Print size: 144.531x144.531
Units: PixelsPerCentimeter
Type: TrueColor
Endianess: Undefined
Colorspace: sRGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
Channel statistics:
Red:
min: 0 (0)
max: 255 (1)
mean: 157.631 (0.61816)
standard deviation: 95.0991 (0.372938)
kurtosis: -1.14248
skewness: -0.581413
Green:
min: 0 (0)
max: 255 (1)
mean: 115.402 (0.452557)
standard deviation: 49.9953 (0.19606)
kurtosis: -0.621025
skewness: 0.0571048
Blue:
min: 0 (0)
max: 255 (1)
mean: 131.957 (0.517477)
standard deviation: 60.6219 (0.237733)
kurtosis: -0.734959
skewness: 0.401461
Image statistics:
Overall:
min: 0 (0)
max: 255 (1)
mean: 134.996 (0.529398)
standard deviation: 71.2236 (0.279308)
kurtosis: -0.608359
skewness: 0.0315798
Rendering intent: Perceptual
Gamma: 0.454545
Chromaticity:
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
Background color: white
Border color: srgb(223,223,223)
Matte color: grey74
Transparent color: black
Interlace: None
Intensity: Undefined
Compose: Over
Page geometry: 4096x4096+0+0
Dispose: Undefined
Iterations: 0
Compression: Zip
Orientation: Undefined
Properties:
date:create: 2014-01-07T18:07:28+00:00
date:modify: 2014-01-08T06:39:04+00:00
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 2
png:IHDR.color_type: 2 (Truecolor)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height: 4096, 4096
png:pHYs: x_res=2834, y_res=2834, units=1
png:sRGB: intent=0 (Perceptual Intent)
signature: 5ad75ff338a85d961c6d125df1263414949ebede64c7f4d79b96d3f24ab0e24b
Artifacts:
filename: h16.png
verbose: true
Tainted: False
Filesize: 10.36MB
Number pixels: 16.78M
Pixels per second: 16.53MB
User time: 1.016u
Elapsed time: 0:02.014
Version: ImageMagick 6.8.8-1 Q16 x86 2013-12-25 http://www.imagemagick.org

s.

I have no idea what XnView is doing. I took IDENTITY.PNG over to PS CS and applied 4 curves: RGB, R, G, B and save the result as PNG and brought it back to IM where the file size was 141KB and still zip compressed.

Does convert ... -strip -compress zip ...

change your resulting file size?

Yes. File size is now... 9.71MB.

All I can say is that XnView is screwing it up in some way. PS CS processing has no problem keeping the file size small, nor does IM processing.

Or Windows IM has a problem. One of the Windows users will need to test that out.

Does it happen when you process with just PS?