Idea for Developed previews

(4 posts)
  • Marc Sabatella
    Moderator

    Some thinking aloud:

    Although I've complained about the location of the developed folder, I have to say, I do love how fast 3.0 is now that it always generates these previews and keeps them around "forever".  The old cache system rarely worked very well - in fact, I suspect it was hopelessly broken; it seemed my previews were *constantly* being regenerated when I asked for full screen views).

    Anyhow, it's the classic time/space tradeoff.  Images generally stay in my "working folders" for a few days, during which time, I *love* having *all* the previews there for my developed images (and am fine with the embedded previews for the undeveloped images).  It's basically the point at which I'm ready to archive the working images that I'd be prepared to delete the previews.  So come to think of it, I might be OK with just an explicit command to do exactly that.  As opposed to temporarily enabling display of hidden files, deleting the Developed folder, then turn off the hidden files again because I normally don't want them.  Although I suppose that in the folders I actually viww, it's normally just this and Originals, so I suppose I could leave hidden files visible without bothering me *too* much.

    Of course, right now there are issues with simply deleting the Develop folder - ACDSee doesn't like it when I do something that breaks the association between images and their previews, as I reported elsewhere (and Mark acknowledged as a known issue).  So for that reason too, I'd prefer a dedicated "clean up previews" command that made sure ACDSee behaved sensibly if its too much trouble to guarantee sensible behavior when I actually delete the files.

    Now, here's another thought:

    Instead of simply deleting the previews, I'll tell you what I *really* want in addition.  I want a reduced resolution version (full screen only, say) generated and moved off to a centralized cache that ACDSee can then manage however it sees fit.  It could be generated directly from the existing previews, or from the camera-embedded previews in the case of undeveloped images.  That would be a very fast operation (although still idelly done in the background like regular preview generation).

    Now, how cool would that be?  100% previews that are available instantly for as long as you want to dedicate the space for them, then at the press of a button, have that space cleared up but have screen-sized previews available for "most" of your"recently" accessed files as determined by the cache system.  Shoot, give me an option to choose the size & quality of the preview, and an option keep them around "forever" (eg, an cache that potentially grows without bounds) and you've got what I do right now as an explicit separate step: generating lower resolution JPEG "proofs" of my images.  Except as it is now, I have to manage these and their connection to the originals myself (eg, when looking at a proof, if I want to access the original, I need to perform handstands to find it, plus metadata changes to one don't affect the other, etc). I'd trade that for what I've just described above in an instant.

    Posted On June 4, 2009 - 07:40 PM (5 months ago) (Permalink to this post)
  • I've just about decided that I like the developed folder and it's link to the RAW file formats, and it's location. I haven't been in the habbit of createing (exporting) developed versions of my adjusted files except when I had a use for the jpeg version, which I know is contrary to the prevailing DAM workflow.  I've been considering changing that habbit. With the developed jpeg created when you use the process module or if you create RAW preview files on import these may become my 'derivatives'. Since they are linked to the original file any updates I do automatically updates my deriviative. The location directly below my original folder location certainly makes backing up easy (again - retracting my initial comments about that subject). I'm willing to adapt my workflow to accomodate software when it makes sense. Your idea has merits as well and I could adapt to that arrangement also. 

    I have not reached the same conclusion about the treatment of jpegs (as the original file). I don't like the fact that the original file is moved into a hidden folder without so much as a "by your leave". Since I'm predominantly a RAW shooter this isn't as big a deal for me as it might be for others. I don't see why they can't leave the jpeg in the orginal folder and simply display a developed version if it exists just like the RAW formats.

    Posted On June 4, 2009 - 11:30 PM (5 months ago) (Permalink to this post)
  • Marc Sabatella
    Moderator

    Michael said:

    I haven't been in the habbit of createing (exporting) developed versions of my adjusted files except when I had a use for the jpeg version, which I know is contrary to the prevailing DAM workflow.

    Actually, I don't think that is contrary - I think most would recommend only generating JPEGs as necessary.  I'm probably unusual in generating as many "proofs" as I do.

    Although I'd probably still like an option to put the Developed folders somewhere central, and ideally cacheable, I'm warming to my idea here of leaving it as it is but providing an easy cleanup method.

    I have not reached the same conclusion about the treatment of jpegs (as the original file). I don't like the fact that the original file is moved into a hidden folder without so much as a "by your leave". Since I'm predominantly a RAW shooter this isn't as big a deal for me as it might be for others. I don't see why they can't leave the jpeg in the orginal folder and simply display a developed version if it exists just like the RAW formats.

    I think the idea is that if you are shooting JPEG, you are likely to expect your processing to be visible outside of ACDSee.  Other programs do it the other way, and it seems many users users express confusion over the need to do an explicit "export" to make their changes visible elsewhere.  I personally think the way ACDSee is doing it makes more sense.

    Posted On June 5, 2009 - 05:50 AM (5 months ago) (Permalink to this post)
  • Marc Sabatella said:

    I think the idea is that if you are shooting JPEG, you are likely to expect your processing to be visible outside of ACDSee.  Other programs do it the other way, and it seems many users users express confusion over the need to do an explicit "export" to make their changes visible elsewhere.  I personally think the way ACDSee is doing it makes more sense.

    I see your point but I guess I see the two approaches as inconsistant - I don't expect any other program to be able to see my RAW edits (one could wish), and this is one point that I most certainly do agree with from the "The DAM Book" in that there are no differences between the RAW formats or jpegs from the camera - both should be teated as an untouchable entity. I know ACDSee's approach honors the spirit of that thought - the approach that Adobe and Bibble takes simply writes info somewhere (side file or db) and leaves the file alone. ACDSee is almost doing the exact same thing with the xmp files in the original folder - with of cource the differnece being what we have been discussing.

    I just had a question come to mind - during the file manipulations - moving the original, creating the developed copy - I would hope that the program is doing it in a safe way - that is - copy the original, confirm that it's a valid copy, and only then overwirte the original location with the developed version. I would hate to loose a photo to a corrupted file because of a power problem or other crashes.

    Posted On June 5, 2009 - 01:02 PM (5 months ago) (Permalink to this post)

Subscribe to this topic via RSS

Reply

You must log in to post.