X3 Resizing Problem

[janem1212]

Thank you for your replies, John and Ron!

John, if I understand you correctly, you're saying my graphics card is the problem?

Ron, is your AGP Texture acceleration enabled?

I searched Intel's site for "AGP Texture Acceleration" and found the following info:

http://www.intel.com/support/graphics/sb/CS-009689.htm

============
AGP Texture Acceleration shows as "Not Available"

Symptom(s):

In the Microsoft* DirectX* Diagnostic Tool (dxdiag), AGP Texture Acceleration shows as "Not Available" on the "Display" tab.

Cause:

Older graphics drivers reported the DVMT (Dynamic Video Memory Technology) memory as non-local video memory (AGP memory). To improve compatibility, this has been changed in newer graphics drivers so that DVMT memory is reported as local video memory.

Solution:

This is expected behavior with the PV 14.x graphics drivers.

For the Intel® Extreme Graphics products, memory that was reported as AGP memory when using PV13.x graphics drivers is now reported as local memory when using PV 14.x graphics drivers. This change should not affect game or application performance since both the local memory and AGP memory are identical in performance.

Operating System:
Windows* 2000, Windows* XP Professional, Windows* XP Home Edition, Windows* XP Tablet PC Edition, Windows* XP Media Center Edition

This applies to:
** Intel® 82915G/82910GL Express Chipset Family ** my chipset
============

Does the above mean that the AGP Texture Acceleration issue should be irrelevant to my problem?

Thanks again,
Jane

[Ron P.]

Sorry forgot to answer part of your question

Yes I do show that AGP texture acceleration is enabled. From what you have posted, yes it should be irrelevant.

[sisom]

I agree, AGP texture acceleration is absolutely nothing whatsoever to do with this!
I'm using PI12, and it's happened to me only when I do several pictures. It's obviously some kind of bug in the program, what else could possibly be causing it?

[John Moran_2]

I agree, AGP texture acceleration is absolutely nothing whatsoever to do with this!
I'm using PI12, and it's happened to me only when I do several pictures. It's obviously some kind of bug in the program, what else could possibly be causing it?

Overheating.

[Ron P.]

Overheating..

Did you overclock it? I'd do some cleaning if that has not been done. Dust can accumulate on the heat sinks and fan blades.

You might try placing a small fan to where it blows into the air intake of your tower. Some people will open the case, and have a fan blow into it, however I don't subscribe to that, as the cases are designed to have air flow through them, and cool the components.

However disregard the above, if you're using a Laptop, which some are notorious for heat build up.

[sisom]

No, it's not overheating. It's a bug in PI12, it's full of them. Look at my other recent post.

[heinz-oz]

No, it's not overheating. It's a bug in PI12, it's full of them. Look at my other recent post.

You can call something a bug if you can reproduce it. Thus far, on 3 of my machines, all different spec's, I have been unable to. There are a number of posters on the different boards to this very same subject who also do not have this problem.

A very selective bug I'd say.

[sisom]

It's still a bug. Some bugs are intermittent. Maybe it's something to do with a specific size setting in the resize option, and the number of times you do it, and any number of other operations that occurred beforehand in PI, and when they all occur in a certain sequence, a flag or something goes wrong.
It's certainly not down to overheating - my PC's on for days at a time, and would have crashed completely long before now.

Did you test it with PI12 as well, Heinz?

Have a look at my other recent post, "PI12 Resizing box causes border change" for another serious problem.

[heinz-oz]

It's still a bug. Some bugs are intermittent. Maybe it's something to do with a specific size setting in the resize option, and the number of times you do it, and any number of other operations that occurred beforehand in PI, and when they all occur in a certain sequence, a flag or something goes wrong.
It's certainly not down to overheating - my PC's on for days at a time, and would have crashed completely long before now.

Did you test it with PI12 as well, Heinz?
Yes I did, same results

Have a look at my other recent post, "PI12 Resizing box causes border change" for another serious problem.

Where would I find that? Can you provide a link?

[sisom]

Sure Heinz, it's here

http://phpbb.ulead.com.tw/EN/viewtopic. ... cf56ffa941

[John Moran_2]

It's certainly not down to overheating - my PC's on for days at a time, and would have crashed completely long before now.

Sisom:
Suggest that you take steps to clean out all dust and lint from your cpu heat sink and fan. Suggest that you also consider temporarily pulling the heatsink off the cpu and sparingly applying new "thermal grease", whatever it is called.

Then put everything back together and see if you get more consistent results with PI X3 resizing. If a laptop is involved, cleaning is more difficult, but also more likely to be needed. Sounds redundant, doesn't it, ut I've "been there, done that" more than once after blaming my newest hobby software over the years.
John

[John Moran_2]

When I use the Adjust - Resize feature on PhotoImpact X3 the image does not resize to the selected size.

For example, my starting image is 2272x1704. I select Adjust - Resize and type in a Height of 324 Pixels - leaving the "Keep aspect ratio" box selected (so Width is automatically changed to 432). The Resample method used in this particular instance was Bilinear (I've used Bicubic before as well w/the same resultant problem)- Resolution of 72 Pixels/Inch. I did not change the "Document size". I select OK and my resultant image resize is 243x182 - NOT what I selected. I hit the Undo button and I select Adjust - Resize again - the settings are 243x182 - it doesn't show the selection I made.

I have to go through Adjust - Resize several times before the image will size the way I select it. . . .

Cheers,
Jane

Jane-
It seems necessary to Deselect the "Keep aspect ratio" box as a final step in order to ensure that final size is exacty the number of pixels you desire. Otherwise, the final pixel count may be calculated to a number that is one (1) or a few pixels off. As to the major shifts from 432 to 243 or 324, that sounds like something is making a typo error, but probably not??? I have not been able to duplicate major shifts - yet.
John

[janem1212]

Hmm, interesting. So far it seems that deselecting the "Keep aspect ratio" button as the final step is working to get the correct height - that is, the height I requested.

Before I read your suggestion, John, I did a few more tests earlier today (with the "Keep aspect ratio" button) selected and got varying results. This time 4 of my 5 tries resulted in an incorrect height (height not what I selected):

----------
original image size (WxH) 1621x1704 - requested: 324 pixels high, result: 432 x 454 (height incorrect!), 2nd request resizes correctly to the specific height I requested

original image size (WxH) 1704x2272 - requested: 324 pixels high, result: 308 x 411 (height incorrect!), 2nd request resizes correctly to the specific height I requested

original image size (WxH) 2162x1615 - requested: 324 pixels high, result: 243 x 182 (height incorrect!), 2nd request resizes correctly to the specific height I requested

original image size (WxH) 2272x1704 - requested: 324 pixels high, result: 434 x 326 (height incorrect!), 2nd request resizes correctly to the specific height I requested
----------

I guess I'm not convinced that this is not a bug, even though many others on other forums do not appear to be experiencing the same problem. If there was a problem with the height I was requesting (such as partial pixels, etc.), why does the program resize to the height I requested the second time I attempt the resize? Additionally, if there is a problem with the height I selected, why will PI10 resize my photos to the exact height I request EVERY TIME? If there was a problem with my system, why does PI 10 perform the requested task correctly - without fail.

This problem sure looks and acts like a bug. I don't think the AGP Texture Acceleration path they sent me down is a correct one.

As a side note, I submitted a support request to Corel on 3/14/08 and still haven't heard anything back from them. This is the lousiest support I've received with a new software product ("free, unlimited tech support by email" is wholly unimpressive). I'm very discouraged and 'turned-off' to Corel products as a result of their lack of assistance. What has been helpful is this forum as well as other PI forums. Thanks so much, Folks!!

Cheers,
Jane

[sisom]

John, it's nothing to do with overheating...

[sisom]

I guess I'm not convinced that this is not a bug, even though many others on other forums do not appear to be experiencing the same problem. If there was a problem with the height I was requesting (such as partial pixels, etc.), why does the program resize to the height I requested the second time I attempt the resize? Additionally, if there is a problem with the height I selected, why will PI10 resize my photos to the exact height I request EVERY TIME? If there was a problem with my system, why does PI 10 perform the requested task correctly - without fail.

Too true. It's a bug. Pure and simple.
Re the support - this is just typical of almost all companies nowadays. How long would it take just ONE competent person to answer e-mails every day? I answer e-mails within about one minute, maybe the occasional one takes two minutes, so what sort of staff are they hiring? Ebay's cast offs?

This is an intermittent bug, and no doubt it's caused by a certain number of other options and commands having been selected/done within PI beforehand, and some sort of junk code is getting left behind where it shouldn't, and it then affects the resizing option.

It seems necessary to Deselect the "Keep aspect ratio" box as a final step in order to ensure that final size is exacty the number of pixels you desire. Otherwise, the final pixel count may be calculated to a number that is one (1) or a few pixels off. As to the major shifts from 432 to 243 or 324, that sounds like something is making a typo error, but probably not??? I have not been able to duplicate major shifts - yet.

Why would it calculate the final pixel count to a number that is one or a few pixels off? The Keep Aspect Ratio is pretty simple programming: divide the start width by the start height, and you get a number: then divide the requested new width or height by that number, to get the opposing measurement. It's as simple as can be.