The Helium Frog Animator Work Log

27/12/2015 The birth of version Helium Frog 3.0
Helium Frog hasn't been updated for a while and there are some issues with running Version 2.06 on windows 10. I think it is now about time for a rewrite. After many failed attempts to convert it to C# I have in the past month had another go. I can report that it is going quite well and this is probably due to the fact that I have been doing a lot of game programming (see other webpages) . I have decided simplify much of the program. I am not going to add in rotoscoping, chroma keying etc. (Or not at least at first) but just get a simple frame capturing and video building program working.
  So far I have webcam streaming, onionskinning, frame grabbing. I have also implemented a new skin for the program. It is more fixed without the moving control pad of Helium Frog 2.06, but the keys in the bottom right of the screen mimic the number pad of a standard keyboard and give all the functionality for general frame grabbing and playback. One further addition is that I will not do video compilation when you capture the frame. This evening I mamaged to get a memory frame store which places compressed jpeg images directly in memory. I am hoping that retrieving frames from memory will be fast enough to do upto 30 frames per second without problems. this way the user can have immediate playback of the animation without any disk access problems.
  I intend to store the raw frames to disk and then the user will be able to compile video from a separate drop down menu in various formats. ther are a few open source video compression classes available for c# so I should be able to use one of those to give multiple video output formats.
  I am hoping to release what I have done early in the new year.

After a long break from Helium Frog I have been having a look at C# code again and begun some work on a new interface based on standard windows controls. I'm hoping that by keeping it simple and clean I can avoid complex programming and get further than I have before. An additional benefit will be that as the code will be open source, the use of a familiar interface will encourage other programmers to join the development. I have also decided to go back to a separate Live and Playback window as computer screens are getting high resolution so the available work area for most people is much larger than it was a few years ago. I have also had some feedback from users and the editor is almost never used.  So for the first build I will probably strip the program out to its bear essentials.

I have been working on two major routines for Helium Frog and they are now complete. The first is the module to set up camera streaming and capture an image from the device. I tried several methods some of which proved very unreliable, but this is now sorted. The second module is one that compiles a motion jpeg file from separate jpeg images. The code module also retrieves a single image from the file when asked. These are the main routines for a video capture program so I am pleased that they are now complete. Next work is to get a module to play video and audio. There are many examples online, so I hope to have this completed quickly. I am really liking this modular way of working as you develop little stand alone programs to run the modules whilst developing them. In the future this will enable me to improve the modules more easily.

Helium Frog 3.00 C# is making good progress. I'm really getting to grip with C# now and like it more and more each day. I managed to get the direct X frame grabber working. I now have a basic animation package that is capable of capturing frames and outputing them to disk. I also worked on a front splash screen for the software and began work on the settings form. The new version will enable the user to enter the program and select the source device whilst the program is running, not just closing immediately. I know this confuses some people who think the software has crashed. I think I have decided to have a top menu (like most windows software). It will be more familiar to users than the current interface. There are so many features now that the "button box" approach that I have hasn't got the room.

Christmas break has given me a little more time to work on the Helium Frog translation to C#. Progress was initially slow trying to work with class structures and such. C# is a very restrictive language, but makes sure you produce better more robust code by forcing you to work in a modular (Object Orientated!) manner. I have completed the button interface and got the program responding well to the user. Its very handy having a completed program in Visual Basic as when coding things for a second time you can see much better ways of doing things. If I can crack the video frame capture soon in C# I am confident that I can complete the task.

I have been making progress learning C# and hopefully will start the long process of recoding Helium Frog soon. I am finding C# quite easy to pick up as its much better than C++. I think this is because its more like Visual Basic. I may even produce a hybrid version of Helium Frog which uses VB for the main routines, but links to libraries written it C#. This way I can start improving the program immediately whilst swapping the code across.
    I have also been learning to use The Gimp paint package. I want to swap from Paint shop pro as this software is free and I can use it both on Windows and Linux. I'm hoping that I can do a nicer skin for Helium Frog.
    I have had a few emails from people who were not aware of the full documentation on the site, so I have compressed up the web documents and put them on the download page, to make them more prominent when users are downloading the software.

I have been looking into converting Helium Frog to C programming language for a while now, but have finally decided on which flavour of C is best to use. It seems that C# fits the bill nicely as it will allow easier development and is a modern and well supported language. I have also found directx coding examples and examples for Canon camera control. This means I can integrate the untidy camera setup (pin properties) into the main program and also finally get Canon live view support into the sofware. I would also like to provide a Linux version and this may also be possible using the Mono project. First step is to teach myself C#.

Work on Helium Frog has stopped for a while, but I am still promoting the software and answering questions online. Promotion has even extended to sponsoring a Live For Speed racing team!

Development work has now ceased on Helium Frog. I am happy it has all the functions I want to include in the software. There may be occasional updates and bugfixes, but I dont expect there will be many new features added, at least not for a while.
    I am hoping to expand the Helium Frog site to include some other related animation projects. I am currently experimenting with modifying a webcam to improve image quality, so i will post details of this soon. Other projects include armature design and stop motion puppet comstruction, so there may be a few posts about that.

I issued Beta3 version today and hope I get some feedback (See bottom of download page). It has all the features I want to include in the next full release. After trying several chroma key methods, I improved the speed  little, but it is still a little slow for my liking. I'll continue to search around for a better method.
    I also added a safe area feature. This is a rectangle on the live window which gives the animator a safe working area, so he can animate towards the centre of the screen. It will be useful if users film in 3:4 ratio and crop to widescreen.

The chroma key routine is now integrated into the program. I just need to sort out the routine to apply chroma keying to  to a captured frame as I have only completed the live view modules at the moment. I tested it this evening and even at 1600x1200 resolution it runs on my PC at 7 frames per second. This should be OK, but it is close to the limit so I'll test it on some slower PCs before release. I still have a few more ideas using lookup tables in the algorithm so maybe the frame rate can be improved still further. I have played around with different algorithms for chroma keying and thought of a few tweaks of my own. The results are very promising as can be seen from the following image.

The algorithm now seems to accomodate background reflections without too much trouble. (See the Minifig sleeves and the black box on the far right, the green tint is still accepted as foreground). The foreground edges still look a little harsh, but nothing too serious.  
    A few users have commented that "Tool Tips" would be a good idea as the program interface is difficult to understand. These have been added. Now when the user hovers the mouse over a button, a brief description appears in the LCD screen on the buttons window. 

More work on the chroma key routine. The interface in the main program has been modified to take all the new buttons and the settings window has been updated and tested. I now need to incorporate the chroma key routines in the main program. This will probably be at least another weeks work. The chroma key algorithm has also seen some changes and now performs a little better.
I am beginning to get some good feedback from users regarding program errors, but thanks to this have managed to solve most of them. As luck would have it most are due to the same fault which has now been corrected in the beta version (See bottom of download page), so this all looks good for the issue of the next version. 

I have spent a lot of time developing a beta version to overcome random crashes and directx problems. I believe windows chooses the wrong filters on some systems causing playback issues. This required a complete rewrite of the playback module so that it explicitly calls the filters by name from the system filters. This took quite a bit of research and a few failures, but it is now sorted. Some of my beta testers report that this has solved the problem. (Thank you for your help).
Work also continues on the chroma key routine and it now works at around 20 frames per second. This should be easily enough as cameras at high resolution rarely exceeds 5 frames per second. There are a few more tricks that can be employed to up this speed a little, so hopefully it will now be in the next build.

The image above shows that I still have a few problems, mainly with whites and blacks (See the face of the figure in the centre and also the audio speaker to the left of the figure in red.) The reason for this is that the greenscreen is actually the wrong colour, it should be an apple green RGB(0,255,0) for best results. Another problem is that the back lighting should be uniform. I think Ill get some swatch colours from my local B&Q store and try to find a good pure green for further tests. Once the routine is stable, it will be easy to offer bluescreen or redscreen.

The Canon A85 camera arrived today. The picture quality is very good, but it came with no software. I managed to find copies though as I have other Canon cameras. Its proving difficult to work out how to connect the camera to get the best results.
Work has continued on Helium Frog. Looking on the net I found an interesting paper about chroma keying and it contained some equations for doing calculations more quickly. Tonight I set up a little program and the results were quite impressive. If I can get it to work rapidly enough it will be a feature on the next version. I have also done homework checking out  features on some other capture software. The main thing I seem to be lacking is Chroma Keying. I have also had a few requests for it, so adding this to Helium Frog should prove popular.

Work ongoing on version 2.06. I have added an ascii keyfinder on the settings window, which shows the user the ascii code of any key pressed. This should make hotkey setup easier. The editor has recieved a new button called "Import". This enables the user to join existing .avi files onto the current animation. This was quite easy to do, but the editor also has to rename any individual frame output correctly also. This is a little tricky but I think I have now got this sorted.
    A few users are having problems with playback and I suspect this is the DirectX library routines being incorrect for certain machines. I am spending much time trying to sort these out. It is important to me as reliability of the software is the big drive at the moment. Work is slowing now as I have most of the features I want to include in the software. Its important now for me to use the software for some animation to see what is missing. With that in mind I found a Canon A85 camera on ebay for 30 so I an eager to give it a try.  Hopefully the depth of field will be better than my Logitech QC9000.

Issued version 2.05 today.  I have had a few reports of random crashes on certain machines, but decided to issue anyway as I don't think its related to any new code.  It seems to be related to reloading the motion jpeg files back into the avi player, but is only specific to only a few machines. I shall continue to try to find a solution.

All features are now completed so I am just fine tuning for a release of version 2.05.  There is such a lot of new code in this one, so I will spend a few nights running the program and watching for anything obvious.

Good progress had been made in a few areas. The automatic error reporting is now incorporated into the capture routine, loading and a few other areas. The mouthshapes as shown below now move as the editor plays and also in the main window. I have completed the Papagayo .pgo translator and that works well. The translator just needs to be incorporated into the main program. The interface has also recieved a few tweaks. The settings, editor and utilities forms are now wider to give more room for buttons. This is all the modifications planned for version 2.05, so hopefully a few more days work and then debug and issue.

Sound has been integrated into the editor. There is a disturbing "reverb" effect at slow playback, but it all works. I have also begun the long task of adding error checking in the main routines. I'm looking at including an automatic emailing routine so users can easily report errors to me with one button click. This should help me isolate any errors more easily when users start reporing faults.

I have spent the last few days finishing off the exposure sheet. I have been given the kind permission to use phoneme mouth shapes drawn by Gary C. Martin in my program and they match the exposure sheet style really well. It's so nice when people release high quality work like this as it saves many people hours of time.

Other work includes writing an audio player for the soundtrack and putting this in the main program. The program now has sound playing alongside the animation in the playback window, and is also offset if required the same amount as the exposure sheet. This works very well and I am syncronising the audio track each program cycle so there is no drift. One disadvantage is that on slow machines where you cannot achieve full playback speed, the sound may be choppy as it is syncronised each program cycle. This will be more apparent in the editor, particularly when not in rapid play mode. One possibility is to slow the audio down. This is the focus of the next few days to integrate sound into the editor.

Work continuing on exposure sheet. It now has a mouth shape that follows the phoneme sheet . It uses the standard Preston Blair Phoneme set. I also added an option so the user can offset the exposure sheet relative to the frames bieng worked on. This means that one long exposure sheet covering the whole film can be used for animating each scene.  I will also use this for offsetting the sound file by the same amount. Sound is the next big task and then it will be time for another issue.

I've abandoned the work integrating the editor in the main window. It just didn't seem logical once I got it working, so instead I'll keep the editor separate. Instead I'm going to add a second exposure sheet which can be toggled on and off on the main form. This gives the user the option of looking at the exposure sheet at any time, not just with the editor open. I checked the program on a 1024 x 768 screen and there looks like there is room to widen the editor window a little. This may enable a slightly larger preview window. I'm taking a break next week, so development will be halted for a while....a chance to have a good think about the layout without actually doing any work!

More work on X sheet and interface completed. I'm trying to keep the main button window compact, but adding a few more buttons. Here is a rough image of what I have come up with :-

I have placed the undo button near the capture button as this seems logical and added two more toggle buttons next to the onion skinning toggle button. These are for switching the X sheet visibility on/off and toggling sound on/off. I have also completed the skin for the pop out editor buttons and got them working again.
    A book arrived today, VB.net in 24 hours. I have the VB6 book of this series and I often use it as a quick reference. It only cost 5 from amazon (second hand) and it looks a good buy. I also found a free ebook on upgrading from VB6 to Vb.net so downloaded this also. Most of the commands are similar, but I use a lot of API calls in my program which aren't really used in .net so this may mean translating is a little more work. Still it will be good practice.  I think I'll issue one more version in VB6 before converting to .net.

I have been working again on integrating the editor with the main buttons and have come up with a good design I think. I am aware that animators want to see the X sheet whilst animating, not just whilst editing. With this in mind I'm trying to get the X sheet to display on the right of the form, and the editorwhen activated just pops up a button box with the extra command buttons that are required.
    I downloaded a copy of Papagayo Lip Sync software and  was impressed how easy it is to use. I did some investigation in how to translate Papagayo project files straight to the Helium Frog X sheet. It seems relatively straightforward, so this is on the list of extra features that will be included. After that, the next step is to add audio capabilities.

I have been investigating a rethink on the editor window. I modified the code to use the main window to show the editor image and made use of the button window slider and keys. It looks much neater and enables a much bigger preview when editing. The editor form is also much smaller and now contains only the X sheet and a few buttons. Other work includes the possibility of swapping the code to Visual Basic.Net. This would mean that Helium Frog could be run on Linux or Mac with a few modifications. Its quite a bit of work, so this may be another one that may take a few months. Visual Basic 6 seems to be getting less support on the net now, so finding sample routines is much easier with VC.net.

I released version 2.04 and immediately was notified of an error in the editor (Thanks to Dusty at VN Animation) so I managed to correct it within 15 minutes with one line of code and re issue. Besides that all seems to be going well. The new version seems quite popular and the number of downloads has increased.  I'm still getting a few reports as to random crashes, but the main cause of this is people using DV cameras that shut off automatically, webcams seem to work quite well. Some capture cards even crash windows. I'm trying to get a method to capture the error, but it is proving very difficult. I have also done a little work on the main source setup routine, so the program doesn't put up a warning and close if there are no source devices, but prompts the user to connect one.  I probably wont add any more features in the next issue, but have another tidy of the code and sort a few reliability issues as this seems to be the main reservation users have with Helium Frog.

I completed the slider control. I had a flickering problem on the form, but this was caused by me refreshing the whole form, not just the slider. I had to do a lot of reprograming to eliminate this, but it is done now. I also managed to get the editor and the undo key to examine all the individual frames (this is an option in the settings window to output individual frames),bmp, jpg, gif etc. and check, delete and rename them when the editor has shuffled the main avi about. This was quite a task, but its finally finished. Just one more thing to do which is the movement of the main button window slider when the avi is playing and then its all complete for this version. I want to give it a good few days testing and then issue it. I'm a bit busy at the weekend, but I hope I have time to release it. I think the editor is the last major piece of the jigsaw that users want.

I now have the final layout for the editor and have nearly all the details completed. I added slow and rapid play options and also explanded the X sheet to include a Phoneme sheet for lip syncing.  There is a lot of detail in the editor and a lot of inter dependancy of code, so its has been a little tricky.  I'll just get the last little bits done, such as the slider control and then give it a good test for a few days. I hope to have the new version ready soon.

More progress on the editor. I have now incorporated it into the main program and done more work on the skin. It's still a little rough, but it all works and builds the edited animation into the main program very well and quite quickly. I'm also experimenting with having the button text separate from the skin. In the example below the quit button text is part of the skin image, but the paste and delete buttons are not, but printed in real time over the top as the program runs. The advantage of doing it this way is. a) I can use jpegs for the skin instead of bitmaps, which reduces the download size, b) The program could be adapted more easily to other languages  c)  Could change colour or font when pressed and d) Enable much smaller buttons to be used should the need arise without the font becoming unreadable (a problem with lossy jpeg images). I'll try to find a nice font and also tone the colour down from pure black to make it less obvious they are pasted over the skin.

I have made good progress on the editor and now have all the routines written and have improved the preview button so it builds an avi at around 100 frames per second (uncompiled). This weeks work is to integrate it into the main program. I have also made the settings window capable of loading old animations from the hard disk. This will also make testing the editor much easier as I can load in long animations  to check the editor rather than capturing new frames each time.

I have been working on the editor and have got it working, but the playback is very slow. I know other programs store frames in memory to improve playback, but I was trying to avoid this as the program is then dependant on how much memory the computer has. I'll continue to work on it to see if there is another way to do things, but I am not hopeful that there is a solution as disk access is relatively slow compared to memory.

I finally integrated the undo last frame function into the main program and ironed out all the problems. It seems to work quite well, stepping back the onion skinning is now all sorted as well. At the requset of someone on the forums I have added a visual indication of position on the slider controls. These took a while to get correct, but it was quite interesting as I haven't done anything like this before.  I'm really pleased with how they look.

The difficulty was getting them to follow the position of the playback and looping function, but I managed to sort this in the end. You can see in the above image that I have finally found a use the button at the bottom left. This is now the home of the "Undo last frame" which enables the user to take back a captured frame. In fact you can undo all the frames you have captured right back to the first should you wish.  I have also made a lot of progress on the editor. I have decided to go for an X sheet type rather than thumbnails as it is impossible to fit enough thumbnails on a form to make it  easy to see where you are in the animation. This means a slight rethink of the inerface I designed a few days ago, but that is hardship as it is on CAD.

I did some more tidying up of the website and also switched over from the editor development onto the "undo last frame button". I managed to program it quite quickly as it is similar to other things I have done, elsewhere in the program.  I performed some tests, getting it to repeat deleting the last frame from a long animation and then checked the.avi file. There were a few bugs, but I have sorted these now. It's just a case of integrating it into the main program. This requires a bit of thought as I also have to make sure the onionskinning steps back in sync with the undo function. Whilst doing this, it gave me an idea of making the rotoscope feature play in time when you are in  playback mode. This would mean you could have sound playing in time. This might be useful if the user wants to use audio when timing his animation. I'll add it to the list of "possible features!"

There appears to be no major issues with version 2.03, which is good news. I have now begun the editor skin design and have made good progress. I'm still not sure how to exactly do an editor.  An X sheet style setup, or a thumbnail viewer type. I like the thumbnail type viewer better, so I will try to do something like that. It depends on how quickly I can get the thumbnail viewer to respond as the user edits, but it should be no problem. These things tend to evolve as you go along. I did a rough sketch then transfered the design to Catia V5 software, which I use at work, so its the software I'm most familiar with. It allows for easy changes should I require them. I will then take a bitmap image to use for the skin.

Editor Design - Rough Sketch

Editor Design - Catia V5

 I also spent a lot of time on the website, organising things on the server and separating out the documentation. Users tend not to read the manual, so I separated some of the stuff into a quickstart guide, I'm thinking that will help encourage people to visit. I am putting off working on the undo last frame feature, as I have done a lot of similar routines recently (.avi file manipulation) so its a bit boring to do. I might have a little go next week.  After weeks of trying to get the Canon Software Development Kit (SDK) I finally managed to get a copy out of Canon UK.  I would really like to add Live View support (ie. Streaming images directly from a Canon DSLR)  but the SDK is really C++ oriented. I had a look on the net for some Visual Basic examples, but I couldn't find any.  Maybe this is a project for a few months time when I have had a good read of the manuals.

Version 2.03 released today.  I have downloaded and tested it from the website and all appears to be OK so far.

I spent all day tidying the code, and adding options to the settings window. I ran a long test on the program up to 1000 frames and all was OK. I have added a frame counter in the playback title bar and also added the option of stamping the output frames with the frame number should this be required. I went through the start up routines and cleaned them up so that windows no longer build in front of the user. This makes the program look a lot better.

More progress on the time lapse facility. I got it working well, but when testing I found a huge memory leak with the program. No user has complained of crashes though so im not sure if this is only apparent in uncompiled versions of the code. I put in a memory monitor in the diagnostic routine I have built into the program. I spent two days tracing the errors and I have now cured the problem. I ran a test today up to 700 frames and memory usage was stable. I am feeling more confident now that the program wont cause any major crashes if the user animates long scenes. 

Snow today meant I couldn't get to work, so Helium Frog got a well needed boost in programming time. The utilities window is coming on and now I have only to do the frame extract facility. I also spent a lot of time tidying up the program and moving routines to more logical places and removed many public variables. I added further error checking by using functions rather than subroutines. I have also revised the startup routine, so the program goes straight to the main program and you can set the video source in the live window. It looks much better now.

Continued work in Visual Basic on main program. I am now adding a utilities form which will enable the user to change frames per second of animations, build avi files from individual frames, and explode avi files to single frames.  This is the first step in allowing the user to edit frames in an animation file. 

I am busy learning Visual C++ 6. I think I have come as far as I can with Visual Basic. VB is unable to control directshow video capture so I am using C routines developed by another programmer. These are a bit of a compromise and dont do exactly what I want. It will take a few months for me to begin to do anything useful in C++. I have found a way to create .dll libraries in C++ which I can link into the main program. I will try to replace some of the main routines with these. This should speed up things a little and give me good practice with my new skills.

I recieved the macro lenses today, but being a bit of a "Numb Nut" I ordered the wrong size (I need 58mm not 52mm). Holding them to the front of the lens they seemed to work well, so I ordered the proper size.

I conducted the first full trial of the software by animating  a lego (very) short movie "Fresh Fruit Mugging". The software worked well, but I have noticed that if you press the capture button rapidly, the playback window goes blank. Ill have to investigate this in the new year. I put the film up on a new webpage 

Other work includes trials with my Canon DSLR. I have ordered some macro adaptor lenses for the camera so I can get closer to the puppets. I'll do a trial using the macro functions then. The Canon"Live view" function doesnt seem to work too well and seems to mess up with the Helium Frog macros. I phoned Canon and they don't do a DirectShow driver, so you can only stream video from this camera to their own software! I applied again for the software development kit, so I may write my own driver if I can. This programming may be a little beyond me though. I also thought of using a webcam through the viewfinder as a video assist. I stripped down an old webcam I had and did a few trials with various lenses. I've ordered a new set off ebay (I think I need a 16mm focal length with 19 degree field of view), so I should be able to get the focus and view angle just right with them. I like this solution as I would mean that what I learn will not be "Canon specific" but useful to any digital SLR.

I could also do with a utility to join separate bitmaps or jpegs into an avi file. Helium Frog already has these subroutines in it, so I just need to write the user interface.

Released version 2.02 today.  Tidied up the macro routines and updated the user guide. Probably no more updates till after Christmas unless there are any major bugs.

I completed the work on the hotkeys, so I think that is now solved. I spent all day today writing some code to enable the user to write macros to control cameras remotely. I got it all working today. I can now trigger my canon camera via the usb lead through the canon software.  It should be possible to develop simple macros to control nikon, olympus etc. Another release will be in the next few days.

I issued version 2.01 today which fixed several bugs in the code. I also traced why the hotkeys are slow to react to user input and produced some code to solve this. I just need to expand this for all hotkeys.

I released version 2.00 today. Its getting very difficult to debug the program now as the program is becoming quite large, it is also very boring. I had some good feedback from Leevi Lehtinen at www.stopmotionanimation.com as to the location of some errors. I've fixed three of them in the code and will get onto the others soon. My plan is to release a bug fix at the weekend. I was less confident on this release as I changed a lot of code. As Im not a formally trained programmer I dont often work object orientated (with separate modules etc.). I'm learning a lot with this program as it is by far the most complex I have ever done. Its only now that its finally sinking in why proper coders do it that way.

I have just completed the loopback function, the playback now loops to show the live window for 1 second before looping again. It works well. I just need to tidy the code a little and run a few trials, I hope to be able to release the new version by next weekend. I'm very pleased as I think this program now has all the basics complete to be a good solid stop motion animator, I hope others will agree.  I might leave the development after this for a few months to hopefully let the number of users build up a bit.

I have integrated the new routines into the main Helium Frog  program and they seem to work well. Today I have put some more options into the settings window, so the user can specify the jpeg compression for the motion jpeg file and also retained the option to output a bitmap based avi if the user requires. I need to add a hotkey for the rotoscope window and also add a playback to live routine, so when looping the last few frames it shows the live window for a short time. I think that will be enough for this release.  I have also located a nice frog which I may use for another webpage showing any lego animations that I make. I found my first test animation that I completed with the new software, so I thought I should share it. Its a bit rough, but the original was very clear, I shall have to experiment with the best settings for you tube and also develop my technique.  Click here to view animation

Finally a breakthrough. I managed to eliminate the last problem with the motion jpeg routine. I tested it with some jpeg stills from Helium Frog version 1 and it produced a motion jpeg no problem. I performed other tests at unusual resolutions and all went OK. I just need to tidy the code, add more error checking and do more testing. I have also been astounded at how small the files are. I grabbed some 960 x 720 jpeg frames at 60% quality and made a motion jpeg using the new routines. The file size on a 6 frame avi was as follows:-
avi file using bitmaps - as current Helium Frog        12153 KB        
avi file using jpegs     - as new routine                           280 KB        2.3% of the size!!!
This should make playback easy using hard drive streaming, even with slow drives. 

I have made good progress today on the motion jpeg routine. I have now got it working for 640x480 images. I had to write some code to help me debug it. I wrote/revised a file comparison routine and also developed a routine to extract jpeg frames from some motion jpeg files. The jpeg extraction routine will be useful in the helium frog software utilities, so the code wont be wasted. The routine is getting more robust each day and I hope to have this finally cracked by the weekend.  

Still working on motion jpeg files, progress is slow, but I am now trying to scale up work to 1600x1200 images.  Getting help from my band of loyal followers who are a great help posing for the cameras and stacking lego! I think were on frame six now guys how about another brick!

Finally making progress on Motion Jpeg .  I have now a subroutine that adds a jpeg to an existing avi file.  It needs more work to make it robust, but the main functions work ok for small sized avi files. I will test the routine on larger images and debug it.  I want to make this very robust with good error checking as this is really the new core to the version 2.0 program. I located a better freeware hex editor (FShed) which enables me to better view the inner workings of a motion jpeg file.  I also wrote a routine to cross check two files looking for differences in the hex values. This was the key to tracing my coding errors.

Continued work on video compression to Motion Jpeg format. I have been working on this on and off for 2 weeks now and do not yet have a clean routine to add jpeg files to an avi file.

Obtained some lighting from IKEA which should help my animation setup (GRUNDTAL 12v lighting set)

Added single frame output options , PNG, tif, gif, and jpeg. Jpeg routine works better than last version and also paves the way to switch from avi bitmaps to jpeg bitmaps for faster playback.

Completed a few test animations with some lego minifigs I have aquired.  Animations were very clear, but playback within the program is painfully slow. I must change this in the next issue. Recompressing using mediacoder produces good quality animations. The quality is as good as any I have seen on the net, which is good news.

Completed switch from two screen mode to exclusiely one screen mode. There was a scaling issue between live and playback windows. I spent many hours tracing the fault. I found it was due to the picturebox frame setting. The two windows now overlay nicely.

Switched playback from MCI to DirectShow playback. Much better now and will enable more acurate pausing / looping etc.

Modified buttons so if the user presses play when playback is at the end of the animation, the program plays from the start. Also added looping to run contiuously. I want to add playback to live looping also.

Noticed there is no hotkey for rotoscoping, so will check out all hotkeys when I have time.