Large image sequences in Flash - How to reduce memory usage? - image

so I'm trying to publish a looping animation in Flash with a large amount of image sequences in it. (around 3000 frames all told). And I'm having problems with the swf using too much memory when it's played.
The swf is about 80mb, but the file uses an excess of 2gb of ram when played. I don't know why that would be. A memory leak?
My understanding is: that Flash will just load all images in a swf into memory unless you dump the memory somehow.Can anyone explain how to do this? Is it possible? I can't seem to find a solution online.
Thanks

SWF file keeps all images in a compressed format. They can be compressed very well but when playing, they must be decompressed so they take much bigger memory space.
How to optimize that depends on you. There is also a possibility that it cannot be optimized - for example, if SWF does automatic decompression of all images on load. You can test it by checking the free memory after swf is loaded but before the animation is accessed. If standard timeline animation takes too much memory, you can try to use your own custom animation. For example, in an ENTER_FRAME loop you can create only one instance of image for the current frame, and all past instances will be removed and garbage collected. Hard to say because a testing is needed.

Thanks for your responses. As I couldn't find an answer to this, I've resorted to using external video. Cheers for your time.

Related

LabVIEW - Store very large 3D array (array of images)

I am working on a LabVIEW project on which I have to process some video (with for example 5000 images of 640*480 pixels, so lot of data to process). Using a for loop I am processing one image at the time so in this side all is okay. But in the other side, I have to store the results to visualise the results of the wished image after the processing. Until now I always worked with array but here LabVIEW has not enough memory to do the job (which is quite normal).
Is there a best way to change my way to deal with the data, using other solution such as cluster, save the image on the local disk, etc?
For information, the processing is quite long (several minutes for only one image) and I don't have to save the result before the user ask for so I am anticipating the case where all the video is processed without saving the result.
Thank you in advance.
How much RAM do you have? Assuming 4 bytes per pixel, 5000 640 x 480 images would take about 6 GB, so if you have 16 GB RAM or more then you might be able to handle this data in RAM as long as you're using 64-bit LabVIEW and you're careful about how memory is allocated - read through VI Memory Usage from the help, for a start.
Alternatively you can look at storing the data on disk in a format where you can access an arbitrary chunk from the file. I haven't used it much myself but HDF5 seems to be the obvious choice - if you're on Windows you can install the LiveHDF5 library from the VI package manager.
Did you consider to store images as files in the system temporary directory and delete it afterwards? Since the processing takes long time per image, it should be easily possible to have a "image queue" of 5 images always loaded into memory (to avoid aby performance drop due to loading from file right before the processing) and rest would sit on the disk.

What is the most efficient way to transfer pictures over wifi from FlashAir in Java8?

I'm creating a program that reads pictures (JPG max size about 10Mb per file) from FlashAir as soon as they're taken, display them in a bigger screen for review and saved them to a local folder. It is paramount to reduce the time from the moment the picture is taken until it is displayed to the user and to prevent loss of quality (they are macro pictures). Now, the camera works with JPG, so changing that is not an option for the moment. All the pictures must be saved locally in the maximum possible quality.
I was wondering what would be the best way to achieve this. Since the FlashAir card is in the camera and moves around, the bottleneck will probably be in the wireless transfer (max speed is 54 Mb/s).
The picture could be displayed withing the Java app or sent to a different app for editing, but I want to reduce I/O operations (I don't want to have to re-read the picture once is saved locally to actually display it).
What is the best way to achieve this using pure Java 8 classes?
My test implementation uses ImageIO.read() and ImageIO.write() methods. The problems I have with this approach is that it takes a long time for the picture to be displayed (it is actually read from the saved folder) and the image is re-encoded and compressed, loosing quality compared to the original file that is in the SD Card.
I feel it should be a way to transfer the bytes very efficiently over the network first and run two parallel processes to save the untouched bytes to disk and decode and display the image (image then could potentially be edited and saved to disk to a different location).
I don't need a fully working example. My main concern is what Java 8 I/O classes are best suited for this job and to know if my approach is the best one to achieve the results.
Edit
After some research I was thinking of using ReadableByteChannel to storage the picture bytes in a ByteBuffer and then pass copies of it to two jobs that will run in parallel: the one saving the bytes would use a FileChannel and the one displaying the image would use them to create an ImageIcon.
I don't know if there is a better/recommended approach.

How does WinRT handle BitmapImage and Image memory

I am new to programming Windows Store Apps with C# and I am trying to understand how image memory is handled. My app is very simple:
1) it references a bitmap from a file using a Windows.UI.Xaml.Media.Imaging.BitmapImage object and then uses that as the Source for a Windows.UI.Xaml.Controls.Image object. In my case the image on disk has larger dimensions than what is being displayed on screen so it is being scaled by the system.
My question is how does WinRT handle the memory for the image? I used the vmmap tool and I see in the Mapped File section there is an entry for my image file. I guess this means that the raw bytes for this file are fully loaded into memory. Since this is a JPG these bytes must be decoded into pixel bytes. It seems from my tests that setting the UriSource of the BitmapImage doesn't actually cause any processing to take place since it takes 0 ms and that instead there is some lazy loading going on.
So the questions are: Which object is dominator of the the uncompressed unscaled pixel data? What object is the dominator for the scaled pixel data that gets drawn on screen? Are there tools that can easily show me this? In the Java world I use the Eclipse memory analyzer tool. I tried using PerfView but the results make no sense to me, it seems the tool was meant for analyzing performance.
UPDATE:
At the BUILD conference the team discussed the Windows Performance Toolkit. I never heard anyone mention PerfView so I believe that WPT is the latest and greatest tool for analyzing memory and performance, here is a link:
http://msdn.microsoft.com/en-us/performance/cc825801.aspx
A short answer is most likely "optimally". Not being a smartass, there are just a lot of different systems out there. One mentioned hardware acceleration, you can also consider number of cores, display memory, disk speed, monitor bit depth and resolution, the list goes on and on.

XAP file from XNA game is huge, how can I compile resources without images being so big?

I typically have been writing xna games for windows phone 7 and set all my content to a build action of compile, which is default; what I've noticed is that my XAP file is now huge after finishing a new project, it seems to have taken 15MB worth of images and blown them up to 200MB in size. Is there anyway to get the build to be smaller while keeping the images compiled? From what I read it compiles images as basically full bitmaps. What's another direction I can take to resolve this issue, as forcing users to download a 200MB app seems unfair when at most it should only take up 15-20MB.
The XNA Content Pipeline basically stores images as they will be used on the GPU. That is either as an uncompressed bitmap, or DXT compressed (which doesn't compress it by much).
So if your original files were in jpeg format (or, to a lesser extent, png), you will find that your original files are much smaller than the built XNB files.
So the answer is to distribute your original jpeg and png files, and load them with Texture2D.FromStream. Note that this uses more CPU power to convert them into the right format at runtime (although I've heard reports of faster loading in some cases, because there's less data being transferred). Also you'll have to do premultiplied alpha manually yourself (and anything else that the content pipeline is handling for you).
Another thing you might want to look into is turning on compression for your sound effects. By default they are uncompressed. See this answer for details.
For more info, this article looks helpful.

comparing 2 kernel images and flashing the diff FLASH memory

i have existing old version images like kernel image,filesys image,application images in my NAND flash.
i want to port the new modified kernel or application image on to the NAND flash by replacing the older one.
But in the new images 90% is common to the old images.
so i don't want the entire new image to transfer.
inspite i am thinking of some kind of comaprision between the old and new images and want to send only the difference on to flash memory. so that i can avoid transfering a larger data.
can it be possible ? i need some guidence to do this.
It's certainly possible, however with flash you'll have to take into account the difference between erase sector size and write sector size (typically the erase block is multiple write sectors in size).
This would be very difficult, for two reasons.
The Linux kernel is stored compressed, so a small change can cause all the compression output following that point to be different.
If a modification changes the size of some code, everything stored after that will have to shift forward or back.
In theory, you could create your own way of linking and/or compressing the kernel so that code stays in one place and compression happens in a block-aware way, but that would be a lot of work -- probably not worth it just to save a few minutes of erase/write time during kernel upgrades.

Resources