7.1 undo trash of image results in 'corrupt' file
Since upgrading to 7.1 from 7.02 I have found that when I delete an image from a session and then go to undo the action (Command - Z) the image comes up blurry with text over it that reads - the selected image is either unavailable, in an unsupported format or corrupted. The Raw file is still in the folder but it disappears from the browser window and creates a space in the browser as if the image is missing. However if I manually drag the image from the trash folder back into the original folder containing the raw files the image is returned without any problems albeit without any corrections. I believe this to be a bug as there has never been a problem before and the image used to come back when you chose to undo the change and the image was returned to its rightful place with all corrections that had already been applied. If you could please explain this it would be great.
0
-
On an new MacBook Pro and on a MacPro, both with 10.8.2., I had to experience the same phenonema.
Christoph0 -
if this occurs, close the catalogue or session, close COne and THEN reopen both. Problems should be gone.
To crosscheck, go to Preferences and check the "Scratch folder of COne" which is indicated along with a letter "Æ’" and delete this file/folder.
BTW. This exists as well if MP crashes ....0 -
The scratch folder option doesn't exist under Preferences, I am using Capture One Pro 7.1 on a Mac [quote="Thomas248" wrote:
if this occurs, close the catalogue or session, close COne and THEN reopen both. Problems should be gone.
To crosscheck, go to Preferences and check the "Scratch folder of COne" which is indicated along with a letter "Æ’" and delete this file/folder.
BTW. This exists as well if MP crashes ....0 -
I believe something is happening to the file when it is being restored from trash that is causing it to corrupt. If I duplicate the file so it is ".copy" that file instantly shows up in the browser which means that the file itself is fine, it is the preview or settings for the file that are being changed in some way. 0 -
For sure this is Mac related, the paths only rely to Mac OS - Windows has a complete different file-structure!
sorry, if it exists it is stored at ~/Library/Application Support/Capture One/...
and as I posted, it might exist - but it will only present if COne crashes.
nothing happens to the file - why should this happen?
The problem is related to the SQLite database - or more precise - the update of the database and the absence of the .cop-file inside the database bundle - and displaying this change in COne's browser.
It is "metadata" and the absence of the .cop file - nothing else.
saludos redondos -
tom0 -
To visualise what happens I'll try to describe the actions related to your topic.
1. Open a new catalogue -> catalogue Bundle is created & -> empty database is created
http://www.cryptodendron.de/divers/POne/step1.png
2. Pictures are imported -> metadata of pictures are inserted into database
http://www.cryptodendron.de/divers/POne/step2.png
3a. Previews are generated -> .cop-file -> .cop-file is stored in bundle
3b. Metadata of .cop-file are generated -> metadata inserted into database
http://www.cryptodendron.de/divers/POne/step3.png
4a. Editing picture -> -.cos-file is generated -> .cos-file is stored in bundle
4b. Metadata of .cos-file are generated -> metadata inserted into database
(Further steps like updating the .cop-file and generating and insert of metadata of edited files are skipped here, because there are too much options like variants and displaying them would be too here.)
http://www.cryptodendron.de/divers/POne/step4.png
If you now delete a file from the catalogue, the data inside the database are deleted, .cop and .cos files (and maybe more are deleted).
If then the file is inserted back into the catalogue, all steps begin from step 1, but the the previews are (sometimes) not updated, because the actual instance is running and updating the browser fails.
Closing the catalogue and - for integrity reasons - closing COne flushes all volatile data from the system.
If COne is reopened and the catalogue of interest is opened again, the database is instantiated newly and the previews, connected with the metadata in the database, are loaded freshly in this new instance will display everything as expected.
The reason is, that is impossible to realise a pattern called polyinstantiation on one catalogue with the used database called SQLite - in short: the database isn't capable to do this within COne, because for this a parallel AND synchronised usage of the catalogue would be necessary and that, for sure, cannot be reasonable realised within an application like COne orcopaable products on a standalone desktop computer system, regardless the underlying desktop OS.
Following this architecture it is obvious, that the original file is never touched anyway and the claimed "corruptness" which does not exist, is only caused by the technology and tools that are used in combination with the presentation on your monitor.
Due to the limitations for pictures here, you can download the pictures for better viewing here:
saludos redondos -
tom0 -
Thanks Thomas for your in-depth reply, I understand some of what you wrote, but what I don't understand is how it is suddenly a problem when there wasn't a problem with v.7.02, or v.6. I use sessions not catalogs because I am more comfortable with it and I just drag folders into the software. This is how I have always used C1 and will continue to at this stage. I'm still not sure how this can be fixed or maybe I need to wait for a version upgrade. 0 -
What I tried to explain was made using "catalogues", but using sessions, the internal processes are programmatically the same. What is just different with catalogues is the fact, that all additional files ares stored into on place, the catalogue and are not spread around multiple storing sources. the database itself exists as well as the .cop, .cos, and .cof files, which are stored in subfolders in the source folders of the referenced pictures.
If you do not use referenced catalogues, but additionally let COne store the source pictures inside the catalogue-bundle, the size of the bundle becomes very fast really large.
The database produced and used is nearly identical for catalogues and sessions, besides, for sure, the referenced paths to the originals.
Remember that the catalogue itself is just a portion of the file-system and it is aggregated to one seemingly single file, but that is just the look at the surface. Do the following: produce small referenced catalogue and store it. Then go the place where the catalogue resides on your hd, right-click on the catalogue and select: "Open Package". A new folder should open and you will detect a portion of the file-system dedicated to that catalogue, which is identical to a standard folder structure produced by HFS+. No witchcraft - nothing strange.
Regarding performance and speed take into consideration, that developers are using fat-clients with the newest processors and mostly a real huge amount of RAM. Older systems like core 2with two kernels are remarkably slower compared to i5 or i7 processors. This is where the lack of performance relies on - if than just a simple hd is in use and not a ssd or a hybrid hd speed will additionally decrease. This becomes worse, if the originals are stored upon an external hd. All this sums up to a slow down and, for sure, as well will increase the time for a complete shutdown of the application.
saludos redondos -
tom0 -
I am experiencing the same problem.
This was also happening in earlier versions of Capture 7, just by changing the order of the thumbnails (date or name) which incidentally didn't actually correctly order the files.
This is still happening with retrieving images from the trash whether using the undo function or manually retrieving them and dragging back into the capture folder.
This completely makes the session dysfunctional and I have to create a new one, as I shoot high volume work with clients I can't be spending time trying to fix this during a shoot, nor trying keep the Photographers that work for me on top of way to work around the bugs in this program.0 -
I completely agree. This should not be happening on an upgrade that is so much better in other areas and that I had to pay for. I wonder how many other people are having this problem and whether Phase One know about it and are going to sort it out in the next update??? [quote="NN634855140325149957UL" wrote:
I am experiencing the same problem.
This was also happening in earlier versions of Capture 7, just by changing the order of the thumbnails (date or name) which incidentally didn't actually correctly order the files.
This is still happening with retrieving images from the trash whether using the undo function or manually retrieving them and dragging back into the capture folder.
This completely makes the session dysfunctional and I have to create a new one, as I shoot high volume work with clients I can't be spending time trying to fix this during a shoot, nor trying keep the Photographers that work for me on top of way to work around the bugs in this program.0 -
I work in south of France with CO7/DB P22/MACPRO and I observe the same phenomena. this is very annoying. I'm glad to know that I'm not alone and hope Phase will fix it soon on a next update. 0
投稿コメントは受け付けていません。
コメント
11件のコメント