Sorry your browser is not supported!

Hey, everyone, a happy new year to all of you.

i've got a problem with the load image command.
my goal is to build a video editing software (yeah, i know) and i'm almost got something useable, but it is limited to loading about 200 images (1920x1080 resolution, jpg format).
i'm using ffmpeg to convert the video to seperate frames.
load image takes on my machine about 600ms to load 1 frame, but i would need to paste the image every 17ms to maintain about 59fps.

any ideas on how to get the images faster?

thank you.

That is simply too large to load from disk each frame at a good speed, you will need to preload the images, similar to buffering before you begin play back. You will be limited by the 2gb limit on 32 bit applications though.

Dbpro probably isn't best suited to this as you ideally want 64 bit for the size and number of images being used as well as the ability to load images on a separate a thread.

If you have 16gb or more of ram, you might try setting up a RAM disk, moving the images and application into it and running everything from there, this essentially already loads all the images into memory before you begin and should load in dbpro much faster.

Following on from what Ortu stated; I would like to point out that DBPRO does not load jpg files quickly. I have avoided the use of jpg files in DBPRO for the past 5 years for this reason. I would recommend .DDS or PNG files instead because they are loaded by DBPRO relatively quickly. You have to also make sure that your images are not being loaded with MipMap filtering enabled. I trust that you understand what I mean by that.

I also do not see DBPRO as the best choice for video editing software development, unless of course your level of skill and understanding is great enough for the challenge. You state you have something almost usable so I imagine alot of work has been put into your product and I hope all goes well and that you get it completed.

i looked into it, but it seems like i cannot create a ram disk from within my application without any additional work from the user. i want to keep it easy to use, in case i will make it public. but i will keep it in mind, as i didn't know that this was a possibility in the first place.
thank you for that


wow, i just made a test disabling mipmaps and got a loading time of about 100ms (opposed to the 600ms with mipmaps, still jpgs) i didn't knew there is this huge difference. i also tested to use smaller images for the editing and use the full size images for rendering.
i tested bmps and got like half the loading time of jpgs. using a smaller bmp (400x225px) gives a loading time of 3ms, without mipmaps. will test dds and png, because of file size and stuff.

with all that i got a reasonable speed, just need to test this on other pc's. thank you for that


that is true. period. but i like the fact that dbpro is so easy to use, i'm using it to make prototypes of my ideas.


i only got one question remaining for now. if i open and close so many files in a loop, do i have to worry about damaging the ssd/hdd?
thank you

Reading files won't put to much wear on the drive, if you write to all of them that will have a bigger impact.

Jpg is a compressed format that had to be uncompressed when loaded so it will take much longer to load than png or bmp. There is a trade off between loading speed vs file size

You are correct, a RAM disk has to be set up before hand outside of your application. It won't really work if you are wanting to distribute this application to users.

200 1080p images is about 1600mb in memory,
About 9mb each. Images are uncompressed in RAM I believe.

Does this video editor save videos into a video format?

1. All modern video editors reduce video quality in the editor during the editing process to be efficient.
I'll give you some advice that will make things easier. Scale the images down to 270p when loading them. Doing this will let you store 3200 images instead. When your program goes to master the final saved animation load each corresponding frame at full resolution one at a time,process it, and unload it when loading the next. This will keep your memory footprint low.

2. Going further, setup a scratch folder. For every set of frames or animation your editor loads to work on, scale down and save the frames to a scratch folder. This helps because if you have too many frames to fit in memory even when scaling them down, you will need to stop your animation from being longer or resort to loading/scaling frames on the fly. If they are already in the scratch folder scaled down you can load low res versions of each frame really fast.


These are basic optimization concepts you see in editors like Adobe Premiere Pro.
Work with a low res version, master at full res.

You'll have much better performance doing this.



Don't do this. Design the program better instead.
If his editor imports animations or sets of frames, saves them to a scratch folder at 270p, edits with the low res version and masters the final exported animation at full res then there's no need.
1080p image is about 300kb. So instead work with a 19kb 270p version the program prepares in advance from the import process. At 60fps that's about 1.1 MB/s.
A regular hard drive can do 10-20 times that speed. Though there is overhead, for hard drive seeking and DBPro processing.
Then you realize that even then the 270p images might not load in 16ms to maintain 60fps. No problem, skip frames. In fact cap the editor at 30fps.
Then when exporting the final finished animation, use full resolution, 60fps.

All the editor has to do is figure out where to snip the animations and where to stick them together. You don't need to work with full quality level and frame rate to do this. Save that for when you're mastering the final finished animation.