ASP Beta 1.1.0.28 - First impressions

[afx]

I'm running FC17 on x86_64 with rpmfusion's NVidia drivers, and from my previous experience you must explicitly install NVidia i686 libs for 32-bit apps.

Using the Nvidia drivers straight from Nvidia and checked the installed files....

Anyway, this is a non-issue since ASP provides its own libOpenCL.

The interesting question is, what else in the system is needed.

Anyway, I've checked if there are unsatisfied dependencies for libOpenCL.so.1.0.0 and there are none. Also, do you have (ugh!) LD_LIBRARY_PATH set?

I do have an AS startup script that has the ldd line uncommented for such checks
That's why I know that AS picks up the Nvidia lib when it does not use it's own.
So all lib dependencies are satisfied.

cheers
afx

[Vinny]

Hi Guys,

I am having problem with the zFrame. The frame disappears when it is being output to jpg.
It anyone having the same problem?

Vinny

Yes.
Seems to screw it up completely.

Also try with ZText enabled but not ZFrame , image is fine but text is missing.

Something for the Monkey I guess.
R.

I have already submitted my monkey report. But one question, is ASP still supporting plugins???
Otherwise, it shouldn't have these problems?

Vinny

[bananahead]

I think this shows the zFrame problem. Told the monkey.

[binoyte]

It never shows up at 100%, it flickers in and out at intermediate zoomsteps and the example below is from fit to window.

Lines.png

cheers
afx

You can see the same grid if you brush large regions in a layer. I forgot to report it to the monkey.

[afx]

But one question, is ASP still supporting plugins???

Why shouldn't it?

Otherwise, it shouldn't have these problems?

Some plugin authors made assumptions that are no longer true...
And, after all, the underlying architecture is undergoing some interesting changes, but the SDK has not been tuned to it. So if plugins currently do not work, I would consider this normal for a beta at this stage.

cheers
afx

[Vinny]

But one question, is ASP still supporting plugins???

Why shouldn't it?

Otherwise, it shouldn't have these problems?

Some plugin authors made assumptions that are no longer true...
And, after all, the underlying architecture is undergoing some interesting changes, but the SDK has not been tuned to it. So if plugins currently do not work, I would consider this normal for a beta at this stage.

cheers
afx

That's a relief! Just have be patience then!

Vinny

[jknights]

I tried the new beta on my iMac (i7 at 2.8 GHz, Radeon 4850, OSX 10.8.2):

There was a slow but clear improvement while scaling up OpenCL support: time per picture went from 4.25 s (No) to 4.15 s (Standard), and then back up to 4.19 s (High).

Problem is: it took ASP 1.0.1.10 only 1.31 s per picture!

Is anyone seeing similar results on OSX?

Yes I am finding on my MacBook Air that 1.1.0.28 is slow and produces very slow Preview builds, 1.0.1.10 is faster.

[Tuvok]

I tried the new beta on my iMac (i7 at 2.8 GHz, Radeon 4850, OSX 10.8.2):

There was a slow but clear improvement while scaling up OpenCL support: time per picture went from 4.25 s (No) to 4.15 s (Standard), and then back up to 4.19 s (High).

Problem is: it took ASP 1.0.1.10 only 1.31 s per picture!

Is anyone seeing similar results on OSX?

Yes I am finding on my MacBook Air that 1.1.0.28 is slow and produces very slow Preview builds, 1.0.1.10 is faster.

Same problem here. The editing is better, no resolution loss while editing, but slower. The change applies for me one or two seconds after the edit. For example, when changing with a slider.

[rlebleu]

I tried the new beta on my iMac (i7 at 2.8 GHz, Radeon 4850, OSX 10.8.2):

There was a slow but clear improvement while scaling up OpenCL support: time per picture went from 4.25 s (No) to 4.15 s (Standard), and then back up to 4.19 s (High).

Problem is: it took ASP 1.0.1.10 only 1.31 s per picture!

Is anyone seeing similar results on OSX?

Yes I am finding on my MacBook Air that 1.1.0.28 is slow and produces very slow Preview builds, 1.0.1.10 is faster.

Same problem here. The editing is better, no resolution loss while editing, but slower. The change applies for me one or two seconds after the edit. For example, when changing with a slider.

I don't think the Macbook Air's graphics card supports OpenCL? There are indications the Intel's HD 3000 does not support OpenCL, and there are questions about the HD 4000 may have difficulties also.

Just to add my experience to this discussion. I tried a test on my late 2011 Macbook Pro (2.2 ghz i7, 8gb ram) with an ATI Radeon HD 6750M dedicated graphics display. It uses the Intel HD 3000 built in the i7 for normal use, but switches to a dedicated graphics display when needed.

I chose 28 Pentax K5 RAW DNG files that ran between 25-32 mb each, and created full size jpgs of them as an exercise.

Here are my results.

No Acceleration 55 seconds
OpenCL on, Low 40 seconds
OpenCL on, STD 23 seconds
OpenCL on, High 25 seconds

I have no idea why the high OpenCL setting fell off in speed??? But less than a second per image is pretty speedy performance in my view.

Dick

[TheDude]

Are you sure this is not because you have the tool's range set too wide?

May be this particular series of images was slightly too challenging for the color correction tool Zooming close to the image and selecting the intended color very carefully worked better.
I tried it in other pictures and it worked better, without selecting that carefully.

Does the reset of a slider by double clicking work fine for you in the cc tool? I can set the slider of any tool to its default value by double clicking. In the cc tool it works sometimes, in most cases it doesn't.

[Dutchmm]

Dude

Your experience with the CC tool explains why I use Sean Puckett's Nuance - it seems to handle the range narrowing pretty well for me.

Double clicking in the CC tool works - only as long as I double click over the control's associated text. But I thought that was true for all controls in AS?

[ogrizzo]

Here are my results.

No Acceleration 55 seconds
OpenCL on, Low 40 seconds
OpenCL on, STD 23 seconds
OpenCL on, High 25 seconds

I have no idea why the high OpenCL setting fell off in speed??? But less than a second per image is pretty speedy performance in my view.

Dick

Can you run the same test on the stable release and post the timing?

Ottavio

[TheDude]

Double clicking in the CC tool works - only as long as I double click over the control's associated text. But I thought that was true for all controls in AS?

funny I used to double click on the knob of the slider. Works for all controls except the cc tool... I never had the idea to click the label, but it works! thanks!

[FalCT60]

Well... I would have been very surprized if I could have noticed any improvement on my old 3GHz Pentium 4
I exported 54 RAW pictures to JPEG 80% - same files, same output - and it took 3.27 s per picture with 1.0.10 against 3.34 s per picture with 1.0.28b.
Doing this test, I could notice something I hadn't so far : the higher the number of files processed, the higher the time it takes for each file.
I.e. : it took only 2.73 s pe file to convert only 4 RAWs to JPEG. Funny.
This apart, it seems stable, though I didn't try to turn it upside down so far.

J.-Luc

[rlebleu]

Here are my results.

No Acceleration 55 seconds
OpenCL on, Low 40 seconds
OpenCL on, STD 23 seconds
OpenCL on, High 25 seconds

I have no idea why the high OpenCL setting fell off in speed??? But less than a second per image is pretty speedy performance in my view.

Dick

Can you run the same test on the stable release and post the timing?

Ottavio

Ha ha! I now see why you asked me to restore the stable release and try this test!

I tried the test with the same 28 images and picked up 3 seconds! i.e.. Stable release converted all 28 images in 20 seconds!

Just in case there was a cache somewhere that was helping out, I chose a different set of 28 images with exactly the same result...

Thanks for the observation Ottavio!

Dick