Image size limitation

[potwnc]

Igor,

Does PTE have a limit on the file size of images?

I have a show with only a few (6 or 7) very large (25MB) images and I get an "image load error" picture instead of my actual image. This happens in preview mode and .exe and .avi output with different codecs, but not on the timeline. My PC is poweful enough and has enough memory to load all the images. So it looks like there is a limit designed into PTE itself - but why not give an error message that the image is too large?

These same images load fine and produce perfect .exe and .avi output and previews in PTE 4.49. They also load fine and produce perfect .avi output from Windows Movie Maker, Vegas Pro 8b and Pinnacle Studio Plus 10.8. So I don't see any reason why PTE 5.1 can't handle them. If I resize them down to about 5MB then PTE can handle them.

Your answer is greatly appreciated as it will determine how I revise the HD appendix of the next version of the User Guide.

Ray

[bmccammon]

I don't have any idea why PTE won't handle them but my question is "why do you want 25mb files to begin with?"

[potwnc]

Because I want to produce full HD (1920x1080 pixels) output with long zooms in the images. That requires very large images, which = very large files.

[cjdnzl]

No, I don't think PTE has a limitation in that direction.

I have just set up a trial with 12 images of 25 MB each, as level 12 jpegs (the highest) in Photoshop, each jpeg is about 5 MB, uncompressing to 25 MB in memory.

I loaded these into PTE 5.1, ran a preview, and then created an exe file. There were no problems either with loading the images or running the preview or exe file.

My computer comprises a 3.00 GHz P4 Northwood CPU, 1 GB ram, and the OS is Win 2000.

I suspect that the error message is from Windows and not PTE. Did the message have an error number, about an 8-character alphanumeric number? That would be helpful.

Also, I know you said your machine was adequate, but could you post the specs, and also were there any background programs running?

Colin

[potwnc]

I have just set up a trial with 12 images of 25 MB each, as level 12 jpegs (the highest) in Photoshop, each jpeg is about 5 MB, uncompressing to 25 MB in memory.

Colin

Colin,

I'm not sure what you mean here. How big are the actual files on your hard drive - 25MB or 5MB?

The error is not a Windows error. I've attached a screen dump of it and the Windows task manager at the time it happens. The actual image containing the error message gets zoomed just as the actual image would if it were the actuual image! If it were a Windows error then Windows wouldn't have the necessary information about my zoom settings for this image.

I have 2 CPUs - each is a quad-core Pentium Xeon running at 2.66 GHz. I have 8GB of physical memory and the task manager screen shows most of it is not being used at the time of the error. I have no other applications running.

Ray

[Lin Evans]

Hi Ray,

Are these 25 meg jpgs? What are the dimensions in pixels? The reason I ask is that if the size of the jpeg in storage is 25 meg and it's done with moderate compression the "actual" size of the file in memory could be as much as 100 meg per file.

Since even the Canon 1DS Mark III at + 21 megapixels doesn't make native jpg images that large, i'm assuming you have interpolated these to get to a compressed file size this large. Remember, PicturesToExe hardware renders at full resolution for any pan, zooms or rotates. If we assume that the "compressed" jpg is 25 meg in size this could mean rendering as much as six gigabytes per second for a pan, zoom or rotate when the program creates sixty frames per second (100 meg true file size times 60 frames per second = 6,000 meg = ~ 6 gigabytes). That's an enormous load on any system.

PTE 4.4x doesn't render it simply displays. So static images are displayed one at a time for the duration necessary for the desired display. This means only one file of the total dimensions and load size is processed for each slide rather than up to 60 per second. Programs which create AVI or mpeg files without hardware rendering downsample to the desired display size (in your case 1080p) and don't playback in real time until the files have rendered and been stored in the final file at which time they are much smaller.

If you want deep zooms, it would be a much better approach to follow the method I explain in my "Superzoom" tutorial where you shoot a few frames with longer focal length lenses and match the 100% size of image one's zoom to the downsized (zoomed out) frame of the following image. This way you have no need for any single image larger in pixel dimensions than your final display device can play. In this case you would get just as good an image as from a huge unmanageable interpolated file of as much as 100 megabytes.

What Colin is saying is that a 5 megabyte jpg (compressed size) compressed in Photoshop to the lowest compression settomg of 12 (highest quality) will have an actual file size of ~25 megabytes when the compressed file expands into memory.

A good example of this is to look at my puzzle files where the appearance on screen is nearly identical but one will challenge even the best hardware and the other will play on even a 32 meg video card. They have practically identical visible pixel dimensions and almost identical compressed zip and executable sizes. The difference is that one expands in memory to over 128 meg per puzzle piece while the other is tiny. The difference is that one has a tiny PNG "footprint" per puzzle piece while the other has a huge 128+ meg footprint per puzzle piece. The "invisible" portions are the transparency sizes which compress greatly but expand back to their true size in memory.

I suspect that what you what to achieve can be easily done with PTE 5.1 but not with files which have a true size of perhaps as much as 100 megabytes per image. Having file sizes this large will not make the end result any better than much smaller files taken with longer focal length lenses.

Unless I totally miss what you are trying to achieve what you need is a different approach to achieve the same end. Keep in mind that none of the other programs you have attempted this with do hardware rendering but rather downsample to the pixel dimensions desired for display.

Best regards,

Lin

Colin,

I'm not sure what you mean here. How big are the actual files on your hard drive - 25MB or 5MB?

The error is not a Windows error. I've attached a screen dump of it and the Windows task manager at the time it happens. The actual image containing the error message gets zoomed just as the actual image would if it were the actuual image! If it were a Windows error then Windows wouldn't have the necessary information about my zoom settings for this image.

I have 2 CPUs - each is a quad-core Pentium Xeon running at 2.66 GHz. I have 8GB of physical memory and the task manager screen shows most of it is not being used at the time of the error. I have no other applications running.

Ray

[potwnc]

Lin,

Thanks for your reply. Some of it makes sense in the context of what I'm doing so let me explain further...

Are these 25 meg jpgs? What are the dimensions in pixels? The reason I ask is that if the size of the jpeg in storage is 25 meg and it's done with moderate compression the "actual" size of the file in memory could be as much as 100 meg per file.

They are around 25MB on the disk. The pixel dimensions are about 8,500 x 5,500.

Since even the Canon 1DS Mark III at + 21 megapixels doesn't make native jpg images that large, i'm assuming you have interpolated these to get to a compressed file size this large.

No. These images were not taken with a digital camera. They are from (35mm) slides taken with a real camera and scanned at 6,400 dpi optical. There is no optical interpolation. The scan produces 48-bit tif files at around 300MB each which I then convert to 24-bit in Photoshop and save as JPEG with the highest quality setting.

Remember, PicturesToExe hardware renders at full resolution for any pan, zooms or rotates. If we assume that the "compressed" jpg is 25 meg in size this could mean rendering as much as six gigabytes per second for a pan, zoom or rotate when the program creates sixty frames per second (100 meg true file size times 60 frames per second = 6,000 meg = ~ 6 gigabytes). That's an enormous load on any system.

Yes. I'm rendering at 30 progressive fps. But look at the specs of the PC I'm using. The SAS hard drives, the video card I have and the 800MHz DDR2 memory are easily capable of meeting the 3GB/s throughput I'm demanding to do what I'm trying to do. When I built this PC about 6 months ago it was the most powerful PC that could be built at the time!

PTE 4.4x doesn't render it simply displays. So static images are displayed one at a time for the duration necessary for the desired display. This means only one file of the total dimensions and load size is processed for each slide rather than up to 60 per second.

I realize that without the PZR of 5.x this is not comparing apples and apples but if I "render" a .avi from 4.4x with a codec other than the PTE codec then there is true video rendering being processed. So a fade from image 1 to image 2 still requires both images to be loaded into memory at the same time to perform the calculation required. But again without the PZR requirement or hardware acceleration being available in 4.x this is also not apples versus apples. That's how I realized that Gary's problem (reported on the thread that lead to this one) is not the same problem.

Programs which create AVI or mpeg files without hardware rendering downsample to the desired display size (in your case 1080p) and don't playback in real time until the files have rendered and been stored in the final file at which time they are much smaller.

I don't expect PTE's preview or its .exe output to be able to do what I require with my current project; that would be beyond current hardware technology. But your point is exactly why I think this is a bug or an unnecessary limitation in PTE for a PC as powerful as mine. My problem is that the render to .avi output also has the image load error. Given that the rendering to .avi output does not have to be perfromed in real time, why does it matter to PTE how long it takes to load the image and then process the effect? Even in 4.4x the render is also not performed in real time when using large images and HD output.

If you want deep zooms, it would be a much better approach to follow the method I explain in my "Superzoom" tutorial where you shoot a few frames with longer focal length lenses and match the 100% size of image one's zoom to the downsized (zoomed out) frame of the following image. This way you have no need for any single image larger in pixel dimensions than your final display device can play. In this case you would get just as good an image as from a huge unmanageable interpolated file of as much as 100 megabytes.

For the project I'm working on the photos have already been taken and can't be taken again. Can you point me to the "Superzoom" tutorial so I can understand this better?

A good example of this is to look at my puzzle files where the appearance on screen is nearly identical but one will challenge even the best hardware and the other will play on even a 32 meg video card. They have practically identical visible pixel dimensions and almost identical compressed zip and executable sizes. The difference is that one expands in memory to over 128 meg per puzzle piece while the other is tiny. The difference is that one has a tiny PNG "footprint" per puzzle piece while the other has a huge 128+ meg footprint per puzzle piece. The "invisible" portions are the transparency sizes which compress greatly but expand back to their true size in memory.

Can you point me to this?

Unless I totally miss what you are trying to achieve what you need is a different approach to achieve the same end. Keep in mind that none of the other programs you have attempted this with do hardware rendering but rather downsample to the pixel dimensions desired for display.

I'm trying to achieve exactly what PTE can do that these other programs can't... produce exceptional, smooth PZR with the image quality of the original image without downsizing to reduce that quality. I can get PTE to output the .avi by turning off hardware acceleration but the video then looks bad when played back on a 1080p monitor.

Ray

[Lin Evans]

Hi Ray,

A few thoughts. You really don't get any increase in image quality from 35mm color film or transparency from scanning at such a high resolution, you just get a larger file size. All usable detail can be captured at about a 4,000 dpi scan. Even drum scans at $75 per image don't get additional detail at greater than 5,000 dpi they just scan grain. With this in mind you may want to try lowering the DPI to about 4,000 and compare. The thing about scanning is that you can scan at higher and higher resolutions but you reach a practical limit with 35mm color film or transparency at about 4K dpi. Anything higher just increases file bloat without giving you any significant detail.

To see the true load size of your files, look at the size of an 8 bit tiff. From your description, it could be in excess of 100 meg per image.

There could well be a bug in 5.1 which is contributing to the problems you are experiencing but even with your computing power remember that 5.1 does "hardware" rendering for DVD. You may want to try the same with 5.0's Video Builder which "didn't" use hardware rendering for the DVD/mpeg creation. This "could" be the difference causing the problems with the huge files. Which video card are you using? Sorry if you mentioned that earlier I missed it.

Go to the Tutorials section and in the "PTE Made Easy" download the AVI on SuperZoom. The essence is that at the time you capture your images and knowing that you may want to zoom to highly detailed areas, you shoot a few overlapping frames to stitch. Then when you want to zoom to detail levels you first find 100% zoom levels for the first image (use "original" to find this) then you load the stitched or longer focal length image temporarily as an object with image 1, zoom it out to match the 100% zoom of image 1 (set opacity to about 40% to visually align and size) then copy/paste the zoom and pan and/or rotate numbers into image 2. This gives you a perfect match for size and position. Then set the opacity back to 100% for image 1 and delete image 2 from the image 1 objects list. This can be repeated as many times as necessary to get even macro detail in the zoom.

It's a bit easier if you actually see it on the tutorial but here are links to two samples. Originally I intended to make the sample for panoramas but the idea is amenable to any zoom. The only thing necessary is to be sure you cover enough real-estate so that when image 2 is zoomed out there is sufficient image size to meet the full screen aspect ratio hence the "stitch" concept.

Look at these two samples which will give you some idea.

http://www.lin-evans.org/pte/kachinazoom.zip

http://www.lin-evans.org/pte/prowler.zip

The first is a one centimeter tall carved Native American Kachina figure zoomed from wide angle to macro. The second is a travel trailer zoom starting at about 28mm and progressively going to 2000mm. On the second one I didn't use stitched images to match, just wanted to show the procedure as a sample but you get some idea of the possibillities. Note the original travel trailer image presented at original size within the "O" of the word "Prowler" at the end of the slide.

Best regards,

Lin

[cjdnzl]

Lin,

Thanks for your reply. Some of it makes sense in the context of what I'm doing so let me explain further...

They are around 25MB on the disk. The pixel dimensions are about 8,500 x 5,500.

No. These images were not taken with a digital camera. They are from (35mm) slides taken with a real camera and scanned at 6,400 dpi optical. There is no optical interpolation. The scan produces 48-bit tif files at around 300MB each which I then convert to 24-bit in Photoshop and save as JPEG with the highest quality setting.

<snip>

Ray

Ray,

I assumed that your quoted file size of 25MB was the uncompressed size. but I see that your uncompressed size is actually about 150 MB, so my trial is not relevant.

Apart from having reservations about your file sizes, and the amount of detail available from a transparency, I can't offer any more help as your computer is a lot more powerful than mine.

But, you didn't say what graphics card you have. That might possibly be your problem.

Colin.

[Barry Beckham]

Potwnc

If you use pan and zoom with images of this size you will very likely have viewers of your show reaching for the escape key. Before you do heaps of work on this, run a couple of lower res tests, you will be surprised that you don't need huge images to get very good pan and zoom.

[Igor]

We didn't add special limitation of images size.

The possible limitation can be in JPEG/PNG library which we use. Personally I never reached this limit in my slideshows and demos. But even if you reached this limit, slideshow will not load these images on any PC, because we use built-in JPEG/PNG/GIF/BMP loader which works equally on any PC.

Also don't worry about limit of particular video card and its memory size, because we use special mechanism of loading of large images to video memory. Some other slideshow makers I've tried don't have this mechanism and fail to load large images depending on particular video card.

[Peter S]

Hi Ray

Just to follow up on Barry's post - you might like to look at this site:

http://gdesroches.free.fr/formation/ftestsdpi_jpg_en.htm

There are some interesting examples of a test card at different jpeg quality levels and a question "Can you see the difference".

There is also a good explanation and examples regarding the old chestnut of DPI.

Kind regards

Peter

[cjdnzl]

Ok, Ray, here is another experiment.

Reminder: my computer comprises an Asus P4E800 DeLuxe m/board, a 3.00GHz Northwood CPU (P4), 1 GB ram, 800 MHz frontside bus, an Nvidia Geforce 6600 GT graphics card, and Win 2000 OS.

I took my earlier test (see my post above), and using Irfanview I batch resized the 12 images to 8500 * 5665 pixels, which made the images 144MB each, near enough to your 150 MB. The compressed images on disk were around 20-odd MB.

I opened up PTE 5.1, imported the 12 images (cf your seven images), which happened at a rate of about two images per second. I set up the output for a 16:10 screen, and just for fun I zoomed a couple right out to about 495% of original.

I then clicked on Preview - and the show ran impeccably, zooms and all. Then I made an exe file, which turned out to be about 60 MB, and it also ran impeccably.

Since your machine is considerably more powerful than this one, there is clearly something wrong. I don't suppose you are running Vista? that could be your problem.

Colin

[potwnc]

Colin,

I'm running XP Pro, 64-bit. Can you try with all your slides having zoom? And try with hardware acceleration turned on and your Screen option at Full screen (not Windowed) and 16:9?

Thanks

Ray

[cjdnzl]

Colin,

I'm running XP Pro, 64-bit. Can you try with all your slides having zoom? And try with hardware acceleration turned on and your Screen option at Full screen (not Windowed) and 16:9?

Thanks

Ray

Hello Ray,

Yep, have done. Image sizes as before, options set to 16:9 (DVD), monitor set at 1280*1024, full screen and hardware acceleration (D3D) on, 4 seconds per slide and and 1.5 secs transitions for each slide (default settings), all 12 slides set for 500% zoom, and all panned away from the central part of the image.

I'm sorry to tell you this, but the show ran as before, not so much as a single stutter throughout the show.

I thought of uploading it, but here in New Zealand the upload speed is throttled to only 128Mb/s, so it would take for ever.

I would think XP Pro 64-bit should handle your slides easily, specially with your computer specs. What other software is running when you have this problem? My machine has ZoneAlarm Pro only, I don't run anything like Norton or McAfee.

Colin

[potwnc]

Colin,

Could you please upload just the .pte file - without the photos?

Thanks

[cjdnzl]

Colin,

Could you please upload just the .pte file - without the photos?

Thanks

Yes - if I knew where to upload it! If you can tell me where, it'll be a snap.

Meanwhile more bad or good news, depending on your point of view I thought I would really stress this thing, so I increased the file sizes to 10,000 * 6700 approx., that's a file size of 200 megabytes. Twelve of those is 2.4GB, far bigger than my 1 GB of memory.

But, with all other parameters unchanged, PTE previewed and ran the same as before, no hiccups, no stutters, just a smooth show.

It would appear that PTE is not the problem with your system.

Colin

[potwnc]

Colin,

Thanks for all your help with this.

I just sent you a private message via the forum.

Ray

[potwnc]

Colin,

We're still not comparing apples with apples here... your project has all the images set to "Fit to slide" mode in the Objects and Animation view, whereas mine has them set to "Original."

Also, your project does not have defined transition effects, whereas mine does.

Also, your project has no music track, whereas mine does.

Would you be willing to make the first of these changes and post your results? (If not I can post a .pte file with these changes that you can just download it and try on your PC.)

Then we'll see whether that's the difference or whether we need to look at the custom transition and sync to music variables.

Again, thanks for your continued help with this - I'm sure all members will benefit once we figure this out!!!

Ray

[cjdnzl]

Colin,

We're still not comparing apples with apples here... your project has all the images set to "Fit to slide" mode in the Objects and Animation view, whereas mine has them set to "Original."

Also, your project does not have defined transition effects, whereas mine does.

Also, your project has no music track, whereas mine does.

Would you be willing to make the first of these changes and post your results? (If not I can post a .pte file with these changes that you can just download it and try on your PC.)

Then we'll see whether that's the difference or whether we need to look at the custom transition and sync to music variables.

Again, thanks for your continued help with this - I'm sure all members will benefit once we figure this out!!!

Ray

Well, I'm getting pessimistic about your problem, Ray. Actually, during my playing around, I did define only the fade transition, but when I increased the file sizes to 200MB it was a fresh start and I just left the random transitions, but i did set the screen to 16:9, and checked that D3D was on. I also loaded just today a sound track and synced it to the slides

None of these changes made any difference. The show still previewed and ran as before. I even made an ISO file, and it ran in WMP, a bit stuttery, but it ran.

But, now the plot thickens.

I transferred the project files from my P4/win 2000 machine to my Dell 1520 laptop. This machine has a duo core 1.8GHz processor, 3 GB ram, a GeForce 8600M GT graphics processor, a 160 GB 7200 rpm HD, - and Win XP Pro. On paper, this should be a better machine than my desktop - but attempting to preview the same slides that ran on my Win 2000 machine presented me with the load error that you are getting. I can't find where the message is coming from, and it doesn't look like a standard Windows message box - far from it, in fact. But, I'm thinking it has to be something to do with Windows, since all the other programs like Java, DirectX, etc. are on my desktop, and the only difference is Win 2000 and Win XP Pro.

Given the horsepower of your machine, I think it has to be XP

I have suspected before that Microsoft's sudden change of heart over XP is for ulterior motives, and I wonder if they have built some of their DRM checking 'features' into the service packs, which could possibly be the cause of the problem.

Could you find a machine running win 2000 that you could experiment with? 2000 doesn't recognise multiple processors, so I don't want to put it on this laptop, even though I prefer 2000 to XP.

Colin

[potwnc]

Colin,

I don't have Windows 2000. But how strange that XP itself would be the problem in the equation! I wonder if it's any better with Vista - which I also don't have.

Igor, is there any way you can report this to Microsoft for them to investigate?

[cjdnzl]

Colin,

I don't have Windows 2000. But how strange that XP itself would be the problem in the equation! I wonder if it's any better with Vista - which I also don't have.

Igor, is there any way you can report this to Microsoft for them to investigate?

Hold everything while I do some re-checking. I may have an inadvertent problem here ... back asap

Colin

[potwnc]

Colin,

Do you have any new information?

Ray

[cjdnzl]

Colin,

Do you have any new information?

Ray

Yes. Much egg on face. My initial tests were with 5 MB compressed jpegs of 25 MB full size images, a mistake I made when you said you were using 25 MB images, as I didn't realize you meant 25 MB compressed - 150 MB full size.

So I uprezzed the images to 150 MB more or less, and opened up PTE again, failing to see that the images in PTE were still the smaller ones. so of course it worked.

But when I saved them onto a usb drive and took them to the laptop, the 150 MB images were imported into PTE, and I got the load error.

Then I tried the large files on the desktop, and although I got no load error, it was clearly too much for either PTE or my computer, as it did run, but very slowly, a minute or more between slides, then PTE baled out after about 4 slides. Possibly where 2000 just baled out, XP might give the load error message, but it's moot, since it doesn't work in either OS.

Just on file sizes, HDTV at 1920*1050 pixels is 2 MP, so at 8-bit depth the file size is about 6 MB. For a five-times zoom the file need only be about 30 MB, and at that you can push the zoom a bit further, say 7 times before the definition falls off noticeably. Likewise, you could probably manage a 10x zoom with a file size about 40 or 45 MB.

I resized my images to 4,600* 3082, which gave a file size of about 42 MB, and the show ran normally on my desktop.

Perhaps this is what you have to do. Unless your requirements are for a greater zoom depth than 10x, I don't think you need bigger than 45 MB.

Colin

[potwnc]

Colin,

Thanks for all the time you've spent repeating all these tests and, in the end, confirming my findings.

I've been doing some more research in the meantime and it does appear that this is a Windows issue and not a PTE issue.

I'll do some more research before I update my HD tutorial for the PTE 5.2 release.

It still shocks me that Windows would produce this error with my small project given the specs of my PC! I guess this is why those who work with such very demanding A/V projects use Macs and UNIX computers. All I can say is that I hope Igor gets the Mac version working very soon!

Fortunately, with Lin's "superzoom" technique I will be able to work around this limitation - although it will cost me a lot of time dividing up my images.

Ray