Legacy ImageMagick Discussions Archive

Well, I think it's possible to set/delete all the extra attributes - if one is using the correct names. And the IM attributes (and also the PNG chunks) seem to be called "date:create" and "date:modify": Properties: date:create: 2010-06-12T17:32:52+02:00 date:modify: 2010-06-12T17...

Never used this before myself.. But I think this should work:
convert image.jpg +set date:create +set date:modify image.png

The default of storing these dates in tEXt chunks when saving to PNG indeed doesn't seem to be very useful.

I've downloaded IM v6.6.2-4 Q16 for Windows, and I think all problems are gone now. I'm getting the same precise results as in versions up to 6.6.0-5. Sweet!
Thank you!

Thank you!

I'm getting the error, too when using pngout this way (and also 'broken pipe' errors). But I don't think that ImageMagick has any fault here. If you're interested in why the command was failing, we could ask in the forums for pngout. I have started a bug report . Edit: @aletaziar: The command from y...

Let's put it that way: This is the situation when you have a Q8 version: All conversion results get some sort of rounding, when they are stored at 8bit (so the values are not getting darker after every conversion). This is the situation with the 16bit->8bit reductions when you have a Q16 version: - ...

It seems to be a problem only in Windows. I had tested various versions - but all on Windows XP. If I convert rose.txt to a Unix TXT format, ImageMagick can read it again. Perhaps you can reproduce it with my Windows 'rose.txt': (Edit: Link deleted) (In a text editor, it should be identical to your ...

Results in this image:

The TXT file itself is fine, but it seems that only half of the image height is recreated with TXT: as input.
IIRC, this error came with IM v6.6.2.0 (versions from before are ok for me).

This happens when 8bit palette BMPs with RLE compression are created. In general, the format of the RLE compression looks odd - and erroneous pixels can pop up if you have image widths of 1 or 2. convert -size 1x256 gradient: gradient.gif convert gradient.gif gradient.bmp This should create a RLE co...

Your 'fail.pdf' is a PDF 1.7 file. Maybe your old Ghostscript doesn't recognize that relatively new format properly. You could either use something like pdftk to copy the files into a more compatible PDF 1.4 format before reading it with Ghostscript, or - as you suggested - update your Ghostscript v...

Probably it's the other way round - you have uncompressed input files, but the output files are compressed. This doesn't get displayed in the verbose output (I'm using current IM versions though). I think, the default for ImageMagick when it has to write 8bit BMPs is to use a BMP V3 header and RLE c...

OK.. Seems you have to avoid some more pitfalls. :) With the 'swan'-example, you had a 32bit name.png. This time, it's grayscale+alpha (2x8bit). Apparently, the basic '-colorspace CMYK' conversion doesn't work for this one. (The gray channel is correctly mapped to the 'K' channel. But the alpha chan...

PNG can't store CMYK. But it doesn't matter as long as you're not saving the result to PNG.

I'm also not sure where the problem originates.. It almost looks as if the fully opaque areas within name.png were treated as fully transparent again (with background color black). Or maybe the alpha channel values are somehow gettin into the black channel of the final CMYK image. Anyway, I think yo...

Thanks. The explicit 8 bit reductions are fine again now, but the implicit ones (all the examples without "-depth 8") still produce the differences. convert xc:"rgb(220,221,220)" xc:"rgb(220,222,220)" xc:"rgb(220,220,219)" -append -colorspace gray gray16.png c...