Loading Profile...
Topaz Adjust Crash, Can't Use :(
When it is working, Topaz Adjust is brilliant and does a really nice job.
Unfortunately it usually crashes with the following error:
"procEngine: error code: -1000"
Note I have done the following:
* I have downloaded the latest version as of May 16, 2009
* As per forum suggestions, I have made sure my Windows Virtual Memory size is 4096 mb.
* As per forum suggestions, I have experimented with reducing the amount of memory used by Photoshop.
Note that I have the following setup:
* Windows Vista Ultimate 32-bit with 2gb of RAM.
* Photoshop CS4.
* Using photos from a Canon 5D Mark II, which are large, although the crash will occur with smaller photos.
My system is otherwise stable and works well. I love Topaz Adjust, but find that I can't use it predictably.
I found no follow-up, no suggestions as to what to try next in existing posts.
Please help.
Unfortunately it usually crashes with the following error:
"procEngine: error code: -1000"
Note I have done the following:
* I have downloaded the latest version as of May 16, 2009
* As per forum suggestions, I have made sure my Windows Virtual Memory size is 4096 mb.
* As per forum suggestions, I have experimented with reducing the amount of memory used by Photoshop.
Note that I have the following setup:
* Windows Vista Ultimate 32-bit with 2gb of RAM.
* Photoshop CS4.
* Using photos from a Canon 5D Mark II, which are large, although the crash will occur with smaller photos.
My system is otherwise stable and works well. I love Topaz Adjust, but find that I can't use it predictably.
I found no follow-up, no suggestions as to what to try next in existing posts.
Please help.
I’m frustrated
1
person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
The company .
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?I, too have seen numerous Adjust 3 crashes, but with Paint Shop Pro X2. To his credit, Albert (?) worked with me for quite a while, but I kinda got back in the habit of using Adjust 2.6 since it's much more stable. Just this evening, I opened Adjust 3, previewed a few presets, then canceled out and didn't apply anything. Shortly thereafter, PSP abended with this followup from Vista :
Problem signature:
Problem Event Name: APPCRASH
Application Name: Corel Paint Shop Pro Photo.exe
Application Version: 12.0.1.0
Application Timestamp: 4727ce74
Fault Module Name: tliadjust26.dll_unloaded
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4960cab3
Exception Code: c0000005
Exception Offset: 0e3b3b03
OS Version: 6.0.6001.2.1.0.768.3
Locale ID: 1033
Additional Information 1: fd00
Additional Information 2: ea6f5fe8924aaa756324d57f87834160
Additional Information 3: fd00
Additional Information 4: ea6f5fe8924aaa756324d57f87834160
In the past it's typically been unload errors, but this time the error occurred right after I used Adjust 3, not after 2.6 (which was earlier, although it appears to have interacted somehow based on the module name). All of this follows a fresh reboot. In my case it's Paint Shop Pro X2 (12), Vista 32 SP1, 3 GB RAM, Canon 350D -
Inappropriate?Hi Akilah,
Using Canon 5D Mark II photos with only 2gb of RAM is on the boundaries of not having enough memory to support the images you are working with. Which is what is causing the crashes.
I would suggest that you consider upgrading to 64-bit or installing more memory on your machine.
Please let me know if you have any other questions.
Best,
Ashley
-
Inappropriate?Just curious - Although I agree that 2GB is small in practical terms, aside from performance issues related to swapping and such, shouldn't Adjust (indeed, any app) have as much "memory" to work with as RAM + swap? The MMU should present memory as memory, whether RAM or disk. How would simply swapping to disk cause crashing? Once again it will be slower, but that should be all.
-
Inappropriate?Ashley, virtual memory can operate well past 2gb.
I find it disappointing that, after weeks of asking for help, the answer is: consider an expensive upgrade.
A better answer would be: we will get our engineers to reproduce the crash, and fix it. I'm an engineer, send me the source code and I'll fix it. I know it can be fixed.
-
Inappropriate?Hi,
Thanks for your message. That was the recommendation by our techs to fix the issue. I will bring the issue to their attention again and see if they may be able to recommend another solution to your problem.
Best Regards,
Ashley
-
Inappropriate?Len and Akilah,
I thought the same. It supposes to be that way with virtual memory but somehow Windows still fails when Adjust try to allocate. My guess is after a while the memory get so much segmented that the Windows memory manager cannot find some for Adjust.
I tempted to email Microsoft but did not. I probably just waste my time... -
Inappropriate?@Akilah
Ashley, virtual memory can operate well past 2gb
Sure - but on 32bit systems the virtual address space at any time is max 4GB large, regardless how many memory is populated.
2GB out of this 4GB are reserved for the kernel and what is left (minus what is need for hardware, video) have to be shared by all apps.
So there might be not enough RAM left for processing large images, especially when the RAM which is left is not contiguous.
The size of Windows Pagefile (what you call windows virtual memory) is irrelevant, since Windows and PS runs fine without any defined and it isn't used anyway - not even on my 2GB laptop where I can run TA against a 8bit 17500x2500px panorama, but not when its16bit.
Images have to be loaded to and processed in RAM right?
I also believe 4GB pagefile is far to large, usually only ~ 400MB are used / needed. If your computer has a permanent need of a 2GB pagefile, you won't be able to work with it anymore.
Anyway - that's not the point - to solve your prob either reduce image dimensions (resp. merge layers and switch to 8 bit) or go for a 64 bit system.
I know the latter sounds somehow odd, but images will not going to be smaller in future and you'll sooner or later run into this problem also with other apps / plug-ins if you are not willing to work on smaller images. -
Inappropriate?Ablicter,
Just enough knowledge to be dangerous :) As a professional software engineer, I wish to correct a couple of inaccuracies (in general, Topaz Adjust aside):
1) Contiguous memory. Actually, since the memory system in Win32 and Win64 is virtualized, it is always contiguous when allocated.
2) Another feature of virtual memory is that the operating system treats physical RAM and pagefile RAM as the same. When the CPU tries to access an address space that is on the page file, an exception is triggered and it will page it in, all done invisibly to an application.
3) Untouched areas, include most parts of the operating system, will remain paged out until touched. Quite a lot of RAM is always useful. So-called "RAM Optimizers" work by touching a large chunk of memory and forcing stuff to get paged out -- the value of this is dubious. The fact that you see X amount of physical RAM in use is meaningless, as the OS will recover what it needs when it needs it, but often not before.
4) In working with images of this size, no other application or plug-in has a problem. I own Noise Ninja: flawless. Other plug-ins I've tried: flawless. DxO no problem. Every application in existence *BUT* Topaz Adjust works, so my guess that it will be "later" rather than "sooner" I run into any other problems.
The problem looks like a third party library does not play nice with Windows. The problem is software, not hardware. It is ironic that the response to bad software is that I should upgrade my system to 64-bit Windows and add memory -- spend hundreds of dollars to use a $50 plug-in.
I like Topaz Adjust a lot. I admire the ease at which it does what it claims to do. Please just don't insult me my pretending that the real problem is my inadequate hardware or my "ancient" Vista operating system. If it is not something the engineers care to fix, just say that instead.
I’m sad
-
Inappropriate?Akilah,
Thanks for the comments. I can assure you that we will work on it and try to find a better way to address this issue. -
Inappropriate?Albert,
Thank you that is great. I realize some problems are harder to solve. People in my situation may have trouble (e.g., laptop owners, people unwilling to move to 64-bit Windows) accomodating the suggested fix.
The heck of it is, I wouldn't care if I didn't genuinely enjoy using the product :)
-
Inappropriate?Akilah - well better dangerous than clueless :-) Even when being very late, I feel I have to answer this.
I just tried to explain it a bit more simplified so even coder might understand. From a coder I expect he is able to investigate a problem himself and find a solution or workaround to it. I was able to do so - it should be even easier for you ;-) And yepp, I can be bitchy as well.
Since it seems it matters: I'm an IT professional as well - and my experience is that not only normal user are mixing up processor address space with virtual address space and RAM with virtual memory, etc. pp. ;-) Myself might have helped here, by mixing up terms even when I was talking about PS' VAS all the time.
1) You are right, the memory is virtualized and the whole 2GB user mode is allocated at ones from the beginning - but this says nothing about how it is used by an application.
Having 112MB left as largest free chunk available, when still 615MB mem are free after loading 1GB of images... ...hm, sorry - I won't call that much contiguous ;-)
VMMAP shows this clearly
- mind the white rows and the max free large chunk. The whole user mode looks clustered like this from 0000 0000 until FFFE 0000
If you wonder about the "64" in some of the paths you see in the image:this is a 32bit PS running on a 64bit XP. In order to run it within the same boundaries like on a 32bit system (2GB user mode), I had to remove the largeaddressware flag.
2 & 3) VM, OS' page file
Seems what you expect PS shall do, is not what it actually does. The OS is out of the game here in context of buffering / outsourcing to its page file.
AFAIK PS doesn't let the OS handle its VM on 32bit systems for file access. Instead of using OS disk buffers, its I/Os are directly written to disk / scratch.
This is for a reason - Russel Williams, photoshop architect ones explained why:
1. It costs extra to copy the data to and from the buffers instead of just reading it to / from the disk. If you get data from the buffer instead of doing a disk I / O, this is more than worth it, but...
2. Photoshop’s access patterns to its scratch file mostly don’t match what the OS is expecting. The OS assumes that if you just read or wrote it, you’re likely to need it again soon. But that’s not generally the case with Photoshop’s scratch disk.
So the OS' page file almost stays untouched from PS - actually it is very small, not more than 350MB on my 2GB machine - loading an amount of 2GB images and working on them.
Seems the only amount which is paged to OS' VM (if) are the 160MB for the "image" (see the picture) as you coder IMHO calls the exec, loaded plug-ins and DLLs.
On 64bit OS', with 32bit PS and more than 4GB RAM the memory handling is a bit different from this.
Regards, Ablichter.
Visit our Topas Group at Flickr
EMPLOYEE
EMPLOYEE
