Legacy ImageMagick Discussions Archive

Nope. Wrong again. Back where I started. Any information would be appreciated but I won't hold my breath. Thanks.

s.

This line is the clue:

png:pHYs: x_res=2834, y_res=2834, units=1

The density is way over. If it's adjusted the file size drops to normal. Obviously not IM's problem but worth knowing. -density is the same as dpi isn't it?

s.

I can't test PS I'm away from where I normally am. I just downloaded FastStone Image Viewer, tested, and have a similar huge file.

s.

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

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 ...

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.

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 ...

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.

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 ...

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.

-threshold 50% returns a black image; -threshold 1% returns what I'd expect from -threshold 50%. Have I nodded or is this a bug?

s.

?

+noise Random -modulate 100,0

(If you're generating noise for a simulatation of film grain it shoulld be +noise Poisson instaead of +noise Random.)


s.

What I'm querying is the inconsistency:

noise generation + desat = dark
random thesholding + desat = no change in gamma

-modulate 100,0 shouldn't involve colour space changes; it's just a desaturation op. Or so I thought.


s.

Just a further question on the colour space theme. This: -evaluate PoissonNoise 2 -modulate 100,0 gives a very dark result; but this: -random-threshold 0x100% -modulate 100,0 gives the correct result without any translation of the colour space. Is the darkened output with -evaluate PoissonNoise 2 to ...

Got it. Thanks for your trouble.


s.