Page 15 of 18

Re: Issue reports

PostPosted: Mon Oct 14, 2013 7:41 am
by JEL
munki wrote:No, doesn't crash for me.

Could you try running PR with administrator privileges? - right-click >> run as administrator. If that does help you can do it always by going into the shortcut properties and you'll find always run as administrator in the compatibility panel if I remember rightly.

Brilliant idea yes, but at present are you not building an archive of flakey jpegs that are unstable and might not load back in? Several bugs IMO including Fluff butt's. Better if Oscar embedded the flow schematic as jpegs in the flow file I think like the jpegs we find in tiff, psd or RAW files. It would be shown as a thumb in Explorer or larger in the PR browser. Proprietary format so no confusion for other apps that handle jpegs.

Apparently it's a difference between win7 and win8 then :)

I don't know if embedding jpegs in .flow files is possible or clever. I'm not sure windows would recognize any images inside a file with a .flow extension. I believe (at least on win7) that would require a permanent driver to be located inside the win-directory, which I personally think is not a good idea. Self-contained software, in my experience, is always more stable than software that gets too mixed into the windows system files.

So far I haven't had any problems loading flows from jpegs. They seem to load as they were in the version of PR they were created in, as Oscar has also explained (you need to update the blocks in old flows when loaded into newer versions of PR (if you actually WANT the flows updated)) This behavior seems to guarantee backward-compatibility :) A flow made in a previous version of PR isn't ruined or changed even if loaded into a new version of PR.
I do personally save .flow files also though. But having the snapshots just makes remembering content much more convenient (well, for me at least :) Of course we all have our personal preferences and work-methods)

Re: Issue reports

PostPosted: Mon Oct 14, 2013 10:31 am
by munki
Well folder permissions was my last guess, must be something deeper as you say. I'll have a go on one of my Win 7s when I get time later. Strange to find win 7 more annoying the win 8 for once :D

A "driver" for explorer to display embedded images as an icon is next to nothing really. If you shoot RAW and your OS is Win 7 then Nikon, Canon or others install theirs along with their proprietary software that comes free with the camera. PR has it's own built-in browser so Oscar can do whatever in there to preview file contents. No matter though, it's not up to me.

Others are having flow snapshot problems, the Fluffbutt one is easily worked around by my method but maybe not by new users if they don't see our forum posts. Still an outstanding issue.

Re: Issue reports

PostPosted: Mon Oct 14, 2013 12:17 pm
by mhwarner
Hi guys,

I have Win 7 x64. I opened PR 1.05, dragged in a main image, added only paintery effect, saved Flow Snapshot. No problems for me. JEL, must be something specific to your machine/setup?

Also, the problem with trying to share .flow files here is that this forum will not allow them as attachments. So you either need to zip them up first or upload them somewhere else and supply a link. These are additional steps that many are not willing to take. It is so much more convenient either attaching the .jpeg or the flow snapshot. Of course, the only trouble with this is that any extraneous files that may be included in the flow which are not part of the PhotoReactor distribution will not be included and you have to play hit-or-miss with substitutions. But then it forces you to experiment a bit.

Re: Issue reports

PostPosted: Mon Oct 14, 2013 8:49 pm
by munki
Yep same here under win7 x64 earlier, but I've reproduced the problem. I am sure this relates to folder permissions. Attempting to save the flow snapshot to a folder without admin privileges causes a crash, C+ runtime error.

Jel, please can you try this?

1. Close PR, open Task Manager and make sure there's no crashed PRs running in the system. Alternatively do this on a fresh reboot of your machine without opening PR at all.

2. Right click your PR shortcut or whatever you normally use to run the program, or the PhotoReactor.exe in your program files/PhotoReactor folder - assuming you installed it to the default location.

3. Go to the Compatibility tab

4. Tick the box marked "Run this program as an administrator" and click OK.

5. Start PR and you should be able to save snapshots without the crash.

Of course you'll need to be an Administrator account on the PC you're using for this to work and you'll need to be starting PR after having changed the run as admin... setting.

I'm back on Win8 at the moment, hopefully I've remembered where the setting is located in Win7, I don't think they changed it between 7 and 8. Maybe Mary can take a look, or I'll have access to win7 again tomorrow. Assuming I described the correct location of the setting panel and you do this it should work for sure.

Folder permissions are usually messed up after running a machine for a few months or are sometimes set a crazy way by the vendor if you didn't build the machine yourself. On Win8 folders like Program Files are restricted by default.

I don't think this is a bug BTW, I think it's a configuration issue on individuals machines, as Mary suggested. I don't know if PR can be updated to do something instead of crashing out though.

Apologies for not just leaving this seemingly redundant topic (posting flow snapshots/.flow files), that I started myself :? but if anyone was interested there's a setting in the forum posting/group permissions to allow other file types. It'd be a job for a mod or forum admin and judging by posts I don't know if anyone wants to upload flow files. If anyone does enable that then maybe enable the V box ones too.

All the best,


Re: Issue reports

PostPosted: Tue Oct 15, 2013 1:06 am
by JEL
munki wrote:A "driver" for explorer to display embedded images as an icon is next to nothing really. If you shoot RAW and your OS is Win 7 then Nikon, Canon or others install theirs along with their proprietary software that comes free with the camera.

I only know Canon and they have a specific download (a codec) you need to install if you want windows to be able to show thumbs for the raw-files. It isn't installed automatically. Having it as a choice is good I think, since there's always the risk that if you have enough of these 'next to nothings' you suddenly have enough to cause trouble. Driver-conflicts is never a fun thing to struggle with, I've had my fair share of those to prefer software NOT putting things into my windows-folder without explicit permission :)

If it could be done as a user-choice I wouldn't mind.

munki wrote:Yep same here under win7 x64 earlier, but I've reproduced the problem. I am sure this relates to folder permissions. Attempting to save the flow snapshot to a folder without admin privileges causes a crash, C+ runtime error.

Why would this problem not exist when saving a render?
And why would the problem go away as soon as a render has been saved once?

While the admin-thing might work (I haven't tried) it's not a viable way to work in my opinion.
Proper software doesn't need admin-privileges, so such a bypass of security isn't an option I would ever recommend so loosely. Software that needs such risky work-arounds is too sloppy to be taken seriously.

And since it's really only a very minor issue, since rendering is obviously the main purpose of PR, it's not a work-around I will begin using myself :)

Re: Issue reports

PostPosted: Tue Oct 15, 2013 2:38 pm
by munki
Hi Jel,

The "drivers" for Canon cameras to connect to the computer are a driver as we use in the common speech, the "drivers" for showing the jpeg embedded into some other file, for example a RAW photo aren't the same type of thing at all. However, in the strictest sense of the word, they are drivers - meaning an intermediate interpreter software.

These things never cause "driver conflicts" as that relates to hardware issues where some device is trying to use the same "port" as another device. I'll bet you've never had a driver conflict while previewing the jpeg thumbnail embedded in a TIFF file.

As Canon, Nikon, Sony et al all use their own proprietary format for RAW files and so Microsoft don't include their stuff in the Windows installation, usually because Microsoft want to develop their own proprietary format that they'd like us to use instead. TIFF files however are not proprietary so Microsoft do include the thing that previews them with Windows. It's nothing more sinister than big companies and their marketing strategies.

PR doesn't need special privileges to work, it works fine for me and Mary as she mentioned earlier. The problem you're having is that folder ownership rights are messed up on your PC and your user account under it's current settings does not impart sufficient permissions to PR when you run it to write the snapshot data. When PR does an actual render some other process is obviously invoked that has higher permissions and that is able to create the file for that.

As I said earlier this is quite common and can often have been put in place by whatever PC vendor a person has that usually uses a custom OEM install of Windows and think they're helping the end-user by making it "better" than the standard install of Windows. And also adding a load of crap HP or Vaio screen savers and wallpaper so we can provide free advertising for them in the office :D

As you'll note from the error you get, it's C+ runtime or whatever PR is made of that is having a problem so any of your "proper software" that uses that particular process would produce the same error on your machine.

If you don't want to run a perfectly harmless software like PR with admin privileges then you could alternatively "Take Ownership" of your own personal folders using the security settings from within Windows explorer which would mean your own user account owns it's own folders as it should. This would also solve the problem.

Running as administrator is also nothing sinister if your user account is an Administrator one. It is simply running it as it should be. On a PC with normal settings we are doing this by default. On your PC it seems you are not.

I'm going to leave this now as I've already shown a workaround for anyone else having problems. If the issue report you raised is not an issue for you then that's cool, just trying to help a fellow PR-ist :D

Re: Issue reports

PostPosted: Wed Oct 16, 2013 3:22 am
by JEL
munki wrote:just trying to help a fellow PR-ist :D

Yes, and I do appreciate that :)

I didn't enter this discussion because the error (the crash when trying to save flow-snapshots before having done a render. Although I still don't understand how I can save them just fine anytime AFTER having done at least a single render) is significant to me (I'm very pleased with how PR works and find it to generally be a very stable piece of software, which in fact allows much more creativity than any other image-editor I've ever used or tried :) I like PR very much, no doubt about it :) ), but just to let Rachel know she isn't the only one getting that type of crash (even if it now turns out we may be talking about 2 different types of errors (as I'm on 64bit I haven't had problems yet with insufficient ram or images being too big for PR to handle, which is more common on 32bit))

Off-topic, but just to round off the discussion:

Drivers, codecs, interpreters, whatever term we use for these bits and pieces, I've had lots of trouble with previews in windows because of conflicts between these 'helpers'. Serious conflicts in fact (locking up the cpu in high load, never releasing it, is what I consider serious in this context)

Also frequent mix-up between which software would handle certain files, such as videos and audio files. Whenever you ran one player it would hijack the file-types, then another player would complain file-types wasn't associated correctly. A lot of annoying back'n'forth like that.

I may just have had bad luck in that regard, but I'm a big fan of the KISS idea and personally don't want software to interfere with my files unless I actually run the main exe file or specifically turn such an automated background-running option on myself.

Anyway, all this is really more about general software behavior than about PR :)

Re: Issue reports

PostPosted: Wed Oct 16, 2013 7:19 am
by Rachel
Thank you, everyone for your help with the clitch. You all are amazing.

Re: Issue reports

PostPosted: Wed Oct 16, 2013 7:42 am
by munki
Jel, it gets worse with win8, they took away the panel that lets us assign edit, open, view etc. from the file types selection. It's now a generic thing that only changes the open command. It's the one thing I hate, well apart from the new start menu that I removed immediately. You have to trawl regedit to restore your preferred settings for file types properly. I still prefer win8 on the whole but file type problems are definitely worse.

I'm using an i7 machine with lots of RAM but large images do cause PR to go unresponsive and emit the beeps. Credit to it, it doesn't break and does complete the process after a bit of time. As mentioned, I have an idea that's it's some internal memory/resource limit rather than the actual computer. It doesn't seem to be using all my actual RAM but it does eat up several GB. Maybe it's hitting the 3GB limit even though it's 64 bit version. I don't know enough to say much about this, leave it to Oscar I guess.

All the best,


Re: Issue reports

PostPosted: Thu Oct 17, 2013 7:24 am
by JEL
munki wrote:I'm using an i7 machine with lots of RAM but large images do cause PR to go unresponsive and emit the beeps.

What size images? I'd like to give that a try and see how it behaves here.

I've worked with 4K (4096 x 2160) images myself (in batch-process mode with over 4,000 being 'reacted' in the same run :) ) and had no indications at all of being anywhere near any kind of ceiling. PR ran that entire process as smooth as one could like :)

'Normal' sized Canon raw images (5760 x 3840) also handle without problem in PR.