PDA

View Full Version : Animated GIF's



jlowe
02-12-2013, 01:47 PM
I find a couple issues with animated gif files.

1. The speed of the gif in HLS animation is much, much slower than the speed of the actual gif when viewed "raw".

2. (This may perhaps be a non-issue or not affect things technically, I'm just not sure.) Once animation has started, unchecking animate effect button and rechecking it will start the frame count back at 1, but the gif image does not reset to frame 1, but animates from current position.

JHinkle
02-12-2013, 03:17 PM
I find a couple issues with animated gif files.

1. The speed of the gif in HLS animation is much, much slower than the speed of the actual gif when viewed "raw".

2. (This may perhaps be a non-issue or not affect things technically, I'm just not sure.) Once animation has started, unchecking animate effect button and rechecking it will start the frame count back at 1, but the gif image does not reset to frame 1, but animates from current position.

#1. The GIF standard gives a Delay after presenting the Image. This delay, if non zero, is the number of 1/100 seconds time events to delay.

HLS converts those delays into the proper number of Sequence TimeTics. Please note 0 (GIF says to not delay in processing the next image) can NOT be processed in HLS per the GIF standard since the minimum HLS delay is 1.

Note that in animation and Effect Creation --- YOUR SETTING for Animation speed says ... "Eat this number of Time Tics before processing the next Effect event".

So ... if your setting is greater than 1 ... YOU are adding a delay multiplier --- making things much slower.

If you want the animation to be as close to spec as possible - make sure your Animation Speed is set to 1.

#2. The intent was NOT to have the Effect start over but from where it was at --- I unfortunately set the frame counter to zero.

In the Next release --- HLS will ask what your intentions are if the Frame Counter is non-zero and you activate it.

Joe

jlowe
02-12-2013, 04:23 PM
I see. So, HLS must always have a delay of at least 1/100th of a second between frames?
I realized after I posted that I probably used a GIF that didn't respect proper rules. It appears to only have about 15 visual frame changes, but contains 1400 frames. So, it makes me think the creator of it applied a lot of frames to build a sort of delay that way. But, for HLS, that means the animation runs very slow. I just need to try different images.

2-Sounds good!

Again, always appreciate your work.

JHinkle
02-12-2013, 05:18 PM
I see. So, HLS must always have a delay of at least 1/100th of a second between frames?
I realized after I posted that I probably used a GIF that didn't respect proper rules. It appears to only have about 15 visual frame changes, but contains 1400 frames. So, it makes me think the creator of it applied a lot of frames to build a sort of delay that way. But, for HLS, that means the animation runs very slow. I just need to try different images.

2-Sounds good!

Again, always appreciate your work.

You misunderstood what I was saying.

The GIF delay is specified in 1/100th second. I convert that into sequence time tics (100 msec = 1, 50 msec = 2, 25 msec = 4).

So --- the spinning girl I showed had a Gif delay of 3 --- equates to an HLS tic delay of 6 since the sequence was at 50 msec. The total frame count I show includes the delays.

Send me your GIF so I can see what is happening to get 1400 frames. That not running frame count is it?

Joe

Lionking_Tx
02-12-2013, 10:52 PM
Joe,

Somehow this question from me was ignored so far, but yes.....regardless of tweaking the settings the speed of the pictures does seem pretty slow .
I didn't know how you handle the frame rate conversion, but the slow speed now makes sense after you explained it.

As a suggestion....Maybe you could add a multiplier option to the "speed of rotation" in order to adjust the frame rate closer to the original ?

JHinkle
02-12-2013, 11:29 PM
Joe,

Somehow this question from me was ignored so far, but yes.....regardless of tweaking the settings the speed of the pictures does seem pretty slow .
I didn't know how you handle the frame rate conversion, but the slow speed now makes sense after you explained it.

As a suggestion....Maybe you could add a multiplier option to the "speed of rotation" in order to adjust the frame rate closer to the original ?

The fastest Frame rate is having Animation Speed set to 1. That mean each Sequence Tic - an Effect Event is processed.

I may let to modify the delay associated with each Gif Frame --- if THOSE were set to 0 --- then a Frame would change EACH sequence TimeTic.

Joe

jlowe
02-13-2013, 01:49 PM
I guess I still don't fully grasp it, unfortunately...

Let me see if I'm restating this correctly:

The "Speed of Rotation" set fastest would be = 1. Which equals one HLS time tic. So, do the HLS time tics line up with frames? So, every GIF frame = 1 HLS time tic?

That's my reasoning, but, in your last post you make it clear that Time Tics are NOT connected to GIF Frames.

So, how are the frames connected to time tics? And, I guess I don't know what exactly an "Effect Event" is. Is that one animation frame? Which would be different than GIF frames?

Gosh, I know my post really doesn't make sense!

Attached is the GIF image I mentioned earlier with 1400 frames. It's just some random file I downloaded from the internet. That frame count shows up when I select the gif, input height and width, and click Generate GIF.

JHinkle
02-13-2013, 01:56 PM
If the GIF Frame delay was 0 --- meaning no delay after the frame is rendered - then HLS would render 1 frame for each sequence time tic.

If YOU delay the Event Tic from getting to the GIF engine by having Speed not at 1 --- then you are eating that many sequence tics for each tic the GIF engine thinks it getting.

If speed is 2 --- then every thing is twice as long ... a setting of 3 = everything is 3 times as long.

There are TWO things controlling GIF frame speed:

#1 -- YOU with the speed setting.

#2 -- The GIF itself with its embedded delays.

THAT is it.

Joe

jlowe
02-13-2013, 02:16 PM
If the GIF Frame delay was 0 --- meaning no delay after the frame is rendered - then HLS would render 1 frame for each sequence time tic.

If YOU delay the Event Tic from getting to the GIF engine by having Speed not at 1 --- then you are eating that many sequence tics for each tic the GIF engine thinks it getting.

If speed is 2 --- then every thing is twice as long ... a setting of 3 = everything is 3 times as long.

There are TWO things controlling GIF frame speed:

#1 -- YOU with the speed setting.

#2 -- The GIF itself with its embedded delays.

THAT is it.

Joe

Joe, again, I appreciate your patience with me! Your last explanation of the speed of rotation and how it relates to the gif frames makes absolute sense. Sorry that it took you beating me over the head with it to get it.

With the example gif that I included in my last post, I set animation speed at 1. When I animate it, it changes frames at a MUCH slower rate than if I just view it in a web browser. Now, I understand that the HLS time tics are going to set it's animation speed. So, my sequence is set for 50ms. Even so, that animated gif does not move to the first actual color change for several full seconds. That's what made me theorize that when HLS says 1400 frames, that it may be that GIF is just weirdly made and HLS is having to render hundreds of frames for each visual change in animation.

I just loaded another GIF file. It generates 60 frames. It displays raw, but, when animating, I never get any actual display. It is the Turkey file that is attached.

I also loaded my profile image (the gecko getting shot out of the cannon). It displayed correctly, but it still is much slower than viewing it in a web browser. In HLS, with speed of rotation at zero, it visually changes about once per second. When I loaded the file, HLS generates 352 frames. I feel like the problem may be coming in during the generation step. HLS generates many more frames than what "appears" to be needed. Then, when animating it in the preview window, because of all the extra frames, the animation seems slow.

JHinkle
02-13-2013, 02:17 PM
I guess I still don't fully grasp it, unfortunately...

Let me see if I'm restating this correctly:

The "Speed of Rotation" set fastest would be = 1. Which equals one HLS time tic. So, do the HLS time tics line up with frames? So, every GIF frame = 1 HLS time tic?

That's my reasoning, but, in your last post you make it clear that Time Tics are NOT connected to GIF Frames.

So, how are the frames connected to time tics? And, I guess I don't know what exactly an "Effect Event" is. Is that one animation frame? Which would be different than GIF frames?

Gosh, I know my post really doesn't make sense!

Attached is the GIF image I mentioned earlier with 1400 frames. It's just some random file I downloaded from the internet. That frame count shows up when I select the gif, input height and width, and click Generate GIF.

I looked at the internals of your GIF.

There are only 5 frames.

The delay associated with each frame is as follows:

#1 - 150
#2 - 250
#3 - 250
#4 - 250
#5 - 500

That's a total delay of 1400 1/100th of a sec.

If your sequence is running at 100 msec per tic --- then 1 complete cycle of the GIF is 1400 * .1 = 140 seconds.

edit - removed statement of error --- math still looks good.

Joe

JHinkle
02-13-2013, 02:25 PM
Joe, again, I appreciate your patience with me! Your last explanation of the speed of rotation and how it relates to the gif frames makes absolute sense. Sorry that it took you beating me over the head with it to get it.

With the example gif that I included in my last post, I set animation speed at 1. When I animate it, it changes frames at a MUCH slower rate than if I just view it in a web browser. Now, I understand that the HLS time tics are going to set it's animation speed. So, my sequence is set for 50ms. Even so, that animated gif does not move to the first actual color change for several full seconds. That's what made me theorize that when HLS says 1400 frames, that it may be that GIF is just weirdly made and HLS is having to render hundreds of frames for each visual change in animation.

I just loaded another GIF file. It generates 60 frames. It displays raw, but, when animating, I never get any actual display. It is the Turkey file that is attached.

I also loaded my profile image (the gecko getting shot out of the cannon). It displayed correctly, but it still is much slower than viewing it in a web browser. In HLS, with speed of rotation at zero, it visually changes about once per second. When I loaded the file, HLS generates 352 frames. I feel like the problem may be coming in during the generation step. HLS generates many more frames than what "appears" to be needed. Then, when animating it in the preview window, because of all the extra frames, the animation seems slow.

I just ran your turkey.

Animated just fine.

GIF has two frames with a delay of 30 associated with each one.

I built this according the the GIF specifications.

I have also read that not all browsers comply with the GIF delay standard as it was associated with a later "98" version of the spec.

Joe

jlowe
02-13-2013, 02:28 PM
Did you see my last reply above you, Joe? I may have been typing/editing it when you replied.

I see what you are saying. That, the image is set with those built in delays. But, for some reason, I guess web browsers either do not respect those delays or there is a different calculation done to come up with those delays. Take my profile image, for example. It clearly does not have much delay between frames when visually viewed on this webpage, but, I assume from some internal timings, HLS is putting in much longer delays. Could it be that there is a misinterpretation of the GIF standard? Or, could it be that it's been done wrong for many years, so web browsers just continue to respect the wrong interpretation? Something isn't adding up, but I don't know what it is.

jlowe
02-13-2013, 02:32 PM
I have also read that not all browsers comply with the GIF delay standard as it was associated with a later "98" version of the spec.

Joe

This must be the issue. I know from doing web development work that sometimes standards have been ignored for so long that the non-standard becomes, in essence, the standard. I would suspect most animated gif's are created with web use in mind. So, it would make sense that those creation tools probably are still using some incorrect method of time generation because that's what the web browsers read. I have opened these files in several web browsers with the same time results.

Now, of course, you can do with that what you will. Clearly this isn't an HLS bug. HLS is respecting the standard. But I bet most gif's people would choose to use fall in the category of NOT applying the standard appropriately.

JHinkle
02-13-2013, 02:39 PM
Did you see my last reply above you, Joe? I may have been typing/editing it when you replied.

I see what you are saying. That, the image is set with those built in delays. But, for some reason, I guess web browsers either do not respect those delays or there is a different calculation done to come up with those delays. Take my profile image, for example. It clearly does not have much delay between frames when visually viewed on this webpage, but, I assume from some internal timings, HLS is putting in much longer delays. Could it be that there is a misinterpretation of the GIF standard? Or, could it be that it's been done wrong for many years, so web browsers just continue to respect the wrong interpretation? Something isn't adding up, but I don't know what it is.

This is from the 98 version of the GIF standard




23. Graphic Control Extension.

a. Description. The Graphic Control Extension contains parameters used
when processing a graphic rendering block. The scope of this extension is
the first graphic rendering block to follow. The extension contains only
one data sub-block.

This block is OPTIONAL; at most one Graphic Control Extension may precede
a graphic rendering block. This is the only limit to the number of
Graphic Control Extensions that may be contained in a Data Stream.

b. Required Version. 89a.

c. Syntax.

7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Graphic Control Label Byte
+---------------+

+---------------+
0 | | Block Size Byte
+---------------+
1 | | | | | <Packed Fields> See below
+---------------+
2 | | Delay Time Unsigned
+- -+
3 | |
+---------------+
4 | | Transparent Color Index Byte
+---------------+

+---------------+
0 | | Block Terminator Byte
+---------------+


<Packed Fields> = Reserved 3 Bits
Disposal Method 3 Bits
User Input Flag 1 Bit
Transparent Color Flag 1 Bit

i) Extension Introducer - Identifies the beginning of an extension
block. This field contains the fixed value 0x21.

ii) Graphic Control Label - Identifies the current block as a
Graphic Control Extension. This field contains the fixed value
0xF9.

iii) Block Size - Number of bytes in the block, after the Block
Size field and up to but not including the Block Terminator. This
field contains the fixed value 4.

iv) Disposal Method - Indicates the way in which the graphic is to
be treated after being displayed.

Values : 0 - No disposal specified. The decoder is
not required to take any action.
1 - Do not dispose. The graphic is to be left
in place.
2 - Restore to background color. The area used by the
graphic must be restored to the background color.
3 - Restore to previous. The decoder is required to
restore the area overwritten by the graphic with
what was there prior to rendering the graphic.
4-7 - To be defined.

v) User Input Flag - Indicates whether or not user input is
expected before continuing. If the flag is set, processing will
continue when user input is entered. The nature of the User input
is determined by the application (Carriage Return, Mouse Button
Click, etc.).

Values : 0 - User input is not expected.
1 - User input is expected.

When a Delay Time is used and the User Input Flag is set,
processing will continue when user input is received or when the
delay time expires, whichever occurs first.

vi) Transparency Flag - Indicates whether a transparency index is
given in the Transparent Index field. (This field is the least
significant bit of the byte.)

Values : 0 - Transparent Index is not given.
1 - Transparent Index is given.

vii) Delay Time - If not 0, this field specifies the number of
hundredths (1/100) of a second to wait before continuing with the
processing of the Data Stream. The clock starts ticking immediately
after the graphic is rendered. This field may be used in
conjunction with the User Input Flag field.

viii) Transparency Index - The Transparency Index is such that when
encountered, the corresponding pixel of the display device is not
modified and processing goes on to the next pixel. The index is
present if and only if the Transparency Flag is set to 1.

ix) Block Terminator - This zero-length data block marks the end of
the Graphic Control Extension.

d. Extensions and Scope. The scope of this Extension is the graphic
rendering block that follows it; it is possible for other extensions to
be present between this block and its target. This block can modify the
Image Descriptor Block and the Plain Text Extension.

e. Recommendations.

i) Disposal Method - The mode Restore To Previous is intended to be
used in small sections of the graphic; the use of this mode imposes
severe demands on the decoder to store the section of the graphic
that needs to be saved. For this reason, this mode should be used
sparingly. This mode is not intended to save an entire graphic or
large areas of a graphic; when this is the case, the encoder should
make every attempt to make the sections of the graphic to be
restored be separate graphics in the data stream. In the case where
a decoder is not capable of saving an area of a graphic marked as
Restore To Previous, it is recommended that a decoder restore to
the background color.

ii) User Input Flag - When the flag is set, indicating that user
input is expected, the decoder may sound the bell (0x07) to alert
the user that input is being expected. In the absence of a
specified Delay Time, the decoder should wait for user input
indefinitely. It is recommended that the encoder not set the User
Input Flag without a Delay Time specified.



I am looking into allowing you to over-ride the GIF delay with your own --- so can will be able to make it any speed you like.

Joe

What are the proper TAGS to use for a code block --- one that maintains its format?

Thanks.

angus40
02-13-2013, 02:39 PM
Joe, again, I appreciate your patience with me! Your last explanation of the speed of rotation and how it relates to the gif frames makes absolute sense. Sorry that it took you beating me over the head with it to get it.

With the example gif that I included in my last post, I set animation speed at 1. When I animate it, it changes frames at a MUCH slower rate than if I just view it in a web browser. Now, I understand that the HLS time tics are going to set it's animation speed. So, my sequence is set for 50ms. Even so, that animated gif does not move to the first actual color change for several full seconds. That's what made me theorize that when HLS says 1400 frames, that it may be that GIF is just weirdly made and HLS is having to render hundreds of frames for each visual change in animation.

I just loaded another GIF file. It generates 60 frames. It displays raw, but, when animating, I never get any actual display. It is the Turkey file that is attached.

I also loaded my profile image (the gecko getting shot out of the cannon). It displayed correctly, but it still is much slower than viewing it in a web browser. In HLS, with speed of rotation at zero, it visually changes about once per second. When I loaded the file, HLS generates 352 frames. I feel like the problem may be coming in during the generation step. HLS generates many more frames than what "appears" to be needed. Then, when animating it in the preview window, because of all the extra frames, the animation seems slow.

try this version I animated it for you :)

angus40
02-13-2013, 02:43 PM
Ps your original gif had no time to it . it tried to be both pictures in the same frame .

Hls would be getting as confused as Photo shop was .

jlowe
02-13-2013, 02:54 PM
Ps your original gif had no time to it . it tried to be both pictures in the same frame .

Hls would be getting as confused as Photo shop was .

I haven't fiddled with animated gifs in forever and a day lol. I never thought to open it in PhotoShop and don't really know the "tools of the trade" for messing with gifs. I'm betting there are a lot of files on the internet which disobey standards and are a bit odd. :)


Joe- If we can control frames and how they connect to the timing tics, then it shouldn't matter if the image reflects standards or not. So, that sounds like a fine solution to me. One other issue is, looping. From my quick cursory look at wikipedia, looping was something netscape added to their browser for interpreting gif files that may not have actually been part of the standard. Right now, it looks like HLS will play the animation once. Is it possible to loop those gifs? Then, I could drag out the size of the PP effect and know that the animation would continue throughout it. Of course, this may already be there and I just messed something up...

Edit: Joe, CODE in brackets is what I would have done as well... not sure why the formatting doesn't work properly.

angus40
02-13-2013, 02:55 PM
What is the fps rate of your animator Joe ?

JHinkle
02-13-2013, 03:02 PM
I haven't fiddled with animated gifs in forever and a day lol. I never thought to open it in PhotoShop and don't really know the "tools of the trade" for messing with gifs. I'm betting there are a lot of files on the internet which disobey standards and are a bit odd. :)


Joe- If we can control frames and how they connect to the timing tics, then it shouldn't matter if the image reflects standards or not. So, that sounds like a fine solution to me. One other issue is, looping. From my quick cursory look at wikipedia, looping was something netscape added to their browser for interpreting gif files that may not have actually been part of the standard. Right now, it looks like HLS will play the animation once. Is it possible to loop those gifs? Then, I could drag out the size of the PP effect and know that the animation would continue throughout it. Of course, this may already be there and I just messed something up...

Edit: Joe, CODE in brackets is what I would have done as well... not sure why the formatting doesn't work properly.

The intention within HLS is to do automatic looping --- if your GIF completes in 3 seconds and your effect spans 10 seconds --- it will keep on looping -- it does not stop.

Joe

Lionking_Tx
02-13-2013, 03:14 PM
I am looking into allowing you to over-ride the GIF delay with your own --- so can will be able to make it any speed you like.
Joe


Cool - I will get my running cat and not a crawling one :thup2:

jlowe
02-13-2013, 03:39 PM
The intention within HLS is to do automatic looping --- if your GIF completes in 3 seconds and your effect spans 10 seconds --- it will keep on looping -- it does not stop.

Joe

This was my misunderstanding then. Thanks!