メインコンテンツへスキップ

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

How to generate previews

Clive102
I'm coming back to C1 again after not using it for many years (v3 was my last version that I regularly used) but it has also now brought up a couple of problem I'd appreciate some help with:

1) How do I get C1 to generate the previews.

I seem to remember that when I used to point C1 to a directory I had to leave it quite some time to generate all the high res. previews ("proxies"?) then it'd fly through the editing. Now when I point C1 to a directory the images quickly load after a few seconds then nothing seems to happen. When I go to edit a particular file, C1 will hesitate a few seconds before the keys respond, as if it's now generating a high res. preview afterwhich all my adjustment can be quickly applied. Then when I go to the next image, the same hesitation happens. But if I return to the previous image, I can fly through my edits. So is there a way to get all the high res. previews to load first so I can fly through my edits from the start?

2) When copying and pasting a horizontal crop to a set of images, if there a few vertical images included, is there a way to get the horizontal crop to be applied vertically to the upright images, as is done in Lightroom?
0

コメント

8件のコメント

日付 投票
  • Permanently deleted user
    Can't help you with your second question but as far as generating proxies it already is. The delay you are seeing is just how slow C1 has become. If you haven't used it since v3 you will notice that v6 has a significant delay when selecting an image. Phase One deems this as not a problem.
    0
  • Clive102
    Thanks Dan for your reply.
    Any idea why when I return to the same image later there's no delay, almost as if once a high(er) res. image has been generated I can select and edit in real time?
    0
  • Permanently deleted user
    Wish I did. I noticed this behaviour during beta testing v6 and reported it to PhaseOne. Tech support told me it is because it is doing more than v5, i don't buy that but it has not gotten any better.
    0
  • Keith Reeder
    [quote="Clive102" wrote:
    Thanks Dan for your reply.
    Any idea why when I return to the same image later there's no delay, almost as if once a high(er) res. image has been generated I can select and edit in real time?

    Once the proxy is built, there should be no lag - it's only during the initial (one-off, if you don't delete them) proxy building stage that you should see any delay.

    It's still a pain in the butt, though.
    0
  • Permanently deleted user
    While I agree there should be no lag i see 5-30 sec lag on each file. I even sent a video to Phase One showing the delay, they said it was normal. Even added more RAM (12 total) and a SSD and no improvement.
    0
  • Keith Reeder
    Hmmmm...

    Despite what Phase One says about it, that doesn't sound normal or acceptable to me.

    Once my proxies are built, moving around within Capture One is pretty much instantaneous in my experience - this is with Canon 7D files, and I can jump from one image to another with no observable delay whatsoever.

    And this is with "only" 8 gb of RAM on a Win 7 64 bit machine, and a traditional spinning hard drive.

    What camera is this, Dan? And out of idle curiosity, is this Capture One Pro or Express? I use Express (I don't really need most of Pro's extras - I have Photoshop for that) and it's really snappy and responsive.
    0
  • Jim MSP
    [quote="Keith Reeder" wrote:
    Hmmmm...

    ...

    Once my proxies are built, moving around within Capture One is pretty much instantaneous in my experience - this is with Canon 7D files, and I can jump from one image to another with no observable delay whatsoever.

    And this is with "only" 8 gb of RAM on a Win 7 64 bit machine, and a traditional spinning hard drive.

    What camera is this, Dan? And out of idle curiosity, is this Capture One Pro or Express? I use Express...and it's really snappy and responsive.


    I have the same experience as Keith does - with a Canon 60D, Win Pro on a similar pc, and CO Pro. Once CO has generated proxies for all the files, I can move rapidly from one shot to the next. However the new Lightroom 4.1 still has a couple of sec delay between the same files in the same folder.
    0
  • SFA
    [quote="Keith Reeder" wrote:
    Hmmmm...

    Despite what Phase One says about it, that doesn't sound normal or acceptable to me.

    Once my proxies are built, moving around within Capture One is pretty much instantaneous in my experience - this is with Canon 7D files, and I can jump from one image to another with no observable delay whatsoever.

    And this is with "only" 8 gb of RAM on a Win 7 64 bit machine, and a traditional spinning hard drive.

    What camera is this, Dan? And out of idle curiosity, is this Capture One Pro or Express? I use Express (I don't really need most of Pro's extras - I have Photoshop for that) and it's really snappy and responsive.



    I would love to understand what is going on at each step of my processing in order to rationalise why things take time - but then I have always felt that no matter which package I was using at the time. Adobe seem to be pretty smart at making the processing look more responsive than perhaps it is. Back in LR 1 days I compared the total elapsed time to perform certain types of eqivalent 'actions' between LR and another editor I used at the time (similar to C1 rather than anything like PS). Whilst LR looked more responsive on screen in fact the total times were very similar with no clear consistent leader.

    There is a heck of a lot of processing going on for many of the activities in the editors - some being more comprehensive than others in their reach within the data. Working with the the default proxy image size and moving betweenimages you would expect to be pretty quick. But if you are, say, running your screen resolution at a different size to the proxy default - what then? The application will either have to rescale the proxy from the underlying data, add adjustments and then display or simply take the proxy and enlarge it just as, for example, Windows Image Viewer would do with a jpg file. The apparant speed of some Photo Browsing packages seems to work on exactly that basis with rapid discards or interpolation used to present quickly without too much care for quality at that stage.

    Nothing wrong with that if one is happy with it and it's 'fit for the purpose'. But for editing purposes it is not necessarily informing people about what is really going on.

    Larger files, more tools and smarter calcualtions may all take their toll on any additional processing power available. However in recent times the rush to ever more powerful processoers has changed somewhat. The desktop objective used to be single process working for processes that were linear calculations. Recently that has changed to multi-core processors and the objective of supporting multiple processing running in parallel on the machine. Fine for running several apps but not necessarily so good for tasks that are not naturally adaptable to be split across multiple processor cores.

    Knowing where the processing challenges are might help people to decide exactly how to fine tune their workflow to obtain best speed where speed is important, or quality when needed and only when really needed if processing times are likely to be seen as unaccaptably long. Anything that provided guidance about such matter would be very useful, in my opinion.

    However I suspect that there are so many grey areas about what affects what that to put it all in writing may be to invite long and extended criticism from all directions! General guidance will rarely cover all possible angles of a subject and often leads to unrealistically detailed discussions of very specific requirements. Something probably best avoided on a very public forum where it would serve no benefit to anyone.

    My thoughts, for what they are worth.


    Grant Perkins
    0

投稿コメントは受け付けていません。