add GIF support for image() function #3380
Currently, animated .gif files loaded via
I would love to solve this issue !
Since we are trying to implement gifs, can we consider this as an ad hoc solution ,
As a permanent solution, parsing the gif into separate image frames and drawing them to the canvas in a loop seems to be the only way. If this is agreed upon, I will start working immediately !
@shiffman ( hello ! very excited to meet you !)
Looking forward to the suggestions ,
I think this issue needs to be more scoped out than it currently is...
In addition, in cases where the gif is set not to repeat at the end:
That's a bunch of questions that would help guide implementing this, because depending upon the feature set the implementations would be far different
@meiamsome Thank you for suggesting the different cases that need to be handled !
On the basis of your questions, I believe creating a sprite class would be helpful, where handling gifs would be one of its functionality . I would love to hear people's thoughts on this
Waiting to hear more about this ,
My thoughts: I think the behaviour should be as close to DOM behaviour as possible and where undefined be what the user would expect out of the gif they loaded. To elaborate:
Yes, I least that's what I would expect intuitively.
I would go for "b", as mentioned at the beginnning, that's what I expect the gif to do (when opening it up directly in a browser or viewer, that's what it does)
Again "b" here, to keep the framerate of the gif tied to real time and not p5.js framerate.
I would go for "a" for this as that provides more flexibility.
It definitely should stop on the last frame, if the user wants it to loop in p5 there can be a
Could this be achieved by a user defined check that the current playhead is at the length of the number of frames in the gif? Much like how you would check if a video has finished playing or not.
One thing to note here is that the user will most likely already seen the gif playing before they decide to load it into p5 (either when they download it from a website or when they created it in something like Photoshop) as such they would have expectation about what the gif would do and I think what we should try to do is to match those expectation as much as possible by default, while providing API that can control them.
@limzykenneth thank you very much for your suggestions !
The current implementation I have in mind, after referring online and looking into the library referenced by @shiffman , is to parse the gif into its constituent images, and store them together, to be displayed in the canvas , mostly by using the image function.
If I can continue on this discussion,
I understand the importance of this , but I also have a doubt, since the rate at which the canvas is updated is controlled by the frameRate(), we cannot have the gif run separately at its own frameRate ( to my knowledge ) , as its also drawn on the canvas.
This means when the frameRate is very low (very large elapsed time ), it can result in the skipping of the frames of the gif. Also , a situation , though quite rare, is that the time delay between different frames of the gif can be different, adding to the complexity.
A crude formula for calculating which frame to render can be,
This will prevent skipping of frames, but will appear slow in low frame rates.
I am in support of this.
I am in support of this.
Can we do this by adding an extra parameter to the class which will most likely be created ?
I am in support of this. But also if you believe that the user already has control of which gif they are going to use, imho, converting it into a video will give the user the support of the already existing video functionality, as well be more efficient as a video's size is drastically less than the gif. Could this be implemented as the temporary solution ? The only adverse effect of using this strategy is that the user cannot use gifs from the internet easily, but considering that giphy, the biggest source of gifs , serves every gif in video format also, maybe this can be implemented ?
Currently I am considering the creation of a sprite class feature as the initial step , which is very similar to what we are doing here. But I believe if that is to be implemented, it will be frameRate dependent,
I would start working on it if I have the approval of the basic implementation by the maintainers .
Would love to hear your thoughts on it ,
For me in this case I think of the loaded gif as you mentioned in the beginning to be a series of images (a data structure) and p5.js is responsible for displaying them. To display the gif in realtime would just be controlling the current frame displayed based on the delta time of the last p5 frame which we kinda already have the mechanism to do it already with
Skipping gif frames here to me seemed reasonable since if your p5.js sketch is operating at 1fps you wouldn't be expecting something that is in the sketch itself to be updating faster than 1fps. And with a function under the gif instance to change the playback fps the gif playback speed can be matched to the sketch's fps as well if desired.
The API p5 users would be used to would probably not be anything that uses any kind of constructor with
I think giphy still do serve pure gifs and in addition to video format, same goes for imgur. I'm not sure how well transparency is supported by videos but if they do support it it would still be rather different from gifs (gif transparency are on or off only, no inbetween). Also it is important to not have the user be tied to a particular source of data, as mentioned in my last comment, people do make their own gifs sometimes.
Upon doing some research on the problem,
Reason: Currently , I am planning to write the parser based on the referenced code, modified to suit p5,
Reason: The reason for creating a new class p5.Gif is because it becomes easier to manipulate the existing features, and introduce new features such as changing the play mode (real time vs matching the canvas frameRate), setting offsets, etc.
for the basic functionality
This method can be included in the image function , but imho I think separating the functionalities makes the usage more clear
I request you to check the implementation idea, if you agree to it , I will start working on the basic features immediately.
I would prefer not to have a separate class for gifs as that adds additional difficulty for the user to use this functionality. Also the code referenced in the stackoverflow answer have a caveat of "NOT for commercial use" which although I don't know how enforceable it is, I'm not comfortable with recommending its usage here.
I would suggest to hold off on actual implementation for the moment as so far I've been voicing my opnion and that does not necessarily reflect the overall concensus of the community or the project maintainer. We should start the implementation only when we have agreed on a rough outline or just as a proof of concept.
@limzykenneth , I am sorry for wording it incorrectly, what I meant was that it is better to write our own parser based on GIF89 standards (not copy the code in the stack overflow answer, rather using its logic so to speak) , such that it is highly flexible to our needs, removing any dependency issues if we use any external library specifically for this.
Yes I understand your concerns regarding the overall consensus, and I am ready to hear more about it.
Thank you for clarifying !
Continuing the discussion, if we consider parsing the gifs into the individual frames (I am unaware of any other implementation at the moment ) , what is the general view on using external libraries to achieve this ? I was able to find a few good libraries such as
which handle this part well
The advantage would be that the unimportant implementation details (such as the decompression function) would not be present directly in the code, allowing us to write only the important parts, and the code will still remain easier for people to read and understand (abstraction over gif parsing).
The disadvantage would be the dependency on the external library. If one feature breaks in the dependent library it would be difficult to fix here, whereas if we write it on our own, it would be highly customisable to our needs. I think the final file size would also be increased significantly.
Would love to hear the community's thoughts on this.
Hello everyone !
I would love to take up this issue to work with the processing foundation this summer , and I have written in the processing forum about some of the features I would like to implement :
It would be extremely helpful if you could guide me and provide feedback, which would help me immensely in contributing to this wonderful organisation .
Thank you for your support !