Yes, it looks like a bug in LibreOffice Impress. I have written a batch export script for Gimp, just in case some user wants to automatize this bypass-procedure, where 500 is the 500 ms delay (50 centiseconds in the macro of my previous post).
Could it be added at these points also to the documentation, to clarify it / or say at least “->see WriteImage function for more details”? Otherwise, each user has to search deeply in the code until finding the reason.
root.cern.ch/root/html/src/TASI … x.html#634
uses the last image (i=10) to make it an infinite loop. But the delay between the last image of the loop and the first one is the default one (“0”). Is there a way to say at the same time → I want a delay of 50 cs and also an infinite loop?
If I want an infinite loop, I have to write my last frame as
c->Print("test_gifs.gif++");
However, the delay between the last image of the loop and the first one is 0 (or non-existent). See the output of gifsicle when analyzing the image created by ROOT:
See also in the gif image the attached result, where the image #3 is just a short “flash”.
Could ROOT include in the future a way of controlling this last-frame-delay? Maybe with a syntak like “++50++”. The bypass I use now, namely to write twice the last frame (once with ++50 and the last with ++) does not seem very clean to me…
I suggest you post a lira request for that.
may be the delay would be always added at the end ?
No need for a new option exist already.
Note that any implementation you may do is welcome.
They answered the bug report. Apparently, GIFs generated by ROOT have a weird metadata order that does not fulfil exactly the standard. Could you check it?
@ferhue I just looked the point #8 you mention here. I am a bit confused because the file referred in that point (gifread.cxx) is not part of ROOT… Can you clarify what the problem is ? may be post a macro and some instructions reproducing it ? The Jira report linked to this post is closed since a long time and tells all is fixed.
//root -l -b -q test_gifs.cpp+
#include "TCanvas.h"
#include "TPaveText.h"
#include "TSystem.h"
void test_gifs()
{
const TString kGifName = "test_gifs.gif";
const TString kGifSleep = "50";//centiseconds
gSystem->Unlink(kGifName.Data());//delete existing file
TCanvas* c = new TCanvas();
TPaveText* t = new TPaveText(0.55,0.65,0.8,0.85,"brNDC");
t->AddText("1");
t->Draw();
c->Print(kGifName+"+"+kGifSleep);
t->AddText("2");
t->Draw();
c->Print(kGifName+"+"+kGifSleep);
t->AddText("3");
t->Draw();
c->Print(kGifName+"+"+kGifSleep);
t->AddText("4");
t->Draw();
c->Print(kGifName+"++"+kGifSleep);//Two ++ makes an infinite loop (replay gif)
}
Then insert the generated file test_gifs.gif in a LibreOffice Impress slide. There, you will see that the gif file only loops once instead of infinitely.
This is due to the fact that the .gif file generated by ROOT fixes the number of loop iterations (the Netscape 2.0 block) at a later point than expected by the standard. Thus, Libreoffice sets the number of loops to the default value (1).
@ferhue thanks for your input. I started looking at it yesterday and I ended up looking in that file too. Because of some other matters to deal with I did not continue. I will today. I will look at your suggestion.
The file produced by the example you gave cycles indefinilty in Chrome, Firefox, Safari, Keynote and PowerPoint… So it is working every where expect in LibreOffice Impress… Therefore I would guess the problem is in LibreOffice Impress.
The GIF89a standard does not specify looping of an animation. Instead this is implemented through an Application Extension Block. This was first added in Netscape Navigator 2.
The standard specifies that Data Blocks (an Application Extension Block is a Data Block) can appear in any order; Check the grammar at the bottom of specification.
There is a guide asserting that the Netscape block (NAB) must follow directly after the global colour table, but it also references Netscape Navigator 2.0beta4 which today is definitely outdated. This then probably deals with implementation details specific to that browser.
This seems to favour @couet’s statement that this is a problem in the LibreOffice Impress implementation
