Animated GIF and Date Taken
Ferguson
Registered Users Posts: 1,345 Major grins
I tend to sort galleries by Date Taken either ascending or descending depending.
I did some animated gif's, and found that no matter what I try, I cannot appear to get a Date Taken into the GIF.
I've tried several things, and it won't stick. In Adobe Bridge I tried to edit one directly and it just says "error writing...".
Can Animated GIF's not have Date Taken?
I'm working around it by changing those galleries to positional sort, but that's a bit of a pain. Actually that's a small request -- if changing from an auto-sort to manual (position), it would be nice if there was a way to use the last auto sort as the starting point. I'm not sure what it uses now, it isn't random, but haven't figured out the pattern.
I did some animated gif's, and found that no matter what I try, I cannot appear to get a Date Taken into the GIF.
I've tried several things, and it won't stick. In Adobe Bridge I tried to edit one directly and it just says "error writing...".
Can Animated GIF's not have Date Taken?
I'm working around it by changing those galleries to positional sort, but that's a bit of a pain. Actually that's a small request -- if changing from an auto-sort to manual (position), it would be nice if there was a way to use the last auto sort as the starting point. I'm not sure what it uses now, it isn't random, but haven't figured out the pattern.
0
Comments
organizer set it to sort by date. Then to manual and I move some photos around and they
stuck as all others stayed in same order, by date.
My Website index | My Blog
was an instance sort (not auto) which allowed moving around photos within that instant sort.
My Website index | My Blog
Sorry, GIF's don't support EXIF information. So you won't be able to use date taken. The only dates you'll be able to use, to sort or arrange, are date uploaded and date modified. Before manually sorting, you can always set the "sort by", so you have a set starting point.
Cavig
:cavig
Allen, Steve... the idea of using the sort first as a starting point does not work for me. I'm in the new Smugmug not legacy. I did these steps
1) Sorted by date taken descending, hit done to come all the way out (just in case)
2) Changed to "Sort manually" - received error
3) Organizer refreshed, and the images came back in some other order, I'm not at all sure what order (perhaps date uploaded, but definitely not taken)
The rather idiotic restriction seems to be one image per post, so in this image showing the starting point, and will do two more posts with the error then the resulting sort order.
So... either I'm doing something that looks simple incorrectly, or it's broken, if you think when you shift to manual that it stays the same as it was.
This shows the path as well, so if Smugmug wants to look they have the location.
The gallery settings sort will override anything you do in organizer.
BTW, any folder sorting in organizer will only work if the actual folder setting is set to "sort by organizer".
My Website index | My Blog
Gesh... I thought this WAS the gallery setting. And actually it seems to be.
It looks like it is necessary to just do it a couple times. If I set it to manual, wait for the refresh, do a sort by date taken again (no error), then switch to manual they default.
Or, as you point out, I can shift to position in the settings dialog, this gives the same [unknown] order as after the organizer refresh above, then come out and set sort to date descending, THEN set manual on the organizer bar -- it stays in that proper order and I can start from there.
I don't think the gallery settings overrides this so much as they are the same setting. But there's some kind of bug when you change the setting on the organizer bar that requires you to do it twice. And in a sense, you are doing it twice also by changing it in the dialog instead of the bar.
Sorry... I just think it's broken, but I can see now how to work around it. Thank you.
can sort by date, change to manual and move photos around.
My Website index | My Blog
OK. Could be date uploaded, that looks reasonable.
What I'm saying is the sort on the option on the bar is the same as the one in the dialog. Try it. Change it on the bar and then look in the gallery settings.
The problem for me was this intermediate phase where it un-does the current sort and goes back to (probably) date uploaded. Well, that and the error message it sometimes gives. That combination is why it appears necessary to change it twice to make it "stick" as the default in manual/position.
I downloaded Adobe Bridge, and looked at a GIF (making sure no sidecar was there), and it shows that it has an IPTC Core and IPTC Extension. Those are filled in, a bit, from Lightroom (this originated as a TIF and then a save-for-web). It also has a Date Created.
Bridge THINKS I can modify those. But when I change them (like Title), and do an Apply, it gives an "error writing metadata".
But the IPTC is really there (or something is) since when I upload to Smugmug, it DOES see the Title, because it shows it on the display. When I go into Info for the shot on Smugmug, however, there's nothing there but pixel size and file size.
I haven't tried editing it on Smugmug (I'm waiting for a replacement to occur -- I uploaded new GIF's about an hour ago, it's still processing
The Date Created in the IPTC is the date taken, by the way -- I've editing this numerous times, it is not the date the TIFF was exported or anything like that; it's the date taken (of one of the layers that produced the TIF). Since it's there and being read by Smugmug, it would be nice if it used that as date taken, but I admit this is something of a niche problem.
I'm off to try to find a standards document, see what GIF's can really show, but not sure if there is -- Compuserve after all is a long, long way gone.
I think I need to correct this a bit. The GIF has an XMP block inside, which is apparently permitted, and the XMP block is the thing that contains the tags that originated normally in the IPTC blocks. Apparently (maybe?) there's no permissible ITPC in a GIF, but the XMP is permitted and it in turn can contain (some/many/most) fields from what would normally be in other blocks.
I'm not sure if this is a distinction without a difference, but it certainly does seem to prevent it from being picked up, and even though the GIF was created by Photoshop's Save-for-Web, both Bridge and Photoshop then seem confused about how to update it.
I can see the real structure with the exiftool, it allows for a very detailed dump.
Interestingly, it appears SM is supporting this XMP block partially as it picks up the title (from XMP-dc) but is ignoring the Create Date from XMP-xmp.