Image Size

[Hatter]

Just an observation on PTE5 that others may find helpful if they encounter the same issue...

I've been trying out the zoom & pan features and I'd set up one slide that was a photograph looking through an arch. I wanted to set it up so that the view zoomed into the scene on the other side, making it appear that the viewer was going through the arch.

In order to keep the resolution of the "zoomed" image about equal to the other slides, I used the full sized image rather than a resized one. The photo as taken was 3072 pixels high by 2048 wide and I padded the sides with black to make it 4096 wide:

The end point of the animation was the central part, filling the full screen, like this:

This works fine on my desktop PC (2.8 GHz CPU with 1 Gb ram) but my laptop (1.4 GHz CPU with 256 Mb ram) can't handle it - the sound breaks up and the slide before this one stays on screen for ages. Then the end frame only of the animation is displayed, followed by the next few slides in quick succession until it catches up with where it should be.

I'm guessing that the processing power needed for PTE to resize the image that big on the fly is beyond the capabilities of my laptop - even though it (just) meets the minimum requirements for PTE with pan/zoom.

If I resize it to 1024 x 768 like all the other slides, it's fine on the laptop, although there's obviously a noticeable drop in image quality at the end of the "zoom".

Gareth

[Lin Evans]

Hi Gareth,

One easy solution to greatly reduce the loading on the laptop video card would be to just crop out the arch into the minimal rectangle of black around it. This black would be identical to the "dark" LCD or CRT monitor so no need for the additional black and the "padding" on the sides. If you have a different shade of black, just change it in Photoshop or your choice of editor to 000,000,000 to match zero light on the monitor.

Unless you are playing it with a different colored background on the PC, it should greatly reduce the size of the file so that you would be zooming into the larger image but saving a great deal of file size for the arch photo.

Best regards,

Lin

Just an observation on PTE5 that others may find helpful if they encounter the same issue...

I've been trying out the zoom & pan features and I'd set up one slide that was a photograph looking through an arch. I wanted to set it up so that the view zoomed into the scene on the other side, making it appear that the viewer was going through the arch.

In order to keep the resolution of the "zoomed" image about equal to the other slides, I used the full sized image rather than a resized one. The photo as taken was 3072 pixels high by 2048 wide and I padded the sides with black to make it 4096 wide:

The end point of the animation was the central part, filling the full screen, like this:

This works fine on my desktop PC (2.8 GHz CPU with 1 Gb ram) but my laptop (1.4 GHz CPU with 256 Mb ram) can't handle it - the sound breaks up and the slide before this one stays on screen for ages. Then the end frame only of the animation is displayed, followed by the next few slides in quick succession until it catches up with where it should be.

I'm guessing that the processing power needed for PTE to resize the image that big on the fly is beyond the capabilities of my laptop - even though it (just) meets the minimum requirements for PTE with pan/zoom.

If I resize it to 1024 x 768 like all the other slides, it's fine on the laptop, although there's obviously a noticeable drop in image quality at the end of the "zoom".

Gareth

[cjdnzl]

I don't suppose you have burned the show to a DVD and are playing that on the laptop? Laptops commonly cannot read a DVD fast enough to present a smooth show, and the software codec in the laptop may not be able to keep up as well.

We have this problem sometimes at the Camera club when somebody brings along a show - usually a ProShow compilation - and playing the DVD on the club laptop is unwatchable. A workaround we use is to copy the show to the hard drive, which generally works, depending on the complexity of the show's construction.

If the above is the case, you could try burning an exe file to a CD and playing that on the laptop.

[alrobin]

One easy solution to greatly reduce the loading on the laptop video card would be to just crop out the arch into the minimal rectangle of black around it. This black would be identical to the "dark" LCD or CRT monitor so no need for the additional black and the "padding" on the sides. .........

However, due to the nature of the jpeg compression algorithm, each image would probably still be about the same file size. In fact, with an example I tested, even though the pixel dimensions are smaller, the cropped file is even larger than the version which had been blacked out. So would this method really save that much in processing time required?

[Lin Evans]

Hi Al,

It's relative, I suppose, but there will be a significant file size difference. Whether that difference is sufficient to help depends on the amount of overload.

As an example, here is a photo of the moon, surrounded by a black sky - then a crop of the moon from the original. A pure "black" sky doesn't have much in the way of detail so compresses really well, but the actual dimensions of the expanded files in memory are still quite different. In the case of the arch, the savings wouldn't be as significant because the arch probably occupies about double the area of the moon in my sample, but in this case the moon surrounded by the black sky is 513K when virtually uncompressed with Photoshop level 12 while the cropped moon is 148 K. With that ratio I would assume that cropping the arch and removing all the extra black would result in at least a savings of half the file size.

http://www.lin-evans.net/pte/moon.zip

Best regards,

Lin

However, due to the nature of the jpeg compression algorithm, each image would probably still be about the same file size. In fact, with an example I tested, even though the pixel dimensions are smaller, the cropped file is even larger than the version which had been blacked out. So would this method really save that much in processing time required?

[Igor]

Gareth,

What video card used in your laptop?

If it's an integrated graphical solution and overall system memory 256 MB, video card might take 64 MB for own needs, so you have only 192 MB of system memory in slide show.

1) First possible reason - lack of video memory.

2) Lack of system memory.

Or both reasons together.

To handle very large images in slide show it's necessary to have NVIDIA or ATI video card. Newest laptops with integraded graphical card based on Intel 965 platform (codename "Santa Rosa") also should be enough fast.

p.s. Lin adviced very well solution for this particular image which will keep same high quality and smoothness of animation on your laptop.

[alrobin]

It's relative, I suppose, but there will be a significant file size difference. Whether that difference is sufficient to help depends on the amount of overload.

As an example, here is a photo of the moon, surrounded by a black sky - then a crop of the moon from the original. A pure "black" sky doesn't have much in the way of detail so compresses really well, but the actual dimensions of the expanded files in memory are still quite different. In the case of the arch, the savings wouldn't be as significant because the arch probably occupies about double the area of the moon in my sample, but in this case the moon surrounded by the black sky is 513K when virtually uncompressed with Photoshop level 12 while the cropped moon is 148 K. With that ratio I would assume that cropping the arch and removing all the extra black would result in at least a savings of half the file size.

Lin,

If you examine the "dark" area of your smaller moon view with your cursor in PS, you will still find a fair amount of texture there. Choose a black brush and go over that area to make it totally black, and then re-save, and I think you will find a significant further reduction in the file size, thus illustrating my premise that there is not much difference in file size between the two cases, even when saved at 100%.

If you were to repeat this with the actual example of a doorway, which is a greater proportion of the total image area, you would find the difference in file size between the two even less.

[Lin Evans]

Hi Al,

Yes, that's why my original suggestion to make the black 000,000,000 to match the completely dark CRT or LCD without having the excess dimension.

Best regards,

Lin

Lin,

If you examine the "dark" area of your smaller moon view with your cursor in PS, you will still find a fair amount of texture there. Choose a black brush and go over that area to make it totally black, and then re-save, and I think you will find a significant further reduction in the file size, thus illustrating my premise that there is not much difference in file size between the two cases, even when saved at 100%.

If you were to repeat this with the actual example of a doorway, which is a greater proportion of the total image area, you would find the difference in file size between the two even less.

[Hatter]

Thanks for the replies, everyone.

Lin - your suggestion of cropping the image down does help - thanks.

I cropped it to this:

and then downsized it a bit to 1500 x 800 - which was small enough for my laptop to handle it.

cjdnzl - it was running from the laptop's hard drive rather than a DVD. I've not tried running from a DVD but I've found that even running from CD is slower than running from the HD. I've been using PTE on this laptop for some time for the competitions at my local camera club and I originally tried running them from a CD but found that the images changed quicker and much more smoothly if I copied the EXE file to the laptop.

Al / Lin - I'm not convinced it's the file size that matters. I used a JPEG quality of 6 which compressed the image down to around 750k - I think it's the image size in memory that's the problem.

Igor - does the following help?

Intel® Graphics Media Accelerator Driver for Mobile Report

Report Date: 06/15/2007

Report Time[hr:mm:ss]: 18:27:18

Driver Version: 6.14.10.4543

Operating System: Windows XP* Home Edition, Service Pack 2 (5.1.2600)

Default Language: English

DirectX* Version: 9.0

Physical Memory: 246 MB

Minimum Graphics Memory: 8 MB

Maximum Graphics Memory: 128 MB

Graphics Memory in Use: 10 MB

Processor: x86 family 6 Model 14 Stepping 8

Processor Speed: 1463 MHZ

Vendor ID: 8086

Device ID: 27A2

Device Revision: 03

* Accelerator Information *

Accelerator in Use: Mobile Intel® 945GM Express Chipset Family

Video BIOS: 1237

Current Graphics Mode: 1280 by 800 True Color (60 Hz)

* Devices Connected to the Graphics Accelerator *

Active Notebook Displays: 1

* Notebook *

Monitor Name: Plug and Play Monitor

Display Type: Digital

Gamma Value: 2.0

DDC2 Protocol: Supported

Maximum Image Size: Horizontal: Not Available

Vertical: Not Available

Monitor Supported Modes:

1280 by 800 (60 Hz)

Display Power Management Support:

Standby Mode: Not Supported

Suspend Mode: Not Supported

Active Off Mode: Not Supported

* Other names and brands are the property of their respective owners.

[Lin Evans]

Thanks for the replies, everyone.

Lin - your suggestion of cropping the image down does help - thanks.

I cropped it to this:

and then downsized it a bit to 1500 x 800 - which was small enough for my laptop to handle it.

cjdnzl - it was running from the laptop's hard drive rather than a DVD. I've not tried running from a DVD but I've found that even running from CD is slower than running from the HD. I've been using PTE on this laptop for some time for the competitions at my local camera club and I originally tried running them from a CD but found that the images changed quicker and much more smoothly if I copied the EXE file to the laptop.

Al / Lin - I'm not convinced it's the file size that matters. I used a JPEG quality of 6 which compressed the image down to around 750k - I think it's the image size in memory that's the problem.

snip...

Of course, that's what we mean by file size. JPG's expand from the compressed format to their full size in memory, but the more you can remove from the area of the original file the smaller this uncompressed size will ultimately be. As Al pointed out, pure black has very little overhead so making this part of the remaining black area 000,000,000 only helps to further reduce load overhead. Actually "painting" the full sized image with pure black everywhere around the arch would have reduced the size by a great deal, but it's easier to simply crop it and let the monitor black substitute.

Best regards,

Lin

[Hatter]

Of course, that's what we mean by file size. JPG's expand from the compressed format to their full size in memory, but the more you can remove from the area of the original file the smaller this uncompressed size will ultimately be. As Al pointed out, pure black has very little overhead so making this part of the remaining black area 000,000,000 only helps to further reduce load overhead. Actually "painting" the full sized image with pure black everywhere around the arch would have reduced the size by a great deal, but it's easier to simply crop it and let the monitor black substitute.

Sorry... I misunderstood then.

I had thought that the amount of RAM taken by an image in memory depended solely on the number of pixels rather than the contents of those pixels, but if that's not the case then fair enough.

A combination of cropping it down and a small resize did the trick anyway!

Gareth

[Lin Evans]

You didn't really have a misunderstanding. Let me try to be more explicit. The amount of RAM used does indeed depend on the number of pixels. If you look at uncompressed tiff files, there is a direct proportional relationship between the number of pixels constituting the file and the size of the file in bytes. So cropping out the arch is by far the most important thing. With jpeg, the less "detail" in the image, the higher it will "compress" but as you correctly assume, the absolute file size determines the RAM requirements. For example, if you take two identical image captures of fairly detailed subject matter then apply noise reduction to one and not to the other, the jpg with noise reduction applied will have a smaller compressed file size than the one with the additional "detail" i.e., noise. But when they expand into memory, each will have identical RAM requirements. So making the area pure black around the cropped arch will only actually reduce the jpg compressed file size rather than actual load size. I was not clear at all when I posted that making the full sized image have a pure black would affect file size. What I meant is that the JPG file size would be smaller because pure black compressed easier than whatever latent detail may be in the non-pure black background. Making it pure black only facilitates the blend or "match" between the dark portion of the LCD or CRT and the image.

Your original understanding is absolutely correct about the "true" file size after expansion into memory. Only the file size of the compressed jpg is different depending on the nature of the components of the image itself and only because of compressibility.

Best regards,

Lin

Sorry... I misunderstood then.

I had thought that the amount of RAM taken by an image in memory depended solely on the number of pixels rather than the contents of those pixels, but if that's not the case then fair enough.

A combination of cropping it down and a small resize did the trick anyway!

Gareth

[Kalain]

Hi,

(pre release 15 June)

I just wanted to report some very similar visual problems. Probably more hardware problem than software (PTE) problem.

Here is full project to try : http://kalain.pierre.free.fr/pte/Project1_...07_13-16-24.zip

What is the problem ?

Zoom effect of third image (920kb) is not smooth.

At the end of 1500ms 3rd image effect, zoom is not linear and has a quick speed hesitation.

zoom speed is linear (no quick speed hesitation) for second image (120kb)

I got a radeon 8500 video card :

Adaptateur Vidéo

Modèle : RADEON 8500 SERIES

Chipset : RADEON 8500 Series AGP (0x514C)

RAMDAC : Internal DAC(400MHz)

BIOS Vidéo : BK7.4.0 VR000.000.007.004.000.001.001 ldfyy

Compatible VGA : Non

Mémoire Totale : 64MB (64MB Vidéo) (54MB Système)

Mémoire de Texture : 118MB

Supporte Texture DIME : Oui

Mode Vidéo Actuel

Mode : 1280x1024 16M+ Vraies Couleurs (32-bit)

Taux de Rafraîchissement Actuel : 85Hz

Taille du Bureau Virtuel : 1280x1024

CPU : Athlon 2100+

Memory : 512Mb DDR SDRAM

Alain

[Ken Cox]

ALAIN

smooth on my system

ati 256 all in wonder

2.8 ghz intel

1 gb swp

1 gb ram

ken

[alrobin]

Alain,

I noticed a slight hesitation on slide 2 at the end of the fade transition out of the previous slide and into the 2nd slide, but only the first time I played it. After that it was fine.

It is normal to experience a hesitation like this under the following conditions:

a) if your video card doesn't have sufficient memory. I would say that 64 mb is not enough for some PZRO arrangements - only for very slow effects.

a+)if your monitor is using a resolution higher than the images (i.e. higher than 1200 x 900 in your case).

c) if your images are too large (900 kb may be too large for smooth effects with your video card in this example). It is still fading out when you are zooming the next slide. Try waiting until the fade out is complete before starting the zoom to see if the hesitation is still there (see attached example).

d) if you are trying to zoom a car on it's side !

Project1_ar.zip

[Igor]

Alain,

I don't see any problem with your project. Log files shows that all is OK. Probably it is a visual impression?

Do you always see this problem (if run 2nd, 3rd time, etc)?

Please run notepad, type:

Project1.exe -log -frametimes

Save this file as Test.bat and put it to same folder where located your Project1.exe file with 3 slides.

Run Test.bat file and when it finishes, you'll find Project1.log text log file. Please send it to me (as attachment to the forum message).

[Kalain]

Alain,

I noticed a slight hesitation on slide 2 at the end of the fade transition out of the previous slide and into the 2nd slide, but only the first time I played it. After that it was fine.

There is zoom hesitation (3rd image : 900kb) each time when I play slideshow.

It is normal to experience a hesitation like this under the following conditions:

a) if your video card doesn't have sufficient memory. I would say that 64 mb is not enough for some PZRO arrangements - only for very slow effects.

a+)if your monitor is using a resolution higher than the images (i.e. higher than 1200 x 900 in your case).

c) if your images are too large (900 kb may be too large for smooth effects with your video card in this example). It is still fading out when you are zooming the next slide. Try waiting until the fade out is complete before starting the zoom to see if the hesitation is still there (see attached example).

Yes, problem seems to come from my videao card.

If third image (900kb) is replaced by another same one smaller (120kb) there is no zoom hesitation just after effect (between 2nd and 3rd images)

d) if you are trying to zoom a car on it's side !

Project1_ar.zip

This is what I have on my desktop and enough to try some effects in PTE.

Alain

[Kalain]

Alain,

I don't see any problem with your project. Log files shows that all is OK. Probably it is a visual impression?

This is a real visual impression.

Do you always see this problem (if run 2nd, 3rd time, etc)?

Yes, I see each time the problem (run 2nd, 3rd, .... times)

But If I replace 3rd image (920kb) by same one smaller (120kb) the problem deasapear.

So, I guess this problem comes from my (too) small video card performance. (This was quite a good one 3 or 4 years ago. )

Please run notepad, type:

Project1.exe -log -frametimes

Save this file as Test.bat and put it to same folder where located your Project1.exe file with 3 slides.

Run Test.bat file and when it finishes, you'll find Project1.log text log file. Please send it to me (as attachment to the forum message).

Here it is.

Alain

[Igor]

Alain,

Please remind me what video card you have installed?

p.s. you forgot to attach log file.