 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2007GIF encoding
Hi, I'm using the AnimatedGifEncoder.java (reference http://www.fmsware.com/stuff/gif.html). I have 15 gif frames, when I use the encoder my file size comes to 82kb, if I use an animated gif application it only comes to 40kb. Any ideas why the file size is so much larger? How can I reduce the file size? ... >I'm using the AnimatedGifEncoder.java (reference http://www.fmsware.com/stuff/gif.html). I am familiar with it. In fact, I wrote a GUI front-end for Kevin's library. You can find my GUI'd version here. <http://www.physci.org/giffer/> >I have 15 gif frames, when I use the encoder my file size comes to >82kb, if I use an animated gif application it only comes to 40kb. Any >ideas why the file size is so much larger? How can I reduce the file >size? It probably comes down to the Color Quantisation Quality (upper right of the mainGUI). Note particularly the tooltip. Play with that factor, and you'll probably see a size reduction for some of the values. Try a variety of qualities, the size of the resulting GIF can vary quite dramatically, and in a not entirely 'intuitively obvious' way. HTH  SignatureAndrew Thompson http://www.athompson.info/andrew/ > kitkat_rob...@hotmail.com wrote: > [quoted text clipped - 24 lines] > > Message posted via JavaKB.comhttp://www.javakb.com/Uwe/Forums.aspx/java-general/200709/1 Hi, Thanks for your reply. Do you know of any alternative Quantisation implementations on this source code? My understanding of Quantisation code isn't very strong. Or do you know of any links to gain a better understanding of Quantisation? ... >...Do you know of any alternative Quantisation >implementations on this source code? My understanding of Quantisation >code isn't very strong. Or do you know of any links to gain a better >understanding of Quantisation? The short answer is 'no'. I treated the FM library as though it were a 'black box' and never even looked into the code itself to any degree, guessing that the author knew more about it than I ever would. As an aside though. What format are your source images?* The quantisation is meant to reduce the source imageS colors to a single palette of 256. If the images are all the *same* 256 colors to begin with, its work is done. This might be easier (or at least, more control over final size) if you were to reduce the colors in the original images to the same 256 color palette prior to running them through the encoder. * GIF images are automatically 256 colors, but no two will necessarily have the *same* 256 colors, OTOH, grayscale images (for example) should be. SignatureAndrew Thompson http://www.athompson.info/andrew/ > .. > [quoted text clipped - 26 lines] > > Message posted viahttp://www.javakb.com The source files are from a single animated gif, which in turn is split into several frames. I would guess each time it splits it saves the palette information and thus when encoded back it duplicates these values? The single animated gif is split into several frames using this Quantisation (http://msdn2.microsoft.com/en-us/library/aa479306.aspx) (I'm using .net but principle is the same), if you add the file sizes up of each of the 15 frames, it amounts to about 70k + 10k for the delay information. Somehow I need to reduce the palettes in each indiviual image and use one global one, would that work? if so how is best to go about it? > > .. > [quoted text clipped - 40 lines] > Somehow I need to reduce the palettes in each indiviual image and use > one global one, would that work? if so how is best to go about it? The difference could also be compression... I know that at least in the past, the technology to create compressed GIFs wasn't free to license. I don't know the details of what you're using, but it could be that one uses compression and the other doesn't. Hope this helps. ... > The difference could also be compression... > >I know that at least in the past, the technology to create compressed >GIFs wasn't free to license. I don't know the details of what you're >using, but it could be that one uses compression and the other >doesn't. Hope this helps. Huhh.. I had not realised GIF's could have 'compression'. The OP's last message seems to strongly suggest as much though, since I cannot explain why the GIF made from the frames of an existing *animated* *GIF* (which should already have a simple 256 color palette) could end up bigger when remade into an animated GIF. SignatureAndrew Thompson http://www.athompson.info/andrew/ > I had not realised GIF's could have 'compression'. This is a sore point Unisys got hold of the patent to LZW compression used in GIF and they started threatening people with it. It is expired now, though you never know what a lawyer could do. I think though your code does do LZW, thumbing its nose at Unisys. This is one reason why the move is to PNG which is an open format. The other reason is it has variable transparency. See http://mindprod.com/jgloss/png.html I have removed nearly all the GIF files off my website. I converted them to PNG. A few avatars still have to be in GIF since they are used by dinosaur sites. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> I had not realised GIF's could have 'compression'. > [quoted text clipped - 3 lines] > >I think though your code does do LZW, ... (slaps forehead) RiiIIGht. It sure does (via the library) make use of (expired) 'proprietary' technologies. > .. thumbing its nose at Unisys. Indeed. ;-) I put a 'use at own risk' caveat in the license, and forgot entirely about it. Does LZW have different 'levels' of compression? I thought I had the size difference sussed, but your comment makes me realise it may not be as simple as I first stated. SignatureAndrew Thompson http://www.athompson.info/andrew/ >> I had not realised GIF's could have 'compression'. > [quoted text clipped - 3 lines] > > I think though your code does do LZW, thumbing its nose at Unisys. The US LZW patent expired on June 20, 2003. The counterpart patents in the United Kingdom, France, Germany and Italy expired on June 18, 2004, the Japanese counterpart patents expired on June 20, 2004 and the counterpart Canadian patent expired on July 7, 2004. Consequently, while Unisys has further patents and patent applications relating to improvements to the LZW technique, the GIF format may now be used freely. I believe Sun added in to Java 6 full GIF compatibility in ImageIO because the patents had long since expired by then. LZW compression as implemented in GIF is now fully free! SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth > >> I had not realised GIF's could have 'compression'. > [quoted text clipped - 19 lines] > Beware of bugs in the above code; I have only proved it correct, not > tried it. -- Donald E. Knuth Thanks for your replies. Having looked further into it, I can see the file size of the "remade" animated gif gets larger when adding the frame information (encoded by the LZW compression). I think its creating a palette based on the first frame and thus when adding the additional frames its not able to compress well as its only taking the first frame into account and leads to addtional file size, whereas the application ive been comparing agaisnt (Easy Gif animated) is able to compress well using all the information from each frame. To recap: I have an animated gif (40k). I can split it into 15 frames, each of which are 256 colours and of good quality. I run these images through ngif (a c#.net port from Java, can be found on code project) and my new animated gif is 80k. However, if I run this using an animated gif application (Easy Gif Animated) it produces an animated gif of 40k, much like the original. One thing I have noticed is if I process the original and the Easy gif animated version both have less colours in each of their frames. For e.g. The first frame has a yellow border, which should be in each of the frames but it is not if you look at each of the frames (but still displays correctly when animated in IE/firefox). The yellow border is however in each of the frames of the ngif produced version, which would account for the extra file sizes. I also believe the original and the easy gif animated version are not storing local colour palettes, whereas the ngif is. Therefore I believe its in the encoding that is the issue, basically.. how can I improve this? People must have come across this issue before. On Wed, 26 Sep 2007 10:47:19 -0000, kitkatrobins <kitkat_robins@hotmail.com> wrote, quoted or indirectly quoted someone who said : >Therefore I believe its in the encoding that is the issue, basically.. >how can I improve this? People must have come across this issue before. What you might do is compose a dummy first frame, which has all colours in it that you plan to use, then strip all the other frames to use only that set. After the animated gif is created, peel off the first frame. Alternatively send your animated gif to a batch paint program via EXEC for tweaking. I suspect you can do this with the animation part of PSP see http://mindprod.com/jgloss/psp.html SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Wed, 26 Sep 2007 10:47:19 -0000, kitkatrobins <kitkat_robins@hotmail.com> wrote, quoted or indirectly quoted someone who said : >Therefore I believe its in the encoding that is the issue, basically.. >how can I improve this? People must have come across this issue before. I am not sure of this, but I suspect GIFs make come in two flavours, ones with a palette map and ones without. I would suspect an animated gif must have a common palette map for all frames. If they don't, you get some sort of inefficient kludging. So it seems logical you need to massage the frames to give them a common palette map before feeding them to the animation gluer. It would be extra overhead to have a different palette map for each frame. Given the age of GIFs, that overhead probably was totally unacceptable originally when the formats were nailed down. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com ... >I am not sure of this, but I suspect GIFs make come in two flavours, >ones with a palette map and ones without. I would suspect an animated >gif must have a common palette map for all frames. Not that my record so far on this thread is *anything* to provide confidence, but I actually thought the entire purpose of the 'quantisation' mentioned earlier was to assemble that common palette. BTW - Joshua, thanks for the detailed run-down on the patent situation. More info. on that side than I have ever seen. I recall sending an email to an address listed by Unisys that was supposedly for information on the GIF/LZW patent, which was (somewhat unamazingly) entirely ignored by Unisys. Oh, and while I remember. Has anybody played with the Java 6 GIF writing abilities for animated GIF's? Java 6 was still some time off when I wrote 'The Giffer', and I decided not to wait for it, since the FM software library could do it 'right now'. SignatureAndrew Thompson http://www.athompson.info/andrew/ On Tue, 25 Sep 2007 11:49:07 -0000, kitkatrobins <kitkat_robins@hotmail.com> wrote, quoted or indirectly quoted someone who said : >My understanding of Quantisation >code isn't very strong. go to the Corel site and download a trial copy of Paint Shop Pro. It has a number of algorithms for reducing the number of colours. You can experiment with images to see what happens. Ctrl-Z is undo, so you can experiment more easily. see http://mindprod.com/jgloss/psp.html SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >How can I reduce the file >size? I would suggest opening the generated animated gif in your paint program and saving it again. You may discover your paint program has some sort of quality vs space tweaking parameters. It may simply be collapsing the palette to the actual number of characters used. Try taking the image apart again and look at the properties of the generated frames in each version. I don't think animated gifs have any sort of frame-to-frame compression scheme, just within each frame. It could be your paint program just implements the GIF LZW compression more efficiently. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.