DNG vs RAW+XMP - Backups en andere (on)gemakken

[LegeBoekenkast]

* Afgesplitst van Het grote Adobe Lightroom topic

Universal Creations schreef op dinsdag 28 februari 2017 @ 10:31:
Ah, dan kopieert ie gewoon? Of kan ie er dan ook een xmp bestand bijzetten met daarin eventuele wijzigingen?

Ja, dat doet hij dan inderdaad. De .XMP wordt dan aangemaakt met dezelfde naam. Ik ben overigens overgestapt naar .DNG bestanden. Als je in Lightroom de bestanden selecteert en dan op CMD+S of CTRL+S drukt, slaat hij alle bewerkingen op in het bestand. Dan heb je geen gezeur met .XMP bestanden.

[ Voor 7% gewijzigd door Ventieldopje op 06-04-2017 13:32 ]

[Ventieldopje]

LegeBoekenkast schreef op woensdag 5 april 2017 @ 22:13:
[...]


Ja, dat doet hij dan inderdaad. De .XMP wordt dan aangemaakt met dezelfde naam. Ik ben overigens overgestapt naar .DNG bestanden. Als je in Lightroom de bestanden selecteert en dan op CMD+S of CTRL+S drukt, slaat hij alle bewerkingen op in het bestand. Dan heb je geen gezeur met .XMP bestanden.

Ieder zijn ding Met DNG moet je een poos wachten om alles om te zetten terwijl een XMP bestand hooguit 1KB groot is en zo gemaakt is, in Lightroom merk je het verschil niet.

DNG heeft alleen als nadeel dat je schrijft naar je RAW bestand en dus bij corruptie (hardware fout / netwerk fout) je de kans hebt dat je bestand onleesbaar wordt. Bij XMP heb je dit niet en blijft je RAW altijd onaangetast, bovendien hoeft niet eerst een heel bestand ingelezen te worden welke vervolgens weer helemaal geschreven moet worden (lezen en schrijven van 1KB vs ... 30MB?)

[ Voor 24% gewijzigd door Ventieldopje op 06-04-2017 00:15 ]

[Orion84]

En wat denk je van backups, waar je dan dus wellicht meerdere versies van je dng opslaat, in plaats van 1 raw en meerdere versies van je xmp.

[Get!em]

Als je een backup/versioning/incremental systeem gebruikt, dan heb je met gewijzigde DNG's wel grotere bestanden die zijn gewijzigd. Echter een slim backup programma, backuped alleen de wijzigingen aan grote files en niet de gehele file. Ik gebruik sinds een half jaar Duplicati 2.0 en die is in combinatie met RAW + xmp heel efficiënt met backup increments als ik weer een middag heb zitten bewerken. Maar als ik de handleiding goed lees, dan zou hij ook met gewijzigde DNG's zo efficiënt moeten omgaan.

Duplicati performs a full backup initially. Afterwards, Duplicati updates the initial backup by adding the changed data only. That means, if only tiny parts of a huge file have changed, only those tiny parts are added to the backup. This saves time and space and the backup size usually grows slowly.

https://www.duplicati.com...basic-incremental-backups

(Duplicati wordt overigens meer besproken in het topic over Stack/1000GB storage )

[ Voor 8% gewijzigd door Get!em op 06-04-2017 10:35 ]

[Ventieldopje]

Get!em schreef op donderdag 6 april 2017 @ 10:33:
Als je een backup/versioning/incremental systeem gebruikt, dan heb je met gewijzigde DNG's wel grotere bestanden die zijn gewijzigd. Echter een slim backup programma, backuped alleen de wijzigingen aan grote files en niet de gehele file. Ik gebruik sinds een half jaar Duplicati 2.0 en die is in combinatie met RAW + xmp heel efficiënt met backup increments als ik weer een middag heb zitten bewerken. Maar als ik de handleiding goed lees, dan zou hij ook met gewijzigde DNG's zo efficiënt moeten omgaan.


[...]

https://www.duplicati.com...basic-incremental-backups

(Duplicati wordt overigens meer besproken in het topic over Stack/1000GB storage )

Zo werken incremental backups nou eenmaal Feit blijft dat je elke periode weer een full backup moet doen waarop nieuwe incrementals worden gebaseerd omdat anders het risico te groot wordt dat een van de incrementals corrupt raakt.

Met XMP + RAW kun je de RAW's eenmalig op een backup locatie zetten (als archief) en hoef je daarna alleen de XMP's te backuppen, dit kan gezien de geringe grootte ook prima met een simpele volledige backup. De RAW bestanden moet je namelijk gewoon als read-only zien, het is onzinnig om die data meermaals te backuppen.

[Get!em]

Waar ik op doel, is dat er ook binnen incremental backups verschillen zijn. Namelijk file-level, block-level of byte-level. Duplicati 2.0 is block-level, en zal alleen de gewijzigde blocks backuppen als increment. Bij File-level, backup je in de simplelste gevallen de gehele gewijzigde file.
In het genoemde geval van 30MB DNG met wijzigingen zit je dus met Incremental File-level in meest simpele geval: 30MB per increment, terwijl je met Blocklevel slechts de gewijzigde blocks hebt (die waarschijnlijk puur de metadata bevatten): paar KB increment.

[Ventieldopje]

Get!em schreef op donderdag 6 april 2017 @ 12:43:
Waar ik op doel, is dat er ook binnen incremental backups verschillen zijn. Namelijk file-level, block-level of byte-level. Duplicati 2.0 is block-level, en zal alleen de gewijzigde blocks backuppen als increment. Bij File-level, backup je in de simplelste gevallen de gehele gewijzigde file.
In het genoemde geval van 30MB DNG met wijzigingen zit je dus met Incremental File-level in meest simpele geval: 30MB per increment, terwijl je met Blocklevel slechts de gewijzigde blocks hebt (die waarschijnlijk puur de metadata bevatten): paar KB increment.

Nee, je begrijpt niet wat ik bedoel Je kunt wel tot in den treure incremental backups gaan maken (full -> inc -> inc -> inc etc.) maar als er één incremental in de chain corrupt raakt dan ben je de klos, bovendien duurt restoren een eeuwigheid. Je zal dus na x aantal incrementals weer een full backup moeten maken mét de volledige DNG's. Dan heb je dus op meerdere punten de gehele RAW data waar toch niet naar geschreven mag worden en onnodige ruimte innemen. Je kan dan wel geavanceerde technieken als deduplication gaan toepassen maar zo simpel is dat niet. Je hebt dan alsnog full -> inc -> inc -> inc -> full -> inc ...

Met de RAW's in je archief hoef je daar nooit meer naar om te kijken en kun je altijd een full backup doen van je XMP bestanden alleen.

[Aikon]

Ik kan het nu niet testen, maar een .dng bestand veranderd niet telkens als je lightroom gebruikt. Tenzij je een ctrl+s doet. De aanpassingen zitten in de catalogus, niet in het .dng bestand?

Daarmee vervalt ook het backup- en corruptie-argument. Mijn inziens toch al geen valide argumenten, want een goede volledige backup heb je ten alle tijden nodig. Dng is vaak nog wel 10-20% kleiner dan een raw file, wat nooit kwaad kan.

Overigens schrijf ik al mijn origenele raw bestanden naar een aparte backup bij importeren, waarna ik uitsluitend verder werk met .dng (met een aparte backup daarvoor). Just in case.

[Ventieldopje]

Aikon schreef op donderdag 6 april 2017 @ 13:46:
Ik kan het nu niet testen, maar een .dng bestand veranderd niet telkens als je lightroom gebruikt. Tenzij je een ctrl+s doet. De aanpassingen zitten in de catalogus, niet in het .dng bestand?

Daarmee vervalt ook het backup- en corruptie-argument. Mijn inziens toch al geen valide argumenten, want een goede volledige backup heb je ten alle tijden nodig. Dng is vaak nog wel 10-20% kleiner dan een raw file, wat nooit kwaad kan.

Overigens schrijf ik al mijn origenele raw bestanden naar een aparte backup bij importeren, waarna ik uitsluitend verder werk met .dng (met een aparte backup daarvoor). Just in case.

Er is een instelling in Lightroom (en veel andere programma's) om automatisch wijzigingen in de metadata te schrijven naar XMP of in het geval van DNG naar de DNG zelf (zelfde geldt overigens voor TIFF, JPG etc.).

Het backup en corruptie argument zijn volgens jouw dus niet valide ... omdat je vind dat je altijd een full backup moet draaien? Ik geloof dat dit net het punt was... telkens een volle backup met DNG betekend dat je 99% van je data onnodig dupliceert.

[Aikon]

Je bedoeld 'automatically write changes to .xmp files' of iets dergelijks. Die zal je uit moeten zetten inderdaad, maar daarna zullen je .dng bestanden niet meer wijzigen en hoef je verder alleen je catalogus op te slaan.

Ik zal e.e.a. verder toelichten:

Corruptie is nou eenmaal iets is waar je altijd rekening mee moet houden, of je nu wel of geen .dng gebruikt. Een goede backup beschermt je tegen corruptie.

En of je nu .dng+catalogus of .raw+.xmp backupt maakt ook niks uit in feite, met beide heb je altijd een goede full backup nodig (nodig! dus niet perse altijd een full draaien). Hoe je die backup doet, altijd een full, wel of niet offsite en offline, ja dat staat er helemaal los van en is (deels) een persoonlijke voorkeur. Maar met .dng heb je iets minder totale data om te backuppen.

[Ventieldopje]

Aikon schreef op donderdag 6 april 2017 @ 14:01:
Je bedoeld 'automatically write changes to .xmp files' of iets dergelijks. Die zal je uit moeten zetten inderdaad, maar daarna zullen je .dng bestanden niet meer wijzigen en hoef je verder alleen je catalogus op te slaan.

Ik zal e.e.a. verder toelichten:

Corruptie is nou eenmaal iets is waar je altijd rekening mee moet houden, of je nu wel of geen .dng gebruikt. Een goede backup beschermt je tegen corruptie.

En of je nu .dng+catalogus of .raw+.xmp backupt maakt ook niks uit in feite, met beide heb je altijd een goede full backup nodig (nodig! dus niet perse altijd een full draaien). Hoe je die backup doet, altijd een full, wel of niet offsite en offline, ja dat staat er helemaal los van en is (deels) een persoonlijke voorkeur. Maar met .dng heb je iets minder totale data om te backuppen.

Het verschil is dus dat je de RAW data maar één keer hoeft te backuppen (archiveren), je kan hier om corruptie tegen te gaan een parity bestand bij aanmaken. Daarna full backups van je XMP (= weinig data).

Je hebt dus alleen een full backup nodig van je XMP's omdat dat de data is die verandert. Resultaat is dus snellere backups, geen afhankelijkheid van backup programma's en minder dubbele data.

[Aikon]

Ventieldopje schreef op donderdag 6 april 2017 @ 14:09:
[...]


Het verschil is dus dat je de dng data maar één keer hoeft te backuppen (archiveren), je kan hier om corruptie tegen te gaan een parity bestand bij aanmaken. Daarna full backups van je LR-catalogus (= weinig data).

Je hebt dus alleen een full backup nodig van je LR-catalogus omdat dat de data is die verandert. Resultaat is dus snellere backups, geen afhankelijkheid van backup programma's en minder dubbele data.

Zelfde voor .dng, zie je (door mij gewijzigde) quote.

[ Voor 194% gewijzigd door Aikon op 07-04-2017 15:15 ]

[ehtweak]

Geen ruzie maken jongens!

Niet om 't een of 't ander, maar ik backup van m'n (grafische werkstation)PC --> NAS m.b.v. Allway Sync. En ik heb de boel zo ingesteld dat altijd alles volledig gesynchroniseerd wordt, met 10 generaties/versies.
En ja, die NAS is alleen online voor back-uppen (en incidenteel voor restoren). In totaal staat er nu een paar Terabyte op, enige honderdduizenden files.
Zodat ik zelfs nog een aantal versies terug kan, mocht ik er b.v. een weekje later achterkomen dat die ene RAW toch niet weg kon, of dat ik die ene TIFF van voor een bepaalde bewerking nog wilde hebben.
En die hele inhoud van die NAS gaat op onregelmatige basis ook nog een keertje naar een stelletje externe losse HDDs.

En zelfs al verander ik tussen twee backup sessies in, in één keer een paar honderd RAW/NEF (b.v. metadata aanpassingen) files en afgeleide TIFFs (en die zijn toch gauw 40-100Mb/stuk), dan duurt de backup 10 minuten i.p.v. een paar minuten.
Who cares? Kwestie van je backup infrastructuur goed inregelen. Zo ben ik blij dat ik een goed werkende dual GB LAN-Team verbinding tussen m'n PC - switch - NAS heb (static link aggregation i.c.m. Intel i350 NICs, TPLinkSG3210; Static LAG, en NIC bonding op de Synology NAS)

Uiteraard heeft de allereerste backup ooit, wel ff geduurd. Maar nu worden alleen de veranderingen gesynchroniseerd (deletes, changes, new files).

Veel moeilijker/ingewikkelder hoeft het toch niet te zijn?

---

En wat de discussie van DNG versus RAW+XMP aangaat:
Sinds kort ben ik overgestapt van Nikons ViewNX-2 naar ViewNX-i
Waarbij ViewNX-2 de basale wijzigingen rechtstreeks in het NEF file toevoegde (daardoor werden ze altijd een stuk groter) versus dat ViewNX-i nu het NEF file onaangetast laat, maar een XML (xmpmeta) bestand in de vorm van [NEF file name].nksc aanmaakt, waar de wijzigingen ingezet worden.
Aan de ene kant lijkt het handig(er) dat de NEF files nu onaangeroerd blijven, aan de andere kant zit ik wel met de afhankelijkheid van dat een (RAW)foto eigenlijk nu uit TWEE bestanden bestaat; een .NEF en een .nksc file.

[ Voor 17% gewijzigd door ehtweak op 06-04-2017 15:14 ]

[Ventieldopje]

ehtweak schreef op donderdag 6 april 2017 @ 14:53:
Geen ruzie maken jongens!

Niet om 't een of 't ander, maar ik backup van m'n (grafische werkstation)PC --> NAS m.b.v. Allway Sync. En ik heb de boel zo ingesteld dat altijd alles volledig gesynchroniseerd wordt, met 10 generaties/versies.
En ja, die NAS is alleen online voor back-uppen (en incidenteel voor restoren). In totaal staat er nu een paar Terabyte op, enige honderdduizenden files.
Zodat ik zelfs nog een aantal versies terug kan, mocht ik er b.v. een weekje later achterkomen dat die ene RAW toch niet weg kon, of dat ik die ene TIFF van voor een bepaalde bewerking nog wilde hebben.
En die hele inhoud van die NAS gaat op onregelmatige basis ook nog een keertje naar een stelletje externe losse HDDs.

En zelfs al verander ik tussen twee backup sessies in, in één keer een paar honderd RAW/NEF (b.v. metadata aanpassingen) files en afgeleide TIFFs (en die zijn toch gauw 40-100Mb/stuk), dan duurt de backup 10 minuten i.p.v. een paar minuten.
Who cares? Kwestie van je backup infrastructuur goed inregelen. Zo ben ik blij dat ik een goed werkende dual GB LAN-Team verbinding tussen m'n PC - switch - NAS heb (static link aggregation i.c.m. Intel i350 NICs, TPLinkSG3210; Static LAG, en NIC bonding op de Synology NAS)

Uiteraard heeft de allereerste backup ooit, wel ff geduurd. Maar nu worden alleen de veranderingen gesynchroniseerd (deletes, changes, new files).

Veel moeilijker/ingewikkelder hoeft het toch niet te zijn?

---

En wat de discussie van DNG versus RAW+XMP aangaat:
Sinds kort ben ik overgestapt van Nikons ViewNX-2 naar ViewNX-i
Waarbij ViewNX-2 de basale wijzigingen rechtstreeks in het NEF file toevoegde (daardoor werden ze altijd een stuk groter) versus dat ViewNX-i nu het NEF file onaangetast laat, maar een XML (xmpmeta) bestand in de vorm van [NEF file name].nksc aanmaakt, waar de wijzigingen ingezet worden.
Aan de ene kant lijkt het handig(er) dat de NEF files nu onaangeroerd blijven, aan de andere kant zit ik wel met de afhankelijkheid van dat een (RAW)foto eigenlijk nu uit TWEE bestanden bestaat; een .NEF en een .nksc file.

Wat betreft het eerste, ik ben benieuwd naar de instellingen van je team. Onder linux kun je gewoon aan beide kanten een round-robin bond maken en dan vliegt het er overheen. Windows ondersteund dat helaas niet en met alle andere teaming modi blijft je snelheid grotendeels gelijk. Ik heb hier in mijn PC en NAS een 4x1Gbit netwerk kaart zitten van Intel, allemaal met korte kabels aangesloten op een 8-poort managed switch welke zowel static als dynamic port aggregation ondersteund. Het is snel, maar geen 4Gbit (of 2/2).

Het tweede, tsja ... ik hoor het meer mensen zeggen maar wat is nou écht het probleem van 2 bestanden die je altijd als één gebruikt?

[ehtweak]

Hoezo Windows 10 ondersteunt geen Link Aggregation?
Zie ook hier:
Win10 + dual Intel Pro 1000/PT --> geen VLAN/Teaming/ANS :-(
Win10 had in eerste instantie met de standaard MS Win10 drivers idd een issue met gebundelde NICs. Maar sinds dat Intel begin dit jaar een verse driver met ANS/Team/VLAN support heeft gereleased; werkt het met een aantal specifieke types NIC weer wel...

Terwijl het voorheen onder Win7 idd gewoon functioneerde.

Dus MET de juiste NICs, MET de juiste s/w support en met een switch die het ondersteund, in combinatie met b.v. een Synology NAS die NIC bonding biedt, en met Jumbo frames enabled (bij alle devices), kan het wel!

Als ik nu een fors aantal grote bestanden van m'n PC --> NAS synchroniseer, dan geeft de resource monitor een network I/O variërend zo tussen 650-980Mbps. Veel kleine bestanden geeft een lagere throughput, grote panorama files (honderden MB's of meer) geeft de hoogste throughput.
Linux kan ik niks over zeggen; daar heb ik geen ervaring mee.

---

Ventieldopje schreef op donderdag 6 april 2017 @ 21:32:

Het tweede, tsja ... ik hoor het meer mensen zeggen maar wat is nou écht het probleem van 2 bestanden die je altijd als één gebruikt?

Precies wat je zelf aangeeft.
Je zou denken dat het allemaal in één file zit, maar dat is dus niet zo. En dat xmpmeta file heeft weliswaar een gelijkluidende naamgeving, maar staat wel weer in een andere directory.
M.a.w. als je b.v. je RAW kopieert, dan mis/vergeet je iets. En moet je er dus aan denken om ook de bijbehorende xml file mee te nemen. Is gewoon niet handig imho.
En nee, al dat soort info in een catalog/databeest oid, dat hoeft voor mij al helemaal niet.

[ Voor 26% gewijzigd door ehtweak op 06-04-2017 23:56 ]

[Universal Creations]

ehtweak schreef op donderdag 6 april 2017 @ 23:41:
Je zou denken dat het allemaal in één file zit, maar dat is dus niet zo. En dat xmpmeta file heeft weliswaar een gelijkluidende naamgeving, maar staat wel weer in een andere directory.

Hoezo staat dat in een andere directory?

M.a.w. als je b.v. je RAW kopieert, dan mis/vergeet je iets. En moet je er dus aan denken om ook de bijbehorende xml file mee te nemen.

Verplaatsen/kopieren van raw-bestanden buiten Lr om is sowieso niet handig. Als je dit in Lr zelf doet, dan snapt Lr waar het bestand is en wordt de xmp meegenomen. Simpel.

[Aikon]

Ventieldopje schreef op donderdag 6 april 2017 @ 14:09:
[...]


Het verschil is dus dat je de .dng data maar één keer hoeft te backuppen (archiveren), je kan hier om corruptie tegen te gaan een parity bestand bij aanmaken. Daarna full backups van je LR-catalogus (= weinig data).

Je hebt dus alleen een full backup nodig van je LR-catalogus omdat dat de data is die verandert. Resultaat is dus snellere backups, geen afhankelijkheid van backup programma's en minder dubbele data.

Dit was mijn originele post, je quote maar dan aangepast, daar is niks geen ruzie aan. Ik geef op deze manier aan dat wat je zegt net zo hard opgaat voor .dng bestanden. Als je het daar niet mee eens bent, reageer je daar op of je laat het voor wat het is. Bizar dat je in plaats daarvan zomaar mijn post censureert.

[ehtweak]

Universal Creations schreef op vrijdag 7 april 2017 @ 01:09:
[...]

Hoezo staat dat in een andere directory?

Zoals ik zei...
Sinds kort ben ik overgestapt van Nikons ViewNX-2 naar ViewNX-i
Waarbij ViewNX-2 de basale wijzigingen rechtstreeks in het NEF file toevoegde (daardoor werden ze altijd een stuk groter) versus dat ViewNX-i nu het NEF file onaangetast laat, maar een XML (xmpmeta) bestand in de vorm van [NEF file name].nksc aanmaakt, waar de wijzigingen ingezet worden.
Aan de ene kant lijkt het handig(er) dat de NEF files nu onaangeroerd blijven, aan de andere kant zit ik wel met de afhankelijkheid van dat een (RAW)foto eigenlijk nu uit TWEE bestanden bestaat; een .NEF en een .nksc file.
Ik gebruik ViewNX-i en die zet de xml files in een aparte subdirectory (/NKSC_PARAM), onder de directory die de NEF files bevat.

Universal Creations schreef op vrijdag 7 april 2017 @ 01:09:

Verplaatsen/kopieren van raw-bestanden buiten Lr om is sowieso niet handig. Als je dit in Lr zelf doet, dan snapt Lr waar het bestand is en wordt de xmp meegenomen. Simpel.

Simpel; ik gebruik geen LR...

[Mr Pingu]

Ventieldopje schreef op donderdag 6 april 2017 @ 14:09:
[...]


Het verschil is dus dat je de RAW data maar één keer hoeft te backuppen (archiveren), je kan hier om corruptie tegen te gaan een parity bestand bij aanmaken. Daarna full backups van je XMP (= weinig data).

Je hebt dus alleen een full backup nodig van je XMP's omdat dat de data is die verandert. Resultaat is dus snellere backups, geen afhankelijkheid van backup programma's en minder dubbele data.

Toch is het fijn om zo wel in de XMP's als de catalogus je edits te hebben.
Ik backup om de week ongeveer mijn catalogus maar laatst ging deze corrupt aan het eind van die week. Als je dan veel edits hebt gedaan is het wel fijn dat je dat nog de XMP's ook te hebben. Enige wat ik kwijt raakte was de edit history.

[Universal Creations]

ehtweak schreef op vrijdag 7 april 2017 @ 09:51:
[...]

Zoals ik zei...
Sinds kort ben ik overgestapt van Nikons ViewNX-2 naar ViewNX-i
Waarbij ViewNX-2 de basale wijzigingen rechtstreeks in het NEF file toevoegde (daardoor werden ze altijd een stuk groter) versus dat ViewNX-i nu het NEF file onaangetast laat, maar een XML (xmpmeta) bestand in de vorm van [NEF file name].nksc aanmaakt, waar de wijzigingen ingezet worden.
Aan de ene kant lijkt het handig(er) dat de NEF files nu onaangeroerd blijven, aan de andere kant zit ik wel met de afhankelijkheid van dat een (RAW)foto eigenlijk nu uit TWEE bestanden bestaat; een .NEF en een .nksc file.
Ik gebruik ViewNX-i en die zet de xml files in een aparte subdirectory (/NKSC_PARAM), onder de directory die de NEF files bevat.


[...]

Simpel; ik gebruik geen LR...

Ok, duidelijk. Je gebruikt een wat onorthodoxe workflow met alle gevolgen van dien

[LegeBoekenkast]

Haha het wat niet mijn bedoeling om een compleet nieuw topic te starten, maar goed om te zien dat er veel discussie over plaats kan vinden!

Ik heb nooit met "gewone" RAW bestanden gewerkt. Voordat ik begon met werken met Lightroom heb ik veel gelezen en bekeken op youtube. O.a. Terry White en SLR Lounge hebben hier videos over gemaakt. De voordelen die benoemd werden spraken me erg aan, daaropvolgend heb ik eigenlijk nooit meer .CR2 gebruikt. Aangezien het originele RAW bestand wordt geïntegreerd in het .DNG bestand, zag ik dan ook niet echt nadelen.

Backups heb ik prima geregeld door middel van een bestand Sync over 2 harde schijven met en een online platform genaamd Crashplan. Het syncen en backuppen van kleine files is inderdaad stukken sneller, maar 30mb files zijn prima te doen.