Legacy ImageMagick Discussions Archive

Try to view output.jpg. It will be much darker than the original. But other programs don't follow this convention, and think g2.jpg is in sRGB colorspace, and display it accordingly. I should perhaps say that IMdisplay, the viewer included in ImageMagick, displays both images the same (for v6.8.4-6...

Colorspaces that fail a simple round-trip test in v6.8.4-6 are: LCH, LMS, YCC, YIQ, YUV. Of these, YIQ and YUV aren't much worse than 1% off. My simple test is ... convert hald:8 src.png convert src.png -colorspace XXXX -colorspace sRGB result.png compare -metric RMSE src.png result.png NULL: ... an...

Sorry, I know nothing about Perl Image::Magick. Certainly, something has changed between 6.8.4-0 and 6.8.4-6 (to name two versions that I have available). However, I fear the IM developers wouldn't call it a bug, but a feature. Or even a bug fix. The fact that I don't like this feature is neither he...

The superfluous conversion seems to occur while writing JPGs. v6.8.4-6 on Windows 7: convert gray_ramp.jpg g.png convert g.png g2.png convert g2.png g2.jpg g.png and g2.png are visually the same as gray_ramp.png. g2.jpg is darker. Inserting "set colorspace RGB" in the final convert prevent...

With 6.8.4-0, this ... convert gray_ramp.jpg g.jpg ... gives no problems. With 6.8.4-6, the same command gives a result that is darker. To correct it (almost entirely; the remaining small difference is probably the JPG compression), I can do: "%IMG6846%convert" gray_ramp.jpg -set colorspac...

It works fine in 6.8.3-0, but not 6.8.4-0. There have been recent fixes to bugs reading GIFs, see for example viewtopic.php?f=3&t=23074

So v6.8.4 converts all 1-channel .png files to sRGB when read in? Not when read in, no. The conversion occurs when certain operators are executed. In this case, it is the "-clut" operator. IM says to itself, "This operator needs greyscale images to be in RGB space. It is currently sR...

To expand slightly on fmw's explanation: convert needs an input file and an output file. They can be the same name, but you must provide them both. So your command could be:

glennrp wrote:I believe that ImageMagick currently assumes that ... all-gray unmarked PNG images are linear.

However, in this example, IM knows the images are all-grey ("-verbose" says colorspace=gray and gamma=1), but we need "-set colorspace RGB" to prevent a conversion.

"-Crop" will chop up the image, eg ... ... will create 8 output files.

IM knows about many paper sizes, but I never use them so can't advise. See http://www.imagemagick.org/script/comma ... s.php#page

Your clut file shouldn't do anything -- the output file should be the same as the input file. And that's what happens with 6.8.3. However, the output from your 6.8.4 is different; it is lighter. I did read somewhere that 6.8.4 onwards did something different with RGB/sRGB on monochrome images. Sure ...

Isn't this what backups are for?

I put a Windows version 6.8.3-0 on Dropbox, https://www.dropbox.com/s/l7evmxggzij4f ... atic.exe?m , if that's any help.

For starters, you could use 8-bit IM. That will halve the space needed.

I'm curious to know why someone wants such huge PNG files.

Using integer arithmetic, what is eleven divided by ten, multiplied by ten? Ten. What is nineteen divided by ten, multiplied by ten? Also ten. Two different numbers have both done the round trip, yielding the same result. That is what you are seeing. You could say the tones have shifted, but that is...

henrywho wrote:... but that should be rounding, truncation ...

Yes, that's another way of putting it. See my first reply: "In general, with integer arithmetic, there isn't a 1:1 mapping between colorspaces."

Try non-integer arithmetic, ie IM with HDRI. Your three commands then give identical results.