openCl : pêrformance decrease after few editing
I've noticed that the realtime preview performance in C1 decreases quite quickly after changing a few editing parameters (-like contrast, colour editing).
That means that when I begin editing a "fresh" raw file (with no editing parameters, just the one automatically applied by C1 when a raw file is imported), the preview is quite immediate, i.e. if I adjust contrast for instance, I see the contrast changing on the screen while I move the contrast knob. Quite freely. But after adding a few parameters one on each other (more obvious with parameters light brightness, contrast, colour editing, WB, but not so much with editing like keystone, erspective, rotation), lets say 3-4 parameters edited, then the realtime display of the change and the computers starts to calculate (pixelization, little compute animation running few seconds for small change of editing parameters, zooming, moving in thye zoomed image), wich make the editing pretty tricky.
An other symptom I find difficult to live with : if I use the dust or spot removal tool, each time I add a new one, all the previous one a re-calculated : the spot/dust appears again each time I add a new one and after a whil it takes several seconds to apply the tool for all the spot removal in the same time.
It looks like if C1 recalculated all the editing parameters each time one of them is changed. i.e., let's imagine I have parameter A, B C, D, E already adjusted, if I move the cursor of the new parameter F, for each change of that parameter it recalculates all A, B, C, D, E parameter, and not only the change made by the last parameter F on the top of all previous parameter. That could explain why C1 slows donwn after some editing.
I have a 3930 6 core i7 processor, 32 GB of RAM a HD7950 radeon video card with 3 Go memory, SSD disk for C1, its not a slow machine that runs perfectly with all the software I use except C1 (Photoshop CS6, LR, Bridge for instance).
The solution saying that I need more computing power for openCL is not a valid answer for me, because that would mean that C1 can only work properly on a high end Formula 1 PC.
Is there something I can do to arrange that ? Did you notice the same thing ?
Are there some improvements for openCL use worked on ?
C1 is a really great software but those issues are really a nightmare and are a problem to obtain a welle tuned image in a workflow because finding the correct adjustment of a parameter becomes erratic as each tiny change of a paramter needs a few seconds of editing to show on the screen.
I know that the job that photoshop does is different, but in a huge file (for instance a pano of 4-6 files from P65+ back) it remains immediate preview on the screen, even with multiple editing layers. And on the same file than C1 for similar editing parameters, LR never slows down. C1 yes. MAybe they don't do the same job inside the box, but what is important for the photographer is the free flow of editing to achieve the most precise tuning.
That means that when I begin editing a "fresh" raw file (with no editing parameters, just the one automatically applied by C1 when a raw file is imported), the preview is quite immediate, i.e. if I adjust contrast for instance, I see the contrast changing on the screen while I move the contrast knob. Quite freely. But after adding a few parameters one on each other (more obvious with parameters light brightness, contrast, colour editing, WB, but not so much with editing like keystone, erspective, rotation), lets say 3-4 parameters edited, then the realtime display of the change and the computers starts to calculate (pixelization, little compute animation running few seconds for small change of editing parameters, zooming, moving in thye zoomed image), wich make the editing pretty tricky.
An other symptom I find difficult to live with : if I use the dust or spot removal tool, each time I add a new one, all the previous one a re-calculated : the spot/dust appears again each time I add a new one and after a whil it takes several seconds to apply the tool for all the spot removal in the same time.
It looks like if C1 recalculated all the editing parameters each time one of them is changed. i.e., let's imagine I have parameter A, B C, D, E already adjusted, if I move the cursor of the new parameter F, for each change of that parameter it recalculates all A, B, C, D, E parameter, and not only the change made by the last parameter F on the top of all previous parameter. That could explain why C1 slows donwn after some editing.
I have a 3930 6 core i7 processor, 32 GB of RAM a HD7950 radeon video card with 3 Go memory, SSD disk for C1, its not a slow machine that runs perfectly with all the software I use except C1 (Photoshop CS6, LR, Bridge for instance).
The solution saying that I need more computing power for openCL is not a valid answer for me, because that would mean that C1 can only work properly on a high end Formula 1 PC.
Is there something I can do to arrange that ? Did you notice the same thing ?
Are there some improvements for openCL use worked on ?
C1 is a really great software but those issues are really a nightmare and are a problem to obtain a welle tuned image in a workflow because finding the correct adjustment of a parameter becomes erratic as each tiny change of a paramter needs a few seconds of editing to show on the screen.
I know that the job that photoshop does is different, but in a huge file (for instance a pano of 4-6 files from P65+ back) it remains immediate preview on the screen, even with multiple editing layers. And on the same file than C1 for similar editing parameters, LR never slows down. C1 yes. MAybe they don't do the same job inside the box, but what is important for the photographer is the free flow of editing to achieve the most precise tuning.
0
-
I would prefer to do less editing and get better results ...
In fact a system that was smart enough to understand each image and optimise it with any effort on my part would be just fine.
Some years ago I was using LightRoom V1 and another editing application that was very similar in its operational concepts to C1 from what I can tell. Put the same image into both LR and that other application and ask them to so much the same tasks (remember they took a different design approach so an absolutely identical edit may not have been possible) and the total time for the task was about the same so far as I could tell trying to time the more complex tasks in order to be able to actually measure anything 'on screen'. However, Lightroom looked like it gace an instant response whereas the other application looked much slower.
If you looked at the screen in some detail during the process you could see that LR, in general, delivered a very fast initial view of the change and then worked away in the background refining it a little bit at a time until it was finished. The other application would, depending on what you asked it to do, display very little in terms of changes until it complete all levels of the task and presented its new screen.
As the other application also offered many more facilities for pure editing activities than LR did at the time (and I was not a great fan of being forced to use a catalogue) I eventually dropped LR. For me the extra features were worth more than the appearance of delivering a faster processing time. Running the same software today on a new machine of similar specification to yours (but with the old software limited to 32bit memory handling) it seems very fast. But of course we would expect that. It's not faster than C1 though, as far as I can tell.
It still has many features that are not readily available elsewhere as far as I know. Interestingly I seem to get much the same results and often better results more directly in Capture One without having to do as much editing. That was at C1 V6 level. V7 is better again. Time moves things along I suppose.
If might be useful to run the Windows Performance Monitor (or there are some useful Free Gadgets around) so that you can see what is happening with the processes and maybe see where the time goes.
My thoughts, for what they are worth.
Grant Perkins0 -
Thanks for your answer. You know, for me adjusting contrast, exposure, shadows, highlights, WB, some perspective adjustments doesn't sound like "too much" adjustments.
For instance on a P65+ raw image :
After :
Adjusting horizontallity
Vertical perspective (28mm shot)
Applying lense correction for the P1 28mm
Contrast +13
exposure 0,18
Saturation -16
36 dust removed
Then when adjusting the tint of the red tee shirt on the boy on the picture (tint + clarity + saturation slider) to make it bit more flashy it takes 25 to 30 seconds to have the result on the screen...
And at that point zooming from 0% to 33% takes 6 secoind to display properly the image. Mooving int the 33% zoomed image takes also 6 sec to have a non pxelized picture displayed.
Zooming from 0 to 100% on a "virgin" raw file takes 1-2 sec the first time, almost realtime the next times, but the same zooming factor on the adjusted raw file can take up to 8-10 sec
Then if I leave the image alone and do something else for a fex minutes (for instance surf on the web) the color edition task only takes 1-2 sec wich is much more usable.
Like if when we do several editing task one after each other, the system slows down. And if you leave C1 in background for a fex minutes the system gets "clear" again and behaves properly.
I'm not a specialist att all but use PCs since 1991 for sound and image editing (was using Phoroshop befoir windows 95 was released...), but it really sound like a cache issue. Whenj C1 is in background, cache is flushed and it work better. But I may be wrong.
I don't think that can be considered as "too much editing" ?
You are probably right when you say that LR does the precise job in background, but I think this approach of the computing utilization is far more better in term of edrgonomics than the C1 operates.
And I agree with you when you say that C1 does better in image editing than LR, more precise.
What size of raw file are you adjusting in C1 ? My IIQ are around 35 Mo. And they produce 16 bits tiff of around 300 Mo (not compressed)0 -
Hi there,
The same problems written in the 1st post I'm expecting also. And in a few words, even if I truly love the amazing capabilities of C1 and that's probably because it has much more complex algorithms behind the hood, at the same time it's incredible slow even on even very fast PC's when rendering the image after adjustments being applied. So, if I may ask in the name of all of us I think, can you please optimize the rendering pipeline without affecting the end results provided by the program, or make them even better at the same time? I know that sounds a little bit strange knowing the fact that C1 delivers in my opinion the best results of any other RAW convertor, but it's always room for the better. In fact, this is the main purpose and road of development process in general.0 -
[quote="cristi" wrote:
Hi there,
The same problems written in the 1st post I'm expecting also. And in a few words, even if I truly love the amazing capabilities of C1 and that's probably because it has much more complex algorithms behind the hood, at the same time it's incredible slow even on even very fast PC's when rendering the image after adjustments being applied. So, if I may ask in the name of all of us I think, can you please optimize the rendering pipeline without affecting the end results provided by the program, or make them even better at the same time? I know that sounds a little bit strange knowing the fact that C1 delivers in my opinion the best results of any other RAW convertor, but it's always room for the better. In fact, this is the main purpose and road of development process in general.
Hi cristi,
I think it would be very helpful of we could quantify what we mean by fast, slow or any other description relating to speed.
I don't have PS or a recent LR to compare with. I can compare C1 V7 on a new reasonably high spec 64bit notebook with C1 V6 on an older dual core Win 32 notebook or a Pentium 4 based Win 32bit desktop and, of course, V7 on the new machine with SSD, etc. is a lot speedier. In fact about the same operational speed as my older 32bit application that was not Adobe or Phase.
Yes I can see things processing but even viewing at 100% and applying quite a few edits as I normally do, V7 on this machine is about as fast I could possibly want at the moment, though of course in time I guess it will come to seem slow.
OK, I'm not dealing with the enormous files that a large back will bring to the party - about 26Mb is as far as any of my current stuff goes. But to offset that my activity often means thousands of images shot per day. In fact on a Mb per minute basis I could produce about 180Mb a minute at times - so plenty to go at if we were measuring productivity by, say, MB per minute of throughput.
Maybe I'm lucky with this machine, I don't know, but even the very slowest change when there is obviously soe other process influencing what the computer is doing has never exceeded 3 or 4 seconds. And that is extremely rare. Mostly I would say the changes, and despite my earlier post I do make a lot though not often WB or colour, take between 1/2 and 1 second to fully re-render. A little longer if I have a very detailed file to process, perhaps. I don't find that too bad. My eyes take longer than that to focus! Maybe this is an age thing? 😂
So I have a recent (but not latest spec) i7, Win 64 Pro, a 512SSD. 1920px screen and inbuilt Intel HD4000 graphics or OpenCL via a lowly Quadra K1000M GPU that is unlikely to get very busy in the current iteration of V7 the way I use it.
I had 8Gb of RAM and that seemed fine. I now have 24Gb (mainly for testing some other software unrelated to photo editing in any way) and I have yet to see the system using more than 14Gb in total. Right now I am running 2 seesions and a catalogue in C1, an instance of another editor (32bit) and Firefox with a load of tabs open and the performance monitor is showing just under 9300Mb RAM used and just under 15Gb free.
As part of the application testing I am doing I have turned off Hyperthreading so the CPU is only using the 4 primary cores and it seems to make very little difference for most activities. "Processing" is the one situation where I can see C1 hitting all the available cores very hard for more than a few tenths of a second but even then for a single file the time difference is not the end of the world. For a batch it might make a big difference - and of course continuing with other activities while processing is a further challenge.
So, am I very lucky that I have a system that seems to perform extremely well, by my estimate, leaving me unable to understand the problems others are having? Or are my abilities for processing at speed (and therefore my expectations of how quickly something should be happening) so much slower than everyone else that I just cannot properly understand the problem?
I really don't know. I wish I did.
I have little doubt that performance can be optimised over time and we would expect that to happen of course. But do we already have unexplained performance differences that may exist for reasons that will not be addressed by any code or database tuning that can be identified? Things like virus checking systems for example, or maybe indexing systems.
If anything like that is influencing performance on a machine by machine bases we might guess that nothing much by way of tuning the code or database will have a big effect whereas maybe changing a virus checker might!
Speculation of course but if you look at a list of programs running ion a machine not many of them or obviously and clearly related to the primary applications and any one of those MIGHT have some interesting side effects.
So, am I lucky with my system's performance or are my personal expectations set much lower than most?
Looking forward to any replies.
Grant Perkins
Grant Perkins0 -
[quote="NNN634863802867218057" wrote:
Thanks for your answer. You know, for me adjusting contrast, exposure, shadows, highlights, WB, some perspective adjustments doesn't sound like "too much" adjustments.
For instance on a P65+ raw image :
After :
Adjusting horizontallity
Vertical perspective (28mm shot)
Applying lense correction for the P1 28mm
Contrast +13
exposure 0,18
Saturation -16
36 dust removed
Then when adjusting the tint of the red tee shirt on the boy on the picture (tint + clarity + saturation slider) to make it bit more flashy it takes 25 to 30 seconds to have the result on the screen...
And at that point zooming from 0% to 33% takes 6 secoind to display properly the image. Mooving int the 33% zoomed image takes also 6 sec to have a non pxelized picture displayed.
Zooming from 0 to 100% on a "virgin" raw file takes 1-2 sec the first time, almost realtime the next times, but the same zooming factor on the adjusted raw file can take up to 8-10 sec
Then if I leave the image alone and do something else for a fex minutes (for instance surf on the web) the color edition task only takes 1-2 sec wich is much more usable.
Like if when we do several editing task one after each other, the system slows down. And if you leave C1 in background for a fex minutes the system gets "clear" again and behaves properly.
I'm not a specialist att all but use PCs since 1991 for sound and image editing (was using Phoroshop befoir windows 95 was released...), but it really sound like a cache issue. Whenj C1 is in background, cache is flushed and it work better. But I may be wrong.
I don't think that can be considered as "too much editing" ?
You are probably right when you say that LR does the precise job in background, but I think this approach of the computing utilization is far more better in term of edrgonomics than the C1 operates.
And I agree with you when you say that C1 does better in image editing than LR, more precise.
What size of raw file are you adjusting in C1 ? My IIQ are around 35 Mo. And they produce 16 bits tiff of around 300 Mo (not compressed)
Hi,
I don't thank that is too much editing, although to have a system guess what your preferences are and take the image there with no intervention would be really cool. 😎 Maybe one day .... perhaps just speak the changes?
I do much the same - though maybe not the dust spots and perhaps less changes of colour usually. But even when I change colours the results are nowhere near that long in processing. OK, smaller files and I guess less detail at all levels including colour renditions but even so I would be very surpised if anything took that long. Even V6 on my older poverty hardware and working under pressure with only 2GB total memory available would not have taken that long.
I may have a few downloaded sample files of a similar size - perhaps even some older Phase files from a Luminous Landscape tutorial a few years back. Fairly sure they are not P65+ files though.
I'll see what I can find. As you may gather from my response to cristi this is an area of interest to me for wider reasons than just photo editing and some performance differences I see reported on what appear to be very similar systems just don't make sense. It would be good to understand a little more about the subject. (or maybe not ... but that is a different discussion!)
If you have a sample file that you could share for testing I would be quite happy to run it on my system and take some timings if you think that could be useful.
Grant Perkins
PS. A thought. I have not yet tried running with dual monitors. Do you run Dual screens? If so - from the same GPU?
I run 2 screens from a single card on my lowly old desktop (C1 V6) and although I was not very aware of any performance issues the GPU would get very confused from time to time, often around the time of a driver update. Hoever it sounds like your problems as something else.0 -
Hi
Thanx for your answer. Yes I have a dual screen system 22" and 24" eizo connected tothe same graphic card.
Of course I can send you a sample file. If you give me your email...0 -
[quote="NNN634863802867218057" wrote:
Hi
Thanx for your answer. Yes I have a dual screen system 22" and 24" eizo connected tothe same graphic card.
Of course I can send you a sample file. If you give me your email...
What happens if, as an experiment, you disconnect one of the monitors? (Or rather run with only one of the monitors but try each one in turn.)
I think it could be useful to try that even if only with a view to elimination of the monitors as potential sources of problems. Hopefully it would not be a very disruptive thing to try.
How big are your files - I'm thing an EIP file would make sense - RAW file and edits.
If it's very large I should check the mail system will handle it. If not I have an alternative approach to suggest.
Grant Perkins0 -
[quote="SFA" wrote:
[quote="cristi" wrote:
Hi there,
think it would be very helpful of we could quantify what we mean by fast, slow or any other description relating to speed.
Grant Perkins
That means that for instance if you adjust contrast you see contrast changing on the screen when you move the slider, not one fraction of second or more after, because in such a case you stop moving the slider too late and your adjustment is not precise. That also mean that when you move a slider it displays on the screen with fluidity, like when you set the volume of your hifi system : What You Do Is What You See (WYDIWYS...). And also it means that the display shows fluid variations and not in na jerky way (I mean that the variation on the display is not progressive but shows some "notches").
Very simple.0 -
[quote="SFA" wrote:
[quote="NNN634863802867218057" wrote:
Hi
How big are your files - I'm thing an EIP file would make sense - RAW file and edits.
Grant Perkins
About 55 Mo0 -
[quote="NNN634863802867218057" wrote:
[quote="SFA" wrote:
[quote="cristi" wrote:
Hi there,
think it would be very helpful of we could quantify what we mean by fast, slow or any other description relating to speed.
Grant Perkins
That means that for instance if you adjust contrast you see contrast changing on the screen when you move the slider, not one fraction of second or more after, because in such a case you stop moving the slider too late and your adjustment is not precise. That also mean that when you move a slider it displays on the screen with fluidity, like when you set the volume of your hifi system : What You Do Is What You See (WYDIWYS...). And also it means that the display shows fluid variations and not in na jerky way (I mean that the variation on the display is not progressive but shows some "notches").
Very simple.
OK.
So using a downloaded 1DX file and displaying at 100% if I click directly to add, say, 2 stops the main viewing screen change is instant. The preview update follows half a second later.
Working with the slider of the Contrast adjustment using the touchpad or other inbuilt notebook pointing device, the presentation varies according to the speed of movement. If I use fast, coarse adjustments an initial immediate display change is deferred until I stop somewhere. Medium speed changes of position result in almost instantaneous changes on screen. Slow speed fine adjustments look instantaneous to me.
I expect it should be possible to obtain even better results with a quality input device that offers better resolution fine movement control.
Grant Perkins0 -
[quote="NNN634863802867218057" wrote:
[quote="SFA" wrote:
[quote="NNN634863802867218057" wrote:
Hi
How big are your files - I'm thing an EIP file would make sense - RAW file and edits.
Grant Perkins
About 55 Mo
I think 55Mb as an attachment might defeat the mail system but if you wish to try it go ahead and we will see what happens.
If it fails I will set up a secure access to download to my site - but I will need an email address to send the details.
Grant Perkins0 -
[quote="NNN634863802867218057" wrote:
[quote="SFA" wrote:
[quote="cristi" wrote:
Hi there,
think it would be very helpful of we could quantify what we mean by fast, slow or any other description relating to speed.
Grant Perkins
That means that for instance if you adjust contrast you see contrast changing on the screen when you move the slider, not one fraction of second or more after, because in such a case you stop moving the slider too late and your adjustment is not precise. That also mean that when you move a slider it displays on the screen with fluidity, like when you set the volume of your hifi system : What You Do Is What You See (WYDIWYS...). And also it means that the display shows fluid variations and not in na jerky way (I mean that the variation on the display is not progressive but shows some "notches").
Very simple.
Indeed, what I wanna experience is instantaneous, fluid response when I dynamically move the slider, not typing a number, or using the shift key and un/down arrow keys. I wanna use the mouse and I want the changes to be displayed without any delay what so ever preferably. This is the only way to see exactly where do you need to stop according to your own taste. I have an i7-3770K OC'ed to 4,4Ghz and HT enabled, 16 GB RAM, Radeon 7850 Power Edition from MSI, already OC'ed pretty good, not SSD, but a very fast HDD and still, even with 10MP files, about 15-17 MB max files, I don't have fluidity. All 8 threads of my CPU when I start moving the slider goes up to 100% or fluctuates between 95-100% and still it's not fast enough rendering the preview real time. Real time means practically 0 delay. Some folks may say about SSD vs HDD, but this counts I believe when you first access your file from the thumbnail panel, getting ready the catalog and other things that involves the SSD/HDD, but when you already select your image, that image is moved uncompressed in the RAM. You're working with the RAM at that point. RAM is fast, everything is fast, but still no real time. I could understand maybe a small delay (not even 10 sec ones) on 25-45MP or larger files, but for 10,1MP files on my system, I was hoping for instant rendering, not in steps and I could bet that even on 3930K is not rendering with practically 0 delay. If not the latest CPU's out there could handle C1, then what? 10 i7 CPU's on the same board? Doesn't exists, and 2nd, I don't think someone would be able to invest that much. That's why, I will ask again the PhaseOne Crew, in the nicest way possible, please optimize the rendering pipeline without affecting the output quality.0 -
Thanks, your english is far more better than my frenchglish to expressed that viewpoint. I've been speaking with mac users who do not seem to have those performance problems. Obviously, C1 PC world is not optimized as C1 macworld is. Same optimization issues when you shoot tethered from a laptop PC.
Image quality is the best of all raw editor I used, but thisperformance issue is really a major point that make the difference between using professionnaly or not.0 -
[quote="NNN634863802867218057" wrote:
Thanks, your english is far more better than my frenchglish to expressed that viewpoint. I've been speaking with mac users who do not seem to have those performance problems. Obviously, C1 PC world is not optimized as C1 macworld is. Same optimization issues when you shoot tethered from a laptop PC.
Image quality is the best of all raw editor I used, but thisperformance issue is really a major point that make the difference between using professionnaly or not.
Based on what I see on my PC and what I read in the Mac parts of the forum it seems that we PV userrs get just as good a deal and perhaps much better.
But the reality is really that both systems have plenty of potential for invisible complexity that is the final responsibility of no-one in the supply chain of components, software and hardware. So some people will have no problems, some will have huge problems and a group in the middle will not be certain whether they have problems or not.
That's technology as it exists in the modern world.
Grant Perkins0 -
So you mean my PC can't handle correctly C1...
I don't think this explanation is correct and what will happen (because I can see lots posts similar to mine on other forums) is that if the majority has problems with performance, they will switch to Lightroom who is able to display instant preview.
I think the best attitude to have (it is mine when I'm confronted to similar problems) is to say : "others can do it so I can do instead of saying : "we are perfect, your system is responsible and we won't consider to improve"...0 -
[quote="NNN634863802867218057" wrote:
36 dust removed
Dust removal is not yet support by the OpenCL engine. So this is the reason why you see a performance difference.0 -
[quote="NNN634863802867218057" wrote:
So you mean my PC can't handle correctly C1...
I don't think this explanation is correct and what will happen (because I can see lots posts similar to mine on other forums) is that if the majority has problems with performance, they will switch to Lightroom who is able to display instant preview.
I think the best attitude to have (it is mine when I'm confronted to similar problems) is to say : "others can do it so I can do instead of saying : "we are perfect, your system is responsible and we won't consider to improve"...
Or when other do not seem to have the problems to the same extent wonder if there is some other unidentified factor involved.
A few days ago I was using Windows Media Player to browse a folder of small jpg files. 2 month old machine, fully up to date with Win 7. Suddenly Media player presented me with a "COM Surrogate" error. Ever since this error (and failure of Windows Media Player) has appeared randomly each time I run Media Player.
I can think of no explanation for that. Media Player is not a brand new program. The problem is reported widely on the internet going back some years. There are probably 1000 "certain" solutions. Microsoft Windows Media Player for heavens sake. What chance does any other developer stand?
Of course to be able to work around a problem you first have to be either very lucky and find a 'fix' without really understaninding what is going on; know someone who already has an answer, or; gather as much information as you can form as many sources as possible in order to try to work out where the problem and things that influence it can be found. This can take time, as you know. With so many variables involved it might take a very long time or, worst case, cannot be fixed without working out how to do something completely differently. To do that comes with different risks. Yet still no guarantees that the proposed solution will work in every possible case. Nor any guarantees that others whose products you interoperate with are not going to introduce some new challenges with whatever they do next.
These are industrywide problems. To have such problems is not a new situation. But for certain core products any problems created may require a lot of effort by a lot of people to rectify a simple error from earlier in the chain by someone far away form the eventual end user.
It's not easy, in my opinion.
Grant Perkins0 -
I understand. My only concern is that C1 is the only program on my system with such an issues. Other softwares using also openCL work perfectly, even no matter the drver version I use on my video card. 0 -
[quote="NNN634863802867218057" wrote:
I understand. My only concern is that C1 is the only program on my system with such an issues. Other softwares using also openCL work perfectly, even no matter the drver version I use on my video card.
Well, I was not thinking specifically of OpenCL.
But what do you mean by "Work Perfectly"?
Make good and testable use of OpenCL and provide a measurable performance improvement?
Or just that they don't generate errors?
Or something else?
If it is measurable performance, what are you using to measure it?
I am interested to know for some testing I am doing for some business software - nothing in anyway related to image processing or Capture One I should add. The only common ground would seem to be the of an SQL database and the development, as happened from C1 V6 to C1 V7, being forced to change all of the underlying "engine" technology in order to move the product to the platforms for the next level of development.
Of course it would also be useful to make comparisons between the performance of systems in general.
I don't think my low spec card is making much effect on performance. In any case I also tend to use edits that are not currently supported for OpenCL so most of the load is in the CPU.
The system still seems quick to me and it peaks on memory usage yet displays no obvious slow down for editing even after several hundred files. Large batch outputs also work well. Maybe too well - I'm running out of disk space on the primary drive!
So, some people sems to have a lot of problems on their PCs. Others, like me, hardly any at all. For me one damaged cos file last weekend. Strange deadlocks in processes in one session until I figured out the problem and resolved it.
It's the same in the Mac forum threads. Some people with huge problems. Others stating they have no problems at all.
You can read Forums for other manufacturers and see a similar pattern. (It does not have to be photo editing either.)
By the way, did you try to mail me a file yet? I have not seen anything in my mail.
Grant Perkins0 -
I don't follow your thought. You mean that if you didn't make measurement with some perticfular tools, or do a full study of all system configuration available on the planet with all available software in the world you can't say : " there is a problem because it is too slow to display the changes when I move a slider" ? And to say all software I use on my system behave correctly so it is the simplest explanation to say that the software that do not behave correctly has some issues ?
And if you follow the law of Okham (don't know the precfise name of it in english), the simplest explanation has the biggest probablity to be the right one. E=MC2 isn't it very simple ?
No I didn't send a file yet.0 -
Hmm.
From my point of view ...
C1 V7.1.1 works perfectly on my system (or at least perfectly enough for my purposes and the features and functions I use so that I have no complaints.)
Some other software installed does seem to have a few problems, so my system, in total, is not perfect. No system is.
The question is how can we compare our views of Perfect?
If nothing crashes - is that perfect?
Or should it be that nothing crashes and everything just works instantly?
Is .5 of a second (for an example) too long for a response thus making the application imperfect? For some, maybe, for others not at all. You could substitute different numbers and still have a range of results and subjective user experiences. The challenge is to find standards that can be agreed upon and methods of measurement that are consistent. (Whether they are accurate is a different matter - we can start with consistency.)
In theory, yes you would have to build a system that could deal with every possible combination of hardware fabrication and lines of code for it to be guaranteed to work perfectly in every possible installation. Of course that is impractical for many reasons, not least that the target moves daily. Even the Apple software control systems do not seem able to get close to that degree of success.
What I would like to find is a good perfomence monitor tool that tells me what is processing and how much it is processing and which facilities, like OpenCL for example, are actually being used. Phase One have provided information about which parts of Capture One can currently use OpenCL capability and which process do not.
Quantifying the benefit of using OpenCL seems to be more challenging.
The GPU card in my system is not very powerful and the GPU monitor I have does not register much activity. (Less after a recent driver update even though I rolled that back.)
I would like to know more. It does not seem to matter much, OpenCL on or Off the subjective performance of the system is not clearly measurably faster upon visual observation. But then maybe that is beacuse the speed is good anyway.
It's the same with Hyperthreading. It seems that having Hyperthreading on or off at the system level makes little if any difference to the speed of the process. Or more specifically the speed of a single application. In fact some people think that many applications (or parts of them) perform better without hyperthreading enabled. (That is a general observation, not a specific comment about Capture One.)
There are even those who think that, for some processes, Mulitcore use of the processor is not the way to go.
Modern systems are most often designed with the intention of running multiple applications in light usage mode and side by side rather than a single application intensively. There are compromises in place. The effects of the compromises may vary system to system.
So, with all of these things (and more) in mind we discover that some users have many problems and some have no problems even when using the same release of software on what are, in theory, almost identical environments. How is that possible?
Well, to find out you have to do the diagnosis of that the differences are in order to understand how to eliminate the problem if it is possible to do so.
Fixing someone elses code problem may be possble in most cases but there is always a good chance that a problem will recur when the poor code is itself "fixed" by the supplier. Or maybe you code around the feature and don't use it (because it does not work) but then are unable to make use of it later (when it does work).
End user product developers coding around the problems of core product development tool providers seems to be a common situation today.
In Summary.
Using the same code some people see big problems others so no problems at all
How can any problems that some people experience be solely the fault of the application code and not influenced by anything else in the environment in which the code exists?
Finding the answer to that should be interesting but perhaps not what we want to be doing as photographers with camera shutters to exercise!
My further thoughts, for what they are worth.
Grant Perkins0 -
Another thing I noticed :
I've been doing some "batch" processing, I.E. copying white balance dust removal, croping, horizontality from pictures to many other ones (copying dust removal could take long time because dust removal is not handled by openCL but that is not the problem).
Then I decided to select another image (wich already had white balnce + croping settings), it took maybe 15 sec to have that image correctly displaid on the screen (from pixelized to clear image).
Then I closed C1 and reopened it, then I reselected the previous image and it took les than 1 sec to have it displaid correctly.
So... I keep on thinking that there is something not optimized on memory or ressource management. And I'm not gonna test this on billions of computers with thousand of softwares to say it !0
Post ist für Kommentare geschlossen.
Kommentare
22 Kommentare