Legacy ImageMagick Discussions Archive

I am trying to use ImageMagick Convert to extract the frames from an animated GIF that was created using the Samsung Galaxy S5 Sequence Shot mode. The GIF, when played on the Galaxy S5 Sequence shot player, is a smooth slow motion animation. When played anywhere else, it is a fast choppy animation. When I use Convert to extract the frames I end up with 20 frames. When played on the Galaxy S5 there are about 10 times that number of frames (the sequence shot player has a frame-by-frame advance button). What is going on? What do I need to do with Convert to extract ALL the frames so I can get smooth playback outside of the Galaxy S5? Is Samsung doing something special in the animated GIF format that ImageMagick Convert can't read correctly? Or do I need to use some special command line options to get it to extract the additional frames? I have attached a link to my GIF image. Help is much appreciated.

https://drive.google.com/file/d/0BzNh7c ... sp=sharing

- Doug

The image size is 720x1280 = 921,600 pixels. It uses a palette, 1 byte per pixel. But IM identify reports the 20 frames take 41 MB each.

exiftool also reports only 20 frames.

I suspect that more frames are squeezed into each GIF frame.

A developer might comment.

By "squeezed into each GIF frame" are you talking about a documented feature of the GIF spec, or is Samsung doing something undocumented or even outside the spec for animated GIFs? If documented, I would expect IM to be able to be configured to extract it properly.

By the way, how do you like my dive? It is much cooler in super slo-mo, so I hope I can get this extracted correctly.

- Doug

Any other ideas?

- Doug

I suspect that your Galaxy S5 is creating new interpolated frames from the original limited gif sequence, but they are probably not saved in an exportable format.

Yes, as Fred said, they are probably putting in the missing frames, or rather, they make a frame that is some kind of blend between two frames.

Just as those "240hz" or "600hz" televisions sold, they show many more frames than the actual video has, by blending frames and put them in between the original frames.

So sorry, the frames you are looking for in your Gif are not there.

Thanks for the feedback.

Does you guys theory jive with the filesize of the animated GIF? The filesize is 39.2 MB. When I use convert to extract the frames to gif, each frame ends up at 252k each. Doesn't there have to be more frames than 20 to account for the file size?

- Doug

It's hard to say without seeing what the Galaxy shows, or hacking a GIF reader to examine the data in the file.

I'm sticking to my theory that the extra frames are hidden inside the ones that IM (and other tools) can see.

The extra frames are probably hidden behind the trailer ';' of the gif file. That is the last character of a gif file (http://en.wikipedia.org/wiki/Graphics_I ... imated_GIF). Your image contains extra data after this character. I have no idea what is but this is probably something only your camera understands.

That makes sense, to me, and it's a better theory than mine.

If you optimize the gif

convert 20140706_171423.gif -layers optimize 20140706_171423B.gif

The new file size is 7.737MB.

252Kb/frame * 20 frames = 5.04MB. So not to far off. But when I optimize it and extract a frame, I get 383KB. So

383 * 20 = 7.88MB Thus closer to the the actual optimized total.

I suspect that the Galaxy S5 optimizes the gif animation before playing it or when it is created or uploaded to your S5.

Did you tell us how and where the animation was created?

The GIF is created using the Samsung Galaxy S5 camera in Sequence Shot mode (http://bit.ly/1peHfDL). It is a shot of me going off the diving platform.

I expect optimization is dropping all of the data that IM doesn't recognize or know about, thus the smaller file size. I have noted elsewhere that IM drops extension block data since that data is application specific. I am afraid that the format may be one only the phone can understand, but that seems strange that you would design it to be stored in animated GIF format, only to remove many of the frames so they can't be retrieved or rendered with standard tools. Why not just put all the frames right in the standard animated GIF format?

I have developed a way to get all the frames, but it is horrendously time consuming. Essentially, I manually step through each frame and take a screen capture via USB of the phone screen. I have only tested that it will work on a few frames, I haven't tried to capture the 200+ frames necessary for the complete sequence. I was hoping to find a better more automated way!

- Doug

Did you ever get this figured out? I just found the same issue when trying to share s sequence shot with a friend. Really stupid way to do this slow motion when they can already do 120fps @ 720p video.

I apologize for replying to this post a full two years after the last reply, but I have not found any other information on any website or forum about how you can possibly extract Sequence Shot data, aside from many unanswered questions.

I have just made a breakthrough.

If you open any Sequence Shot GIF's (in this case, the one provided in this post) in any hex editor (I used HxD), you can see that the file begins as a GIF: Eventually, the GIF ends. But, there is a lot more data after the GIF.
Right after it ends, there is the following string: Followed by file headers for a 3GP format video (with my Note 4, it shows MP4 format headers): If you simply remove everything before, and including, the "SequenceShot_Data" string (that is, making the file begin with the "....ftypisom" string), and save the file (see this video), you get the slow motion video file in all of its proper full 720p 30fps MP4 glory. All Samsung did was glue an MP4 to the end of a GIF.

Using the .GIF provided by this forum post, this is the result:
https://youtu.be/Kd_ymU_0KeA

I have tested this on Sequence Shot "GIF's" from my Note 4 and from this post and it is consistent. I have no idea why Samsung decided to do this, as simply saving the MP4 video itself would have been fine, but at least there is now an easy and properly documented way to extract it.

Excellent. Thanks for the information.