Dear developers,
on Debian stable and ROOT v5.34-26, I am creating animated gifs with ROOT (infinite replay), and they play correctly in any viewer. However, when I embed them into a Libreoffice Impress 4 presentation, they do not replay (they just run one time).
As I learned in this post, if I open the gif with Gimp and export it again as gif (check “Loop forever”), then they replay correctly in Impress. forum.openoffice.org/en/forum/v … f=10&t=510
Is there any trick how ROOT could export in the same way as Gimp for being compatible with Impress and avoiding the tedious open-and-resave-with-Gimp?
I attach my macro and the gifs. test_gifs.zip (31.4 KB)
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.
