Issue reports

Upcoming mother of all image editors

Re: Issue reports

Postby Fluffbutt » Thu Oct 17, 2013 10:40 am

Report: (Win 7 x64, 8G ram)



image size approx 15900 x 9600.

PR memory use (task manager) 6.8 G
PR mem allocation (own reporting) 2.8G

PR shut down 1/3 way into the run after a memory allocation error. Normal windows error message, not a crash.



Image size (same image resized) 7700 x 4800

PR mem use = 2.9G
PR allocated = .710G (710 Mb) - after 180 secs = 1.27G

Completed without errors



Based on the memory allocation change on test 2 I'd say that test 1's crash was due to trying to allocate some 12G of ram (from 6.9G, based on the jump from .710 to 1.27 in test 2)

Not a PR fault, it was trying it's best..
Fluffbutt
 
Posts: 1060
Joined: Sun Apr 24, 2011 3:05 am
Location: No longer here

Re: Issue reports

Postby munki » Thu Oct 17, 2013 3:43 pm

Well I mostly use A3 size at 900dpi at the moment, which is weird I know, but as I posted in another thread that's to keep fine lines separated in print. Then I've got some other files that're anything up to around 100 megapixel.

I get the beeps if I rapidly load the images in either after rendering or if I clicked the wrong image and quickly load a different one, I mean doing this stuff in quick succession a number of times. It seems to me like maybe some swap file is getting emptied and I'm loading more big data in too fast. I don't get the whatever is not responding standard windows message things just get slow for a short time.

The beeps aren't like standard sounds, they're very much like the old skool beeps you'd get back in the day when things were too busy for the soundcard and the computer cried for mercy with the old internal buzzers they had. We don't have such things now but it's that kind of beep if you get me?

You can batter other software in a similar manner so it's nothing too bad, plus PR doesn't crash it just takes a breather then carries on. I can't seem to make it happen at will, it happens from time to time as I'm playing around. I guess also I'm running other apps too so that'd tie up resources. Hmm, messing with PR while waiting for a long 3D render sometimes :oops:

As I'm playing around I'm maybe loading some file with tons of layers in it so the file size could be quite large indeed, I expect PR has to do some flatten process before it gets to work. I mean loading the standard way, not importing a PSD file.

All this being said it takes me by surprise and I haven't had chance to check the resource meter panel, if I did I'd look at the disk access as well as RAM because the standard Windows swap file will be in use and I didn't notice a setting in PR to swap file to one of my other disks like photoshop has. I mean other than the drive with the OS on it.

Either way, if I'm just lazily using PR, tweak - render - tweak - render it never seems to happen. I knew what Rachel meant when she mentioned it earlier though.

All the best,

-andy
munki
 
Posts: 40
Joined: Tue Aug 06, 2013 8:24 pm

Re: Issue reports

Postby munki » Thu Oct 17, 2013 3:47 pm

I wonder if I can bump something I mentioned previously in one of the threads.

Does anyone know if we can jump to DAP and back from PR? I seem to get an instant crash if I try. I have no knowledge of any command line params I'd need to add, and I guess I'd have to be working on a DAP sized image.

I've not had great fun manually, DAP is so random and PR is so not. Seems like it'd be really painterly though in theory.
munki
 
Posts: 40
Joined: Tue Aug 06, 2013 8:24 pm

Re: Issue reports

Postby bil abington, pa » Thu Oct 17, 2013 5:27 pm

Oscar's working on it. I think he has to do a rebuild so it probably won't be available until the new DAP comes out.

munki wrote:I wonder if I can bump something I mentioned previously in one of the threads.

Does anyone know if we can jump to DAP and back from PR? I seem to get an instant crash if I try. I have no knowledge of any command line params I'd need to add, and I guess I'd have to be working on a DAP sized image.

I've not had great fun manually, DAP is so random and PR is so not. Seems like it'd be really painterly though in theory.
Have Fun Bill
Bill Somogyi
bil abington, pa
 
Posts: 461
Joined: Sun Mar 03, 2013 11:26 am

Re: Issue reports

Postby munki » Thu Oct 17, 2013 11:16 pm

Thanks Bill, that's good to know. Been a long time since a DAP update?

I've been having a much better time in PR with my particular style of "painting" effects as it seems I can control things better than in DAP. But the program postworkshop that someone mentioned previously seems to have a DAP like function that seems to drop brush shaped blobs over image areas. It's not as nice as DAP and the other parts of the program that are Node based aren't as nice as PR. I don't have a copy so maybe a practiced user can get a good effect but stuff I've seen looks weak by comparison.

I expect it's doable with the SDK if I had time to look at it. Like the random circles demo but restricted to certain image areas, and DAP style brush shapes instead of circles. DAP seems to work that way I would imagine.

My idea would be to split an image into blocks of colour/texture/luminance in PR and send those parts individually to DAP for brushing, then bring them back into PR for assembly.
munki
 
Posts: 40
Joined: Tue Aug 06, 2013 8:24 pm

Re: Issue reports

Postby Fluffbutt » Fri Oct 18, 2013 7:37 am

munki wrote:
The beeps aren't like standard sounds, they're very much like the old skool beeps you'd get back in the day when things were too busy for the soundcard and the computer cried for mercy with the old internal buzzers they had. We don't have such things now but it's that kind of beep if you get me?
-andy



It might be exactly the same thing - a beep signal from PR saying it's done or ready. That beep gets interrupted (as in "interrupt cycles" in the cpu itself).

Try an experiment - do the same as you did before, but slow down - give PR a chance to clear buffers and reset thing, then drop the next image, wait for it to open in PR (nig images take time to actually open ready for use), and so on.. pauses of 2-5 secs, just for the experiment.

Maybe you're just moving too fast with drag/drop/open/move for things to catch up?
Fluffbutt
 
Posts: 1060
Joined: Sun Apr 24, 2011 3:05 am
Location: No longer here

Re: Issue reports

Postby munki » Fri Oct 18, 2013 5:57 pm

Well this is true of the computer system in general, but the beeps in this case are generated by PR or its processes as they can't be heard if PR is muted.

It's definitely when I'm moving too fast, I just keep thinking it's not too fast for my PC and I wonder if PR isn't allocated as much resource as it could be. Although under your tests it seems to have as much RAM as it wants.

It's not like any other sound PR seems to make usually. It's three deep-ish tones in a chromatic sounding scale.

I was thinking if we talked about things enough perhaps Oscar would comment as presumably he'd know exactly what this audible notification actually means and we wouldn't have to guess like PR is some mystery artifact we're trying to investigate :roll:
munki
 
Posts: 40
Joined: Tue Aug 06, 2013 8:24 pm

Re: Issue reports

Postby andydansby » Fri Oct 18, 2013 11:07 pm

The beeps aren't like standard sounds, they're very much like the old skool beeps you'd get back in the day when things were too busy for the soundcard and the computer cried for mercy with the old internal buzzers they had. We don't have such things now but it's that kind of beep if you get me?
-andy


I believe I know exactly what the beeps are, I hear it every time I code in the SDK and write code that overwhelms Photoreactor and/or Windows. Usually, I do it by pushing to many messageboxes to the screen in repetition, but it could just as easily be done by pushing too many formulas at the same time to your processor. I hear thoses beeps so many time during development, I don't even pay attention to them hardly anymore.

As Photoreactor provides a live update to the screen the math is constantly being pushed to the processor and you processor only can take so much at a time. Which is why I think the beeps are there.

This is of course all related to the complaint being made about the preview screen, which in relative to the actual image is tiny, so I am assuming that larger previews are a bi-linear scaling, which would explain to a degree the complaint bil made about Photoreactor, non accurate preview. I understand the need for a completely accurate preview, but the sheer volume of math being pushed into the processor for a near live update prevents complete accuracy. Photoshop and Paint Shop pro are able to do it because it calculates that sequence of formulas once when you run a filter (for the preview) and just once more when you apply the filter. Photoreactor does this every time the image is re-positioned for you click on the screen.

Andy Dansby
andydansby
 
Posts: 161
Joined: Fri Oct 29, 2010 6:00 am
Location: Syracuse, NY

Re: Issue reports

Postby JEL » Sat Oct 19, 2013 11:56 pm

I'm not using anywhere near those image-sizes myself, so maybe that's why I haven't had any issues with PR like you guys.
DAP (AOPs): http://jelstudio.dk/DAP/
PhotoReactor (flows, effects and scripts): http://jelstudio.dk/PhotoReactor/
JEL
 
Posts: 294
Joined: Fri Jan 06, 2012 9:35 pm

Re: Issue reports

Postby Fluffbutt » Sun Oct 20, 2013 11:14 am

My normal images are 5000 x 4000 or 4000 x 3000 (21 and 12 Mpxl cameras).

Occasionally I might play with a 25 Mpxl fractal.
Fluffbutt
 
Posts: 1060
Joined: Sun Apr 24, 2011 3:05 am
Location: No longer here

PreviousNext

Return to Photo Reactor

Who is online

Users browsing this forum: No registered users and 0 guests