Capture Ones obegripliga filstruktur och ofrivillig permanent radering av bilder

[thommya]

Alltså föga likhet med C1.

Ja, och det var ju det jag skrev i mitt första inlägg.

 

[unoengborg]

Suck och stön, ska jag behöva förklara en tusende gång vad problemet är? Vi provar igen: Hur tar jag bort bilder från C1 utan att radera dem från disken? Det verkar tydligen inte gå. Antingen raderas de direkt, eller så hamnar de i en osynlig papperskorg och raderas sen när man tömmer papperskorgen. Vilket är fullständigt obegripligt eftersom de inte legat i papperskorgen utanför C1
Alltså föga likhet med C1.

Inte obegripligt alls. När du trycker delete på en bild i katalogen slutar den visas i katalogträdet och visas i stället i C1 katalogens papperskorg. Bilden på disk flyttas inte utan den ligger kvar där den var.
När du sedan tömmer C1 papperskorgen genom att trycka på "ta bort från disk" tas bilden bort från disken. Väljer du bara "ta bort" ligger bilden fortfarande kvar på disk, men katalogens referens till den försvinner så du ser den inte längre i C1 men du kan fortfarande se den i finder/explorer Systemets papperskorg är aldrig inblandad.

Varför vill du föresten ta bort bort bilder från C1 katalogen men fortfarande ha kvar bilden?

 

[Makten]

 

[Melker Humala]

Jadu makten. Det är så här ett modernt databasbaserat program fungerar. Man måste släppa kontrollen i sina vanliga mappar och låta programmet sköta filhanteringen. Jämför hur itunes eller apples bilder hanterar filer, samma sak.

det verkar inte som om detta passar ditt workflow helt enkelt. Det normala ”tänket” är ju att behålla rawfilen och bara exportera ut jpg när man behöver dem till tex webbpublicering.

Ps Jag gillar din Picard referens

 

[unoengborg]

Jadu makten. Det är så här ett modernt databasbaserat program fungerar. Man måste släppa kontrollen i sina vanliga mappar och låta programmet sköta filhanteringen. Jämför hur itunes eller apples bilder hanterar filer, samma sak.

det verkar inte som om detta passar ditt workflow helt enkelt. Det normala ”tänket” är ju att behålla rawfilen och bara exportera ut jpg när man behöver dem till tex webbpublicering.

Ps Jag gillar din Picard referens

Apples bilder fungerar lite annorlunda, där lagras både bilder och editeringsinformation i databasen. Detta går även att göra i C1. När man importerar bilder i importerar man dem helt enkelt direkt till katalogen istället för till en mapp i filsystemet. Då riskerar man aldrig att komma att förlora sync mellan databas och filsystem. Nackdelen är förstås att man inte kan ha större kataloger än vad filsystemet klarar av att lagra som en fil. Fördelen är att backup blir enkelt, bara ta backup på katalogfilen och allt är klart. Skulle också kunna vara praktiskt om man har en katalog per kund då kan man ju lagra katalogfilen tillsammans med annan kundinformation som t.ex. avtal, modellreleaser m.m. Men begränsningen är förstås att man inte kan ha hur stora. katalogfiler som helst, men det kanske kan lösas genom att ha en katalog per år eller månad beroende på hur mycket bilder det rör sig om.

 

[Fredrik O.]

Hur tar jag bort bilder från C1 utan att radera dem från disken?

Håller med om att det är rätt otydligt i C1 hur man hanterar de filer man ska ta bort. Det skiljer sig också mellan kataloger och sessioner.

I bild-vyn har man tre alternativ:
1. Ta bort (flyttas till katalogens/sessionens papperskorg)
2. Flytta till katalogens/sessionens papperskorg (med andra ord samma som #1)
3. Radera från hårddisken (raderas helt från skivan direkt)

Går man sedan till papperskorgen så kan man välja Töm papperskorgen (då får man välja om du vill ta bort alla från hårddisken eller bara från katalogen)

Eller så kan man marker en eller fler bilder och välja:
1. Ta bort (från disk) (då får man välja mellan att radera från hårddisken eller bara katalogen)
2. Radera från hårddisken (samma som #1)

Arbetar man med sessioner så kan man bara radera, inte ta bort från katalogen.
Man vänjer sig efter ett tag men ja, detta skulle kunna göras betydligt mer logiskt.

 

[unoengborg]

Håller med om att det är rätt otydligt i C1 hur man hanterar de filer man ska ta bort. Det skiljer sig också mellan kataloger och sessioner.

I bild-vyn har man tre alternativ:
1. Ta bort (flyttas till katalogens/sessionens papperskorg)
2. Flytta till katalogens/sessionens papperskorg (med andra ord samma som #1)
3. Radera från hårddisken (raderas helt från skivan direkt)

Går man sedan till papperskorgen så kan man välja Töm papperskorgen (då får man välja om du vill ta bort alla från hårddisken eller bara från katalogen)

Eller så kan man marker en eller fler bilder och välja:
1. Ta bort (från disk) (då får man välja mellan att radera från hårddisken eller bara katalogen)
2. Radera från hårddisken (samma som #1)

Arbetar man med sessioner så kan man bara radera, inte ta bort från katalogen.
Man vänjer sig efter ett tag men ja, detta skulle kunna göras betydligt mer logiskt.

Förstår dock fortfarande inte varför man vill ta bort bilden från katalogen men fortfarade ha orginalbilden kvar. Katalogen innehåller ju alla redigeringar och metadata man tillfört sedan bilden importerats. Tar man bort bilden från katalogen går ju dessa förlorade och det som är kvar är bilden precis som den kom ur kameran innan man importerade den..

 

[Fredrik O.]

Förstår dock fortfarande inte varför man vill ta bort bilden från katalogen men fortfarade ha orginalbilden kvar. Katalogen innehåller ju alla redigeringar och metadata man tillfört sedan bilden importerats. Tar man bort bilden från katalogen går ju dessa förlorade och det som är kvar är bilden precis som den kom ur kameran innan man importerade den..

Jag ville mest påpeka att det är otydligt och skulle kunna göras med pedagogiskt. Jag har själv alla mina i katalogen och de som jag tar i jobbet kör jag sessioner och arkiverar. Men det har varit tillfällen när jag snabbt slängt in bilder i en befintlig katalog för att synka utseende med övriga bilder och exportera dem för att sedan vilja ta bort dem från katalogen, utan att radera originalfilerna. Och då reagerar man på att det skulle kunde fungera smidigare. Exempelvis bara ha ett alternativ i kontextmenyn där det står "Ta bort bilden från katalogen".

 

[Sten-Åke Sändh]

Apples bilder fungerar lite annorlunda, där lagras både bilder och editeringsinformation i databasen. Detta går även att göra i C1. När man importerar bilder i importerar man dem helt enkelt direkt till katalogen istället för till en mapp i filsystemet. Då riskerar man aldrig att komma att förlora sync mellan databas och filsystem. Nackdelen är förstås att man inte kan ha större kataloger än vad filsystemet klarar av att lagra som en fil. Fördelen är att backup blir enkelt, bara ta backup på katalogfilen och allt är klart. Skulle också kunna vara praktiskt om man har en katalog per kund då kan man ju lagra katalogfilen tillsammans med annan kundinformation som t.ex. avtal, modellreleaser m.m. Men begränsningen är förstås att man inte kan ha hur stora. katalogfiler som helst, men det kanske kan lösas genom att ha en katalog per år eller månad beroende på hur mycket bilder det rör sig om.

Det är väl också mer sårbart med "a single point of failure" som ju en monolitkatalog är och särskilt då om även bilder skulle lagras i själva databasen istället för i vanliga mappar eller där enbart en pekare till bilderna ligger i databasen och möjligen redigeringsmetadata. Det är sårbart även om bilderna ligger i mappar och ändringsmetadata ligger i databasen.

Det finns ju fler än ett skäl till att låta bildfilerna äga metadatat som i alla större professionella DAM-system och sedan indexera detta. Då är det aldrig någon katastrof om databasen blir korrupt eller försvinner av misstag eller så. Finns bara filerna kvar så är man på banan igen efter en omindexering.

DAM-systemen är dessutom optimerade för snabbhet, skalbarhet och flexibilitet genom att de inte arbetar direkt med de tunga filerna vid sökningar och scrollning utan med mindre och lättare filer optimerade för snabbhet och gallring. Man kan även hantera flera databaser i samna sökningar. Monolitdatabaserna är väldigt praktiska men mer sårbara och de går ofta inte att skala på något praktiskt acceptabelt sätt men för många som inte har 100 000-tals bilder är detta kanske inte ett problem. Så för dem är monolitdatabassystemen enkla, billiga och praktiska lösningar, så länge man är medveten om deras begränsningar och hur de ska hanteras.

 

[unoengborg]

Det är väl också mer sårbart med "a single point of failure" som ju en monolitkatalog är och särskilt då om även bilder skulle lagras i själva databasen istället för i vanliga mappar eller där enbart en pekare till bilderna ligger i databasen och möjligen redigeringsmetadata. Det är sårbart även om bilderna ligger i mappar och ändringsmetadata ligger i databasen.

Det finns ju fler än ett skäl till att låta bildfilerna äga metadatat som i alla större professionella DAM-system och sedan indexera detta. Då är det aldrig någon katastrof om databasen blir korrupt eller försvinner av misstag eller så. Finns bara filerna kvar så är man på banan igen efter en omindexering.

DAM-systemen är dessutom optimerade för snabbhet, skalbarhet och flexibilitet genom att de inte arbetar direkt med de tunga filerna vid sökningar och scrollning utan med mindre och lättare filer optimerade för snabbhet och gallring. Man kan även hantera flera databaser i samna sökningar. Monolitdatabaserna är väldigt praktiska men mer sårbara och de går ofta inte att skala på något praktiskt acceptabelt sätt men för många som inte har 100 000-tals bilder är detta kanske inte ett problem. Så för dem är monolitdatabassystemen enkla, billiga och praktiska lösningar, så länge man är medveten om deras begränsningar och hur de ska hanteras.

Tror inte det är någon större skillnad ur sårbarhetssynpunkt. Vet inte hur det. ser ut på PC men på mac är katlogfilen egentligen en mapp med filinfo satt så att den ser ut som en enda fil. Inuti katalogfilsmappen ligger det dels en sqlite3 databas med metadata och orginalfilerna samt previiew veersioner och tumnaglar i mappar utanför databasen. Så skillnaden är väl egentligen bara att det blir svårare att ta bort billder som finns i databasen med finder av misstag och att katalogen inte kan spänna över flera diskar.