create:date and modify:date are always set

[bronson]

Is there any way to let the original create:date and modify:date just pass through, or be set to 1-1-1970, or pretty much anything that will not change each time I call convert?

I'm storing tons of pngs in a revision control system... Every time I render, the create:date and modify:date are set to the current date, so it looks like they all changed, and I get useless commits where it looks like 100% of the files have changed.

I've tried for hours to get ImageMagick to NOT set the dates to the current date. Here I've thrown every option I can find at the convert command... no change, imagemagick still sets date:create and date:modify.

Code: Select all

$ convert -resize 128x128 -strip -define png:exclude-chunk=date +set modify-date +set create-date tumblr.png tumblr.out.png
$ identify -verbose tumblr.png
...
  Properties:
    date:create: 2012-08-19T19:56:17-07:00
    date:modify: 2012-08-19T19:56:17-07:00
    png:IHDR.bit_depth       : 8
...
$ identify -verbose tumblr.out.png
...
  Properties:
    date:create: 2012-08-21T09:39:06-07:00
    date:modify: 2012-08-21T09:39:06-07:00
    png:IHDR.bit_depth       : 8
...

This is with ImageMagick 6.7.9-0 on a mostly stock Linux Mint 12, but I see the same thing with 6.7.7-6 on OSX Mountain Lion.

Thank you for any ideas! I'm baffled.

[glennrp]

You can use

Code: Select all

-define png:exclude-chunks=date

[bronson]

Thank you glennrp! However, that doesn't seem to work either:

Code: Select all

$ rm tumblr.out.png 
$ convert tumblr.png -define png:exclude-chunks=date tumblr.out.png
$ identify -verbose tumblr.out.png 
...
  Properties:
    date:create: 2012-08-21T13:48:35-07:00
    date:modify: 2012-08-21T13:48:35-07:00
    signature: 5e3447743d4396fbb758c59be8c49be331e223634bd1cb944420b6393f58d1a9
...

I tried both 6.6.0 and 6.7.9.

[glennrp]

I just tried this:

convert logo: logo.png
convert logo.png -define png:exclude-chunks=date logo_nodate.png

identify logo_nodate.png shows date-create and date-modify, but
pngcrush -n -v logo_nodate.png indicates that there are no text chunks in it.

The date-create and date-modify properties are evidently being added
by "identify", in magick/constitute.c, which sets these properties according
to the file timestamps.

In fact, if I do convert logo.png logo-olddate.png several times,
logo-olddate.png does not contain the dates inherited from
logo.png but gets new ones. That appears to be a mistake.
I can see how date:modify would be updated, but date:create
should be passed through.

Anyhow, the -define png:exclude-chunks=date does work, and
your version control system should see the pngs as equivalent,
despite what "identify" is telling you.

EDIT: I did "touch logo.png logo-olddate.png"; then
"identify" shows new dates for both (one having the PNG
tEXt chunks with dates and one without).

[anthony]

These two are generated by the image loader. Any existing properties of this type present in the image is ignored.
They represent actual information about the file being read.

Actually these should probably be per-image artifacts, (which are not saved with images) rather than properties, as they actually represent data that is internal to ImageMagick, rather than image properties.

My work with IMv7 has properly highlighted to me the differences between

• Artifacts (values associated with an image, EG: width, hight, colorspace)
• Properities (out of band, free form string settings directly associated and saved with an image)
• Artifacts (free form settings, not saved. Typically used to control later operations).
• Options (User defined free form global settings (wand not image).
  In IMv6 these roll into per-image artifacts.
  But in IMv7 these are looked up if a per-image artifact of the same name is not defined.

[glennrp]

These two are generated by the image loader. Any existing properties of this type present in the image is ignored.
They represent actual information about the file being read.

It seems to me that if a creation date is stored in the image, that should be preserved, though. IM is certainly within its rights to reset the date:modify. Unfortunately in PNG, the creation date is a free-format text chunk so I'm not sure it's possible to use it to reset date:create (we can preserve the text chunk of course, but then the output would contain that along with another text chunk containing ImageMagick's generated date:create property).

[anthony]

It won't if the values were saving internally as artefacts instead of as a property. Artefacts are NOT saved with the image.

Basically I think these are a very very old (from long before IMv6, and year 2000) miss-configuration, prehaps it is time to remove them, as that slowly the free-format text chunk that are in some existing IM generated PNG images, disappear.

The values would still be available internally in IM and represent the current files date information, but it would no longer be saved.

In fact I would have the loader specifically remove these specific 'property' it finds in a image so that it does not override the artefact.

Remember properties override artefacts of the same in percent escapes, which in turn overrides global options of the same name.

Do you agree?

[glennrp]

The values would still be available internally in IM and represent the current files date information, but it would no longer be saved.

In fact I would have the loader specifically remove these specific 'property' it finds in a image so that it does not override the artefact.
Do you agree?

I don't have a strong preference either way. But generating a new creation date for an existing image doesn't seem right.
Removing a free-format property from an input image isn't that simple, but there would be no problem ignoring any text chunks with the
"date:create" keyword. It would be easy to not generate a text chunk for these IM-generated properties in the PNG outputs.
In PNG, the modify date should actually be stored in a specified format tIME chunk instead of a free-format text chunk (note that
there has been a TODO comment in coders/png.c to that effect for probably a decade).