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
I am hoping to release what I have done early in the new year.
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.
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.
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.
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.
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.
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.
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
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!
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.
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.
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.
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
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.
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
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
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.
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
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.
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
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.
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
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.
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.
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.
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
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.
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!
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 :-
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.
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.
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.
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
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.
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.
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
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.
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
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
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.
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
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!"
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
Version 2.03 released today. I have downloaded and tested it from the website and all appears to be OK so far.
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.
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.
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.
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.
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.
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
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
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
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.
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.
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.
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.
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.
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
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
avi file using
jpegs - as new routine
2.3% of the size!!!
This should make playback easy using hard drive streaming, even with slow drives.
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.
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
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.
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)
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.
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.
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.
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.