Mask corrupted / C1 kills layer masks?
Hi.
If that's true then this is a severe issue.
It appears to me that during startup, on loading "all images" or other collections, maybe on other occasions too, you can "loose" layer masks!
Or, it is detected at that time that you have lost layer masks (corruted files?)
If that's true, the problem is that you do not even notice this unless you look into the application log!
And even then, the log not even contains the file for which the mask is corrupted.
Masks are being "regenerated" which seems to be nothing else than to generate an empty mask!
It happened to me at least 30 times since summer last year, and indeed I miss some layer masks (the layers are still there in the LA tool but no pixels in the mask). I concentrated my search for missing masks on images whose .comask file have the latest changed date/time in Windows explorer when I detected corrupted mask message today.
It happens with version 8 and 9. And on two different PCs.
Application log:
"Mask corrupted, regenerating"
At least the application log should issue the image names! Even better if C1 shows a message to the user. Even better if the root cause would be eliminated, I hardly can believe that this is a file system / drive issue, as I have never ever experienced a corrupted raw file for example, only layer masks...
I would be interested if you also have this error message in the application.log and/or if you also miss masks.
Thanks and cheers
BeO
If that's true then this is a severe issue.
It appears to me that during startup, on loading "all images" or other collections, maybe on other occasions too, you can "loose" layer masks!
Or, it is detected at that time that you have lost layer masks (corruted files?)
If that's true, the problem is that you do not even notice this unless you look into the application log!
And even then, the log not even contains the file for which the mask is corrupted.
Masks are being "regenerated" which seems to be nothing else than to generate an empty mask!
It happened to me at least 30 times since summer last year, and indeed I miss some layer masks (the layers are still there in the LA tool but no pixels in the mask). I concentrated my search for missing masks on images whose .comask file have the latest changed date/time in Windows explorer when I detected corrupted mask message today.
It happens with version 8 and 9. And on two different PCs.
Application log:
"Mask corrupted, regenerating"
At least the application log should issue the image names! Even better if C1 shows a message to the user. Even better if the root cause would be eliminated, I hardly can believe that this is a file system / drive issue, as I have never ever experienced a corrupted raw file for example, only layer masks...
I would be interested if you also have this error message in the application.log and/or if you also miss masks.
Thanks and cheers
BeO
0
-
Hi,
as far as I know C1 expects the related files (*.comask) at certain places - at least in Sessions which is the mode I'm working in.
Is there a chance that C1 in your working ambient could loose connection / track to the subfolder where this information is stored (expected)?0 -
Thanks Michael,
No, this is not the case. Before and after such messages in the log, I have the same number of .comask files the the adjustments folder. Many of them have a new modified date and time (time of C1 startup) but all have an old creation date.
Also, I often have several layers/masks. Usually one one layer mask is lost but the others are there, I assume all masks are stored in the same .comask file for an image.
Cheers
BeO0 -
If I knew which images are affected (as soon as they are affected / corrupted) I could copy the .comask from an older backup.
Anyone else with "mask corrupted" message in the application.log?0 -
I suspect this message may not be telling the entire story to us, the uninitiated.
That it is able to "regenerate" and on the basis that I have not yet identifies a missing mask despite a lot of use and, on occasions, a lot of copy and apply activity suggests to me that this is an internal message that something is not right with something in memory (whether just now being loaded or something from cache is unstated, and is therefore being recreated in the memory stack from the comask file. If I am right we can think of this as inbuilt process error correction.
The use of multithreading technology by both CPU and now GPU means that arts of the process are picked out processed and re-combined later. In some ways the linear process power CPUs (usually top gaming machines) from a decade or more back offered a more controllable processing opportunity than the multicore and multithreaded chips available today. However since linear processing is no longer a realistic option in a process intensive application where the usage demands a fast perceived response split and recombine is the only option. Check and correct to ensure that everything has worked as planned is therefore a requirement. I suspect that might be what is being recorded in parts of the log file in order to monitor how well the designs applied are achieving their goals.
Or something like that.
I could well be wrong but so far I have not observed a total loss of masks (or any other adjustments other than one occurrence of a partially damaged .cos file back in V7 days). On that basis I have concluded that the message line in the log file is informational rather than something that relates to a permanent error.
Grant0 -
Hi Grant,
I have meanwhile conducted a lot more tests. I finally ended up with a new catalog with only 1 image to ease my tests. And I think there is a very little error likelihood for my findings.
Case 1: .comask file not available
If the file is not available (deleted, renamed, not accessible) then a new (empty) file is generated. No mask pixels inside.
The layer properties (slider values) are preserverd, as they are stored in the database (ZVARIANTLAYER). In this record there is a unique ID for the layer mask (ZMASKUUID).
This ID is not changed, i.e. if you find the .comask file in one of your Adjustment folder backups you can replace the newly created empty file with the old one and everything is fine.
In addition to "mask corrupted, regenerating" you also get a line in the application.log saying "file abc.comask not found", so you know which variant is affected.
This is true for v9.0.3 not tested for earlier versions.
Case 2: File exists but is "corrupted".
I have .comask files in my backup which were stored on a Synology NAS, don't know if this is the (or the only) reason for this or similar problems, as most of such files work fine.
However, C1 does not regonize some files as valid and says "mask corrupted, regenerating". But no mention about the affected file!
And in this case, the UUID in the database is changed!
It seems that the corrupted (or unidentified) layers are replaced, the layers' mask UUID is newly generated!
That means your backup .comask files (with the original UUIDs) are totally useless, you cannot replace the file to regain your mask.
Useless unless you also search for the old UUID in the old catalog and replace the new UUID in the new catalog with a database tool. Which I did and which proves that the neither the old backup file nor the mask in it are actually corrupted.
What they did half-way right for a missing file (right: don't change the UUID, log the filename. wrong: no notice of the user in the application GUI), they did not make it right for single layer masks failing (wrong: change UUID, no filename in the log, no notice of the user in the application GUI).
------
I have 30 such lines in the log since last summer, randomly distributed. I guess that an earlier version of C1 (from last year) re-generated the UUID for some layers for some unknown reason, I don't really believe that my .comask files got really corrupted.
I lost another 10 masks just yesterday on the new computer, with my optimized, exported and verified catalog.
To prevent further mask issues I think I have to go back again to an (not to) old catalog and try to find another way to migrate.
Cheers,
BeO0 -
I repeated the migration procedure (copy catalog and adjustments from old notebook to new PC) but this time copied all files with xcopy /v via a external drive to be sure the files get not corrupted in the copy process.
Cache files were then generated on starting C1.
Then starting / closing C1 a few times. Loading catalog, all images. Navigating in the catalog. No edits.
1. Roughly 300 .comask files then have gotten a new modification date in windows explorer. Why? This happens every time I load all images.
2. From those 300, 50 comask files have been updated in the database (i.e. in ZVARIANTLAYER they kept their ZMASKUUID BUT they got a new primary key (Z_PK)). Why?
3. So far so good (?), BUT 2 variants of those 50 lost layer masks (1 image lost all 9 masks, the other image lost 1 of several masks)!
So, Why does C1 modify the 300 files on loading all images at all?
Why does C1 even change the primary key for the 50 layer masks?
Isn't both itself a problem, at least beard the risk of failures/corrupts?
Why got 2 files corrupted masks?
I am sending two files (Oringial comask file and corrupted comask file which lost one mask) to my support case.
Cheers
BeO
P.S. I just started C1 again to confirm step 1, I then again lost another mask !!!!0 -
[quote="BeO" wrote:
Anyone else with "mask corrupted" message in the application.log?
Hi BeO,
I only have 410 .comask files in a catalog of 33592 referenced images.
I don't have any "mask corrupted" messages in the application.log files.
The modification times of my .comask files are not updated when I select the "All Images" collection, but only when I actually select and view an image that has a mask.
Richard0 -
Richard,
Thank you!
Opening a .comask file with notepad++, it seems that some version number("ver") and "userinfo" is stored. As I am running v8 as a registered user but v9 as a trial, mabye C1 updates this info in the file.
Files are modified as I go scroll through the browser. But C1 could have done this while generating preview imo.
However, you confirm what I also see, repeatedly restarting and openening the same image modifies the file again. Which is silly imo.
I am happy that C1 does not change the raw files and eventually corrupt them!
I would attribtue this to either v9 or the new PC but have noticed this with v8 on the old notebook too, so it seems to be an issue with C1, if that's not going to be sorted out that's it for me.
First time ever I really get angry about the issues with C1 👿
Thanks again Richard
BeO0 -
Hang on BeO,
The New V9 engine probably does imply changes to the information in the comask files - especially interesting to deal with if you have variants using different engines all the way form V7 perhaps.
As I recall there were also some step changes in the V8 engine and I assume they might end up with the same result.
So changes are not necessarily a problem. Losses, unexplained, possibly are - although why they apparently go missing may not be so easy to confirm or identify. Indeed is anything lost? It may be possibly to have a comask file that was created, is actually doing nothing and is therefore binned on development engine upgrade since it has no purpose and cannot be upgraded.
I'm speculating of course - but it is speculation that may need to be considered.
Grant0 -
Grant, thank you. [quote="SFA" wrote:
Hang on BeO,
The New V9 engine probably does imply changes to the information in the comask files - especially interesting to deal with if you have variants using different engines all the way form V7 perhaps.
Grant
I just imported a new file into V8 and added layers and masks. Closed C1. Started C1. View this image again. Comask files is modified. No other application changes a file when viewed only without having made any changes, any auto-save feature should respect that.
But yes, not a problem as such, just weird.[quote="SFA" wrote:
Indeed is anything lost?
Grant
Indeed masks are lost. Slider values are preserved. Believe me, if a mask has red pixels and sliders are applied, and after the message "Mask corrupted, regenerating" the comask file size is smaller, the layer sliders still there but no red mask anymore, sliders with no effect, then the original mask is lost.
Cheers
BeO0 -
I've just done a few experiments in a new catalog.
I imported some RAW files and created masks on two of them. Corresponding .comask files were created.
The following tests were made without changing the actual masks on the images.
With one of the images selected, I restarted Capture One. The modification time for the selected image's .comask file was changed, but the one that had not been selected was not changed.
I then changed the selection to the other image and the modification time for its .comask file was immediately changed.
Changing the selection again did not change the modification time of either .comask file. It looks like the modification time is only changed the first time image is selected after Capture One is started.
I took copies of a .comask file before and after its modification time was changed and used the WinMerge app to compare them. The contents of the files were identical. i.e. the modification times had been updated, but the contents were the same.
I noticed another oddity. I selected an image file that did not have a mask. I cloned the image and added a mask to the clone. A .comask file was created. At this point one variant of the image had a mask and the other didn't. I then deleted the clone that had the mask. The .comask file still existed, even though the only remaining variant of the image didn't have a mask. The modification time of the this 'orphaned' .comask file did not get changed when I selected the image after restarting Capture One. Running Verify on the catalog detected no errors.
During these tests I didn't get any "mask corrupted" messages in the application.log file, or notice any masks go missing.
Richard0 -
BeO, Richard,
Interesting observations.
Am I correct to assume that both of you have done the analysis working just with catalogues?
I will see if I can find anything of similar interest in my sessions. I have certain seen the "regenerating" message although form memory less so since V9. That does not mean much of course - it may depend on what I have been working with.
Grant0 -
I have a situation with my masks in that if I open a catalogue a mask for any image won't show until I go to the mask, click on it and select Adjust>Fill Mask and then the mask comes back.
Is this similiar situation to your problem?
I'd also like to know why Capture One doesn't pick up the pre-created masks?
Richard0 -
Hi Richard,
Adjust>Fill Mask: If you mask any closed geometry, then Fill mask fills the empty pixels within that geometry. In case your mask is empty, then it fills the whole image. Is it that what you mean? When you say "then the mask comes back." does it means the whole image is masked and you expect that?
I can't imagine a use case for a mask with 100% image coverage (and equal opacity, gradients are a different story of course).
In case you usually have masks with lesser area coverage (or gradients) and you need to Fill mask and then you have 100% coverage then the mask was either empty by you or you have found a mask which was killed by C1.
10 minutes ago another image lost its mask... (v9 trial on new PC)
Maybe C1 writes bytewise new information like version of userinfo and if the new version or userinfo has more bytes then it overwrites some bytes in the file and therefore corrupts one or more masks in the file?
Yes Grant, I don't use sessions.
Cheers
BeO0 -
btw, it looks like this: ********************************************************************************
[2016-02-28 16:14:03.219][000][ID:007, ]{APPL } | Application started, version Capture One 9.0.3.14
[2016-02-28 16:14:03.484][265][ID:007, ]{LOG } | Log file initialized.
[2016-02-28 16:14:03.952][468][ID:001, ]{APPL } | INFO : Program closed correctly on last run.
[2016-02-28 16:14:04.108][156][ID:001, ]{APPL } | Starting ImageCore
[2016-02-28 16:14:04.139][031][ID:001, ]{APPL } | Application version : Win.9.0.3.14.9f9ab92.c22e66d
[2016-02-28 16:14:04.139][000][ID:001, ]{APPL } | ImageCore version : Build: 19 Commit: c22e66dca91daaf178a8d37f4f8ec55c0068c632 Branch: release/9.0.x
[2016-02-28 16:14:04.139][000][ID:001, ]{APPL } | XMP Sync is set to : None
[2016-02-28 16:14:04.670][530][ID:014, ]{CAMCO} | Succesfully set the OpenCL setting to Never
[2016-02-28 16:14:06.161][491][ID:025, [FileSyste]{FS } | Starting File System Notifications Processing
[2016-02-28 16:14:06.223][062][ID:024, [FileSyste]{FS } | Starting Queue Processor Thread : [FileSystem] Scheduler SDE [24]
[2016-02-28 16:14:06.223][000][ID:023, [FileSyste]{FS } | Starting Queue Processor Thread : [FileSystem] Scheduler SIU [23]
[2016-02-28 16:14:06.223][000][ID:022, [FileSyste]{FS } | Starting Queue Processor Thread : [FileSystem] Scheduler DE [22]
[2016-02-28 16:14:06.223][000][ID:027, [FileSyste]{FS } | Starting Queue Processor Thread : [FileSystem] Scheduler IU [27]
[2016-02-28 16:14:07.003][780][ID:001, Main]{APPL } | CameraProperty: Name='', Value set to ''
[2016-02-28 16:14:07.003][000][ID:001, Main]{APPL } | CameraProperty: Name='', Value set to ''
[2016-02-28 16:14:07.003][000][ID:001, Main]{APPL } | CameraProperty: Name='', Value set to ''
[2016-02-28 16:14:07.003][000][ID:001, Main]{APPL } | CameraProperty: Name='', Value set to ''
[2016-02-28 16:14:07.003][000][ID:001, Main]{APPL } | CameraProperty: Name='', Value set to ''
[2016-02-28 16:14:07.003][000][ID:001, Main]{APPL } | CameraProperty: Name='', Value set to ''
[2016-02-28 16:14:07.003][000][ID:001, Main]{APPL } | CameraProperty: Name='', Value set to ''
[2016-02-28 16:14:07.003][000][ID:001, Main]{APPL } | CameraProperty: Name='', Value set to ''
[2016-02-28 16:14:08.594][591][ID:001, Main]{PSIST} | Opening document : C:\Users\abc\Pictures\NewTrial\C1.cocatalogdb
[2016-02-28 16:14:09.125][530][ID:042, ]{PSIST} | Number of collections loaded for the document is: 102
[2016-02-28 16:14:09.172][046][ID:001, Main]{APPL } | RequestPopulateContents is called for All Images
[2016-02-28 16:14:09.187][015][ID:039, [Collectio]{PSIST} | Loading collection All Images
[2016-02-28 16:14:09.484][296][ID:001, Main]{APPL } | RequestPopulateContents is called for All Images
[2016-02-28 16:14:09.640][156][ID:039, [Collectio]{PFORM} | s_freePreallocatedLocksPool is exhausted
[2016-02-28 16:14:09.640][000][ID:039, [Collectio]{PFORM} | s_freePreallocatedLocksPool is exhausted
[2016-02-28 16:14:09.998][358][ID:040, Persistenc]{VIEWE} | Error: VariantGridView.OnSelectionPropertyChanged SmartBeginInvoke failed - this could mean one missing viewer update
[2016-02-28 16:14:10.753][755][ID:001, Main]{LOG } | User log: description = [Capture One started], details = [The application was started successfully]
[2016-02-28 16:14:12.111][357][ID:014, ]{CAMCO} | Succesfully set the OpenCL External setting to Auto
[2016-02-28 16:14:12.532][421][ID:014, ]{CAMCO} | Succesfully set the OpenCL setting to Never
[2016-02-28 16:14:12.532][000][ID:014, ]{CAMCO} | Succesfully set the OpenCL External setting to Auto
[2016-02-28 16:14:29.636][103][ID:001, Main]{PSIST} | Mask corrupted, regenerating.
[2016-02-28 16:14:29.636][000][ID:001, Main]{PSIST} | Mask corrupted, regenerating.
[2016-02-28 16:14:29.636][000][ID:001, Main]{PSIST} | Mask corrupted, regenerating.
[2016-02-28 16:14:29.636][000][ID:001, Main]{PSIST} | Mask corrupted, regenerating.
[2016-02-28 16:14:29.636][000][ID:001, Main]{PSIST} | Mask corrupted, regenerating.
[2016-02-28 16:14:29.636][000][ID:001, Main]{PSIST} | Mask corrupted, regenerating.
[2016-02-28 16:14:29.636][000][ID:001, Main]{PSIST} | Mask corrupted, regenerating.
[2016-02-28 16:14:29.636][000][ID:001, Main]{PSIST} | Mask corrupted, regenerating.
[2016-02-28 16:14:29.636][000][ID:001, Main]{PSIST} | Mask corrupted, regenerating.[2016-02-28 16:14:35.112][475][ID:039, [Collectio]{SESPS} | Loading collection finished. Document Type: Catalog. Collection Name: All Images. Collection items count = 4102. Time taken: 25927 ms.
[2016-02-28 16:18:34.743][631][ID:001, Main]{PFORM} | Form Closing - Reason: UserClosing
[2016-02-28 16:18:34.790][046][ID:001, Main]{APPL } | Cancelling collection filling of All Images
[2016-02-28 16:18:34.868][078][ID:031, ]{PFORM} | s_freePreallocatedLocksPool is exhausted
[2016-02-28 16:18:36.688][820][ID:001, Main]{PFORM} | s_freePreallocatedLocksPool is exhausted
[2016-02-28 16:18:37.646][958][ID:001, Main]{PFORM} | s_freePreallocatedLocksPool is exhausted
[2016-02-28 16:18:37.824][178][ID:001, Main]{APPL } | Closing app: Message pump stopped
[2016-02-28 16:18:37.828][004][ID:001, Main]{APPL } | Closing...
[2016-02-28 16:18:37.884][056][ID:001, Main]{APPL } | Closing app: Closing the IC crash handlers
[2016-02-28 16:18:38.412][528][ID:001, Main]{APPL } | Closing app: Closing OpenCore
[2016-02-28 16:18:38.512][100][ID:001, Main]{APPL } | Shutdown of managers and cores completed
[2016-02-28 16:18:39.300][788][ID:001, Main]{PFORM} | Shutdown end
In this above case the second variant of an image lost all 9 layer masks.
Sometimes
[2016-02-28 16:21:31.106][478][ID:045, ThumbnailB]{PSIST} | Mask corrupted, regenerating.0 -
[quote="BeO" wrote:
Hi Richard,
Adjust>Fill Mask: If you mask any closed geometry, then Fill mask fills the empty pixels within that geometry. In case your mask is empty, then it fills the whole image. Is it that what you mean? When you say "then the mask comes back." does it means the whole image is masked and you expect that?
I can't imagine a use case for a mask with 100% image coverage (and equal opacity, gradients are a different story of course).
In case you usually have masks with lesser area coverage (or gradients) and you need to Fill mask and then you have 100% coverage then the mask was either empty by you or you have found a mask which was killed by C1.
I have an image that I believe was first edited in capture One Pro 8 which has a gradient mask applied to the sky.
I then open the same image in Capture One Pro 9 and the gradient mask for the sky isn't automatically re-applied when the image is opened; to do so I have to select the gradient mask and then select Adjust>Fill Mask for the mask to show again.
Very odd behaviour.
10 minutes ago another image lost its mask... (v9 trial on new PC)
Maybe C1 writes bytewise new information like version of userinfo and if the new version or userinfo has more bytes then it overwrites some bytes in the file and therefore corrupts one or more masks in the file?
Yes Grant, I don't use sessions.
Cheers
BeO0 -
The Message seemingly produced about masks and problems looks fairly simple in its interpretation. But is it?
What do we know abut when it is deployed, where it is used and what it is intended to report?
Absent that knowledge it is an interesting puzzle but not much else that we can be sure about.
Grant0 -
Grant, we know nothing from the message itself, but I know that the mask pixel are lost and the file size is smaller after the "regeneration", and I know this by observation.
Richard, I now got you. This does not help in my case, when I "Fill mask" a lost mask layer I got a complete 100% fill, not a restore of the original mask.
Cheers
BeO0 -
I have talked to our developers about this, and they would very much like to investigate this more. We have been aware of this issue for a while, but with more data, we are able make a better fix.
Those of You who experience this issue, please write Support and reference my response here. We can then setup a TeamViewer session or extraction of more data, once we have Your contact details.
Thank You for all your hard work here.0 -
Hi Christian,
Thank you, this is very good news and very much appreciated!
I've written already quite a lot in my support case and have attached 2 comask files for an image (original/after regeneration), this might maybe already helpful as a starting point for the developers?
Contact
I think my contact details (e.g. email) are accessible for you from my account, case number is 212983.
Maybe you can forward this information, the case has not yet been answered, maybe because of workload, so an additional case might not be recognized soon.
I think there are a number of observations, some of them are not easy to reproduce "on demand", i.e. hard to show in a web session, without a proper demonstation path prepared. I therefore suggest that you (respective development) formulate some ideas what you would like to see.
A short summary of my observations
0. Actual root cause for the mask "corruption" event: That's what we all look for but notthing directly to show, can't determine when and why exactly it happens, so it might only be possible to identify by researching indirect observations or source code inspection?
1. comask file "modification date" is changed when variant is viewed in viewer (easy to reproduce)
2. Image filename is not metioned in application.log when comask file exists but a mask is said to be corrupted.
Adding this information would ease the search.
3. ZMASKUUID is newly created if a mask is "regenerated" as an empty mask (which makes backup comask files useless, because the mask from the backup then is also recognized as "corrupted", suspiciously due to UUID mismatch). This was true for some of the affected images, not for all (some backup files worked). Hard to reproduce for a single layer corrupted, easy if the whole comask file is missing.
Keeping the UUID could ease the pain if a mask gets corrupted and user detects that and still has an uncorrupted backup file.
4. ZMASKUUID remains identical for a layer but ZVARIANTLAYER.Z_PK changes (hard to reproduce). This happened for many images, not only for those which have lost masks. (Observation via SQL, attached to the support case). No idea how to reproduce.
When I say "hard to reproduce" it means that I haven't tried to reproduce it, it sometimes is only an observation after things went wrong, not sure when it went wrong, that's why it is hard to reproduce.
My suspicion is that the corrupted mask "detection" occurs when writing to the comaks file. Writing to the comask file probably occurs when viewing the image. So point 1 (what are the criteria to write, and what data is written on viewing an image) might be a good starting point for your own research as a preparation?
I am very open to help in any way I can.
Cheers
BeO0 -
Christian,
I am not sure about this but it has occurred to me that some useful information about processing activity may be split across log files.
Has this been looked at already?
Has anyone identified some sections of files and combined them in order to see if a repeating series of events can be observed?
I am considering do it with my files but I'm not at all sure I have seen adverse results from the problems mentioned above so I could be wasting the effort.
Grant0 -
Some of oddities have been fixed with the just-released CO 9.1, more here: viewtopic.php?f=62&t=22332 0 -
Thanks Christian. 0 -
Hey There Masterminds from Phase One!
I came from Aperture and now using your great Software.
Thanks for all that kind of hard work.
I am using Capture One Pro 9.2.1 on a MAC Book MacBook Pro (17-inch, Mid 2009), OS X El Capitan, 10.11.6 (15G1004).
2,8 GHz Intel Core 2 Duo, 8 GB 1067 MHz DDR3, no windows on it. Sorry i haven´t read the headline.
But the same Problem.
Came back from Holiday with about 2300 pics and 400 have to find their way into a photobook.
The files a delivered, all perfect. Thanks god for that.
After that, i want to number all my seven folder for my sessions. (Diffrent sessions)
Go to finder and changed the folder name, ass well the 4 Sommerurlaub Dachstein.cosessiondb
On the next day i got a failure code (window) on my session from the holiday.
it was a german window and it says something about "anpassungs maske kann nicht geladen werden".
"mask could not be loaded".
Going into several other pictures, the sliders have the position on which it was applied for the mask.
But the effect was not visible.
Either by changing the slider or by on/off selection of the respective mask.
But on a other session, the mask is there and the effect could be seen.
Thereafter i deleted the number on the folder as well on the cosession file.
restart the computer, restart the capture one pro.
several times.
Allways a fault code on the "Dachstein" folder.
opening the file with a texteditor shows only a few lines.
"XCon¿Bæ∫˛ TYPE¿CaptureOne Mask˛VER˛
ˇˇMaskInfo"Hdr"ˇ¿–˛!ˇˇUserInfo"$A45F3573-B4D9-48FA-A4D5-B7C62DE7EAC7˛1ˇˇUserInfo"$412064B1-CC90-403B-AB07-06EB64960AB8˛1ˇˇUserInfo"$48DACFA3-8206-4990-B4A3-19B6653B3CF7˛1ˇˇUserInfo"$2B78C33D-BF73-402A-860A-346C45C90EC3˛1ˇˇUserInfo"$7ADF969D-8787-4C25-BCA3-57CB35FB0100˛1˛DsMapoP˛oYMapoP˛oYMapoP˛oYMapoP˛oYMapoP˛oYBlk"ˇHdr"ˇ˛ˇˇIdx"˛dat˛˛7˛C3i"
The other ones from other selected sessions, did have more entries in the comask file.
I thought i could bring them back by time machine, but unfortunately i did not save the folders from capture one sessions due to the external HDD was on the "EXCLUDE File List" from time machine due to the size of the HDD.
So i could not bring them back or load it from a few days before.
i tried to repair the HDD by "zugriffsrechte reparieren" but also it won´t work.
I tried also inside the programm the verify function.
did not help.
Mit Datenbank verbunden
/Volumes/Media/Capture One Sitzungen/4 Sommerurlaub Dachstein/4 Sommerurlaub Dachstein.cosessiondb
Datenbank Verbindung OK
Überprüfe Datenbank…Checking database integrity
Database integrity OK
Checking database structure
Checking database structure: tables
Checking database structure: tables structure
Checking database table 'ZCAPTUREPILOT' structure.
Checking database table 'ZCOLLECTION' structure.
Checking database table 'ZDOCUMENTCONTENT' structure.
Checking database table 'ZENABLEDOUTPUTRECIPE' structure.
Checking database table 'ZENTITIES' structure.
Checking database table 'ZIMAGE' structure.
Checking database table 'ZIMAGEINCOLLECTIONPROPERTIES' structure.
Checking database table 'ZKEYWORD' structure.
Checking database table 'ZPATHLOCATION' structure.
Checking database table 'ZPROCESSHISTORY' structure.
Checking database table 'ZSELECTEDVARIANTS' structure.
Checking database table 'ZSIDECAR' structure.
Checking database table 'ZSTACK' structure.
Checking database table 'ZSTACKIMAGELINK' structure.
Checking database table 'ZVARIANT' structure.
Checking database table 'ZVARIANTLAYER' structure.
Checking database table 'ZVARIANTMETADATA' structure.
Checking database table 'ZVERSIONINFO' structure.
Checking database structure: triggers
Checking database structure: indexes
Database structure OK
Checking database content
Checking document type
Checking document type done
Checking document UUID
Checking document UUID done
Checking document selected collection
Checking document selected collection done
Checking Capture Pilot settings
Checking Capture Pilot settings done
Checking layer ordering values
Checking layer ordering values done
Checking layer for missing metadata
Checking layer for missing metadata done
Checking metadata for missing layers
Checking metadata for missing layers done
Checking variant relationships
Checking variant relationships done
Checking image variant relationships
Checking image variant relationships done
Checking variant image relationships
Checking variant image relationships done
Checking local adjustment layer UUIDs
Checking local adjustment layer UUIDs done
Checking style adjustment layer UUIDs
Checking style adjustment layer UUIDs done
Checking stack image relationships
Checking stack image relationships done
Checking stack collection relationships
Checking stack collection relationships done
Checking image relationships
Checking image relationships done
Checking stack-image links
Checking stack-image links done
Checking stack-image links for duplicates
Checking stack-image links done
Checking for duplicate stacks
Checking for duplicate stacks done
Checking sidecar entities
Checking sidecar entities done
Database content OK
Debug OK
I tried to reload the preview pics, no help.
Is there any chance to bring back the applied mask and the effect??
Thanks in advance
Peter, from the AUSTRIA0 -
I've just noticed that this has happened again.
I upgraded to 10.0.2 and all the previous masks I have created are still showing as being there but are non active.
By that I mean that if I select any mask I have created prior to the update the mask show in the list but if I select a amsk and press 'M' nothing happens (no red mask appears) and if I remove the tick from a mask nothing happens.
All that work wasted, again!
I'm not impressed!!!0 -
[quote="Richard_Allen" wrote:
I've just noticed that this has happened again.
I upgraded to 10.0.2 and all the previous masks I have created are still showing as being there but are non active.
By that I mean that if I select any mask I have created prior to the update the mask show in the list but if I select a amsk and press 'M' nothing happens (no red mask appears) and if I remove the tick from a mask nothing happens.
All that work wasted, again!
I'm not impressed!!!
Richard,
Have you renamed the problem file per chance?
Or does this happen for all files?
The comask files are in a different folder in a session but I would guess they are referenced by the cosessiondb file and so something similar is likely in a catalog. That could lead to the editor knowing about the layer but not the mask to apply to it.
As an experiment one might take a couple of minutes to create a new import (to a new session) of the existing files with their adjustments to see what happens. For a catalogue I would guess that one would need to first export with adjustments (EIP?) and then import again - or maybe just try Export to new catalogue directly?
The question is whether the cause is the same as previously or something new and unfortunately similar.
Grant0
Post is closed for comments.
Comments
26 comments