Reparera felande digitala foto-filer (NEF), bästa sätt?

Permalänk
Medlem

Reparera felande digitala foto-filer (NEF), bästa sätt?

Jag har problem med ett tjugotal foton, som jag inte kan öppna eller se längre, och behöver hjälp med att återställa, om möjligt.

För ett par år sedan tog jag ett stort antal foton med min Nikon systemkamera. Fotona sparades på mitt chip i kameran, i RAW-format, s.k. NEF-filer. Dessa filer överförde jag sen till SSD-disk på datorn (Win10) och gjorde även backups på. Idag kan jag fortfarande öppna och använda alla NEF-filerna, utom ca 20 stycken. Jag vet inte vad som hänt, annat än att dessa filer har inte ens använts på annat sätt än att öppna och titta på dom, liksom alla andra filer har.

Dessa 'felande' filerna, visas inte längre som thumbnail i explorer, och kan inte heller öppnas- eller ens förhandsgranskas av något annat grafikprogram. Alla programmen säger liknande, att det är okänt eller fel format på filen jag försöker öppna. Windows självt säger att jag behöver installera stöd för att visa s.k. RAW-filer, och hänvisar mig till Microsoft Store för nedladdning. Men detta är fel, eftersom jag kan se thumbnails och även öppna alla andra NEF-filer direkt i Windows förhandsgranskning.

Dom felande NEF-filerna har inga andra indikationer på fel som jag kan se. Dom är lika stora i storlek som alla andra foton med. Jag anar att det här skulle kunna vara möjligt att 'fixa' på något sätt, eftersom datan finns troligast där men något verkar ha blivit fel i hur filen deklareras för programmen som försöker öppna dom.

Tänkte fråga om detta och se om någon här känner igen problemet?
Eller om det finns program/metoder för analys av råa fotofiler, som skulle kunna visa/avslöja/redigera till formateringsfel eller liknande problem som kan ha uppstått i filerna.

Tackar så mycket för alla former av kommentarer

Permalänk
Forumledare

@Dooley: Nu var det ett tag sedan (i.e åratal) jag råkade ut för liknande problem men då var det oftast möjligt att få ut iaf en högupplöst jpeg från filen.

Vilken kamera använder du? Vissa program stödjer vissa kameror har jag för mig

Permalänk
Medlem

@NordhNet Det låter ju lovande Bilderna är tagna med en Nikon D90.
Jag 'tror' att dom här bilderna funkade utmärkt att se och använda i början, och då menar jag på datorn, för jag använder inte bilderna med kameran alls. Jag bara fotar, sen flyttar jag över dom på datorn direkt. Det är mest nu som jag märkt att enstaka bildfiler inte går att se.

Permalänk
Rekordmedlem

Låter som nån typ av bitröta pga dåliga lagringsmedia, gör aldrig backuper till halvledarbaserad lagring för den är i de allra flesta fall (om inte alla) självraderande över tid.
Arkivering/långtidslagring bör göra på magnetiska elerl optiska media med redundans (paritetskontroll och dessutom i flera exemplar)

Permalänk
Medlem

Har du tittat med någon hex-editor om det finns något meningsfullt i filerna som krånglar - filnamnen är kvar, storleken är korrekt men så är de bara fyllda med '0' tex.

en annan trix är att komprimera filen - blir det inget kvar i komprimerad mode så är filen rätt tom.

Filer som är fyllde med 'nonsens'/slumpvärden är dock svåra att skilja från riktiga filer då alla moderna lagringsformat komprimerar filer på olika sett - även RAW-filer entropikomprimeras på olika sätt så att resultatet ser rätt mycket som 'nonsens' och krymper väldigt lite vid en ytterligare kompression.

När det är tom innehåll så är det ofta resultatet av bitröta - kanske redan på SD-minnen vid första överföringen eller så har det blivit i senare hantering.

Till skillnad från när man läser filer från SSD/snurrdiskar och optisk media får man ingen varning om datat som läses ur SD-minne (och även många USB-stickor) när man har läsfel och datat är ersatt med '0' eller nonsens/slump - vilket var en situation som inte fick hända med tape, magnetdisklagring och floppy och optisk lagring, men dessvärre breder ut sig i flash-lagring som inte är bundna till protokoll som SATA/SAS (och förhoppningsvis också NVMe) för att man en gång i tiden antog att flash-minnen för framförallt medialagring (som SD-minne men även dess föregångare i MMC-gränssnittens värld) aldrig gör fel och ingen mekanism att rapportera tillbaka när det ändå är fel - och så blir det skit när det är lägsta kvalitens Flash i TLC och QLC som stoppas i dessa och i USB-stickor.

Permalänk
Medlem
Skrivet av mrqaffe:

Låter som nån typ av bitröta pga dåliga lagringsmedia, gör aldrig backuper till halvledarbaserad lagring för den är i de allra flesta fall (om inte alla) självraderande över tid.
Arkivering/långtidslagring bör göra på magnetiska elerl optiska media med redundans (paritetskontroll och dessutom i flera exemplar)

Jag tänkte komma lite till det du talar om. Det här har drabbat flertalet bildfiler i "Mina bilder" mappen med, och jag har tänkt tanken att det är SSD som kan vara boven. Jag måste nog bättra på min backup lite. Just nu kör jag ren rak synkning, speglar mappstrukturen på extern backup. Och det innebär ju att jag kopierar över även dom 'rötiga' filerna och kan sen inte återställa dom. Jag backar dock upp på skivdisk.

Det sjuka är att jag körde ut en SHA3-512 checksumma på alla bildfilerna jag talar om ovan. Och även fast nu flertalet bilder inte längre är användbara som förut, så matchar dom ändå 100% vid SHA verifiering. Känns lite UFO för mig faktiskt.

Finns det mjukvarulösningar som utför paritetskontroll vid/efter överföringar, eller är det enbart hårdvaru för RAID och liknande? Tänkte om det kanske fanns backupprogram som utför paritetskontroll eller andra fördelaktiga redundans-kontroller. Blev lite mörkrädd när inte ens SHA3-512 verkar kunna identifiera att det finns en skillnad.

Permalänk
Medlem
Skrivet av Dooley:

Jag tänkte komma lite till det du talar om. Det här har drabbat flertalet bildfiler i "Mina bilder" mappen med, och jag har tänkt tanken att det är SSD som kan vara boven. Jag måste nog bättra på min backup lite. Just nu kör jag ren rak synkning, speglar mappstrukturen på extern backup. Och det innebär ju att jag kopierar över även dom 'rötiga' filerna och kan sen inte återställa dom. Jag backar dock upp på skivdisk.

Det sjuka är att jag körde ut en SHA3-512 checksumma på alla bildfilerna jag talar om ovan. Och även fast nu flertalet bilder inte längre är användbara som förut, så matchar dom ändå 100% vid SHA verifiering. Känns lite UFO för mig faktiskt.

Finns det mjukvarulösningar som utför paritetskontroll vid/efter överföringar, eller är det enbart hårdvaru för RAID och liknande? Tänkte om det kanske fanns backupprogram som utför paritetskontroll eller andra fördelaktiga redundans-kontroller. Blev lite mörkrädd när inte ens SHA3-512 verkar kunna identifiera att det finns en skillnad.

För att reda ut detta lite, du har sparade hashar från när filerna var hela och fungerade? Och när du nu jämför med filernas nuvarande hashar så matchar de fortfarande?

I så fall finns det väl god anledning att tro att filerna är oförändrade jämfört med när de fungerade, och att det då kanske är något som skiljer med mjukvaran som ska läsa dem. Är det helt säkert att:

Skrivet av Dooley:

Dessa 'felande' filerna, visas inte längre som thumbnail i explorer, och kan inte heller öppnas- eller ens förhandsgranskas av något annat grafikprogram. Alla programmen säger liknande, att det är okänt eller fel format på filen jag försöker öppna. Windows självt säger att jag behöver installera stöd för att visa s.k. RAW-filer, och hänvisar mig till Microsoft Store för nedladdning. Men detta är fel, eftersom jag kan se thumbnails och även öppna alla andra NEF-filer direkt i Windows förhandsgranskning.

inte är lösningen?

Permalänk
Medlem
Skrivet av xxargs:

en annan trix är att komprimera filen - blir det inget kvar i komprimerad mode så är filen rätt tom.

Filer som är fyllde med 'nonsens'/slumpvärden är dock svåra att skilja från riktiga filer då alla moderna lagringsformat komprimerar filer på olika sett - även RAW-filer entropikomprimeras på olika sätt så att resultatet ser rätt mycket som 'nonsens' och krymper väldigt lite vid en ytterligare kompression.

När det är tom innehåll så är det ofta resultatet av bitröta - kanske redan på SD-minnen vid första överföringen eller så har det blivit i senare hantering.

Zippade just ett antal av dom bilderna som inte funkar. Dom är ca 11mb stora, vilket även dom fungerande filerna är. Dom fungerande bildfilerna blir knappt 10mb när jag zippat dom. Men zippar jag dom icke fungerande, så blir dom alla 10,4kb.

Fan, verkar alltså som det gått sork i systemet då? SSD-sork.

Permalänk
Medlem
Skrivet av Dooley:

Zippade just ett antal av dom bilderna som inte funkar. Dom är ca 11mb stora, vilket även dom fungerande filerna är. Dom fungerande bildfilerna blir knappt 10mb när jag zippat dom. Men zippar jag dom icke fungerande, så blir dom alla 10,4kb.

Fan, verkar alltså som det gått sork i systemet då? SSD-sork.

Det där låter ju klart misstänkt... är du säker på att hashvärdena är från tiden då filerna var hela?

Permalänk
Rekordmedlem
Skrivet av Dooley:

Jag tänkte komma lite till det du talar om. Det här har drabbat flertalet bildfiler i "Mina bilder" mappen med, och jag har tänkt tanken att det är SSD som kan vara boven. Jag måste nog bättra på min backup lite. Just nu kör jag ren rak synkning, speglar mappstrukturen på extern backup. Och det innebär ju att jag kopierar över även dom 'rötiga' filerna och kan sen inte återställa dom. Jag backar dock upp på skivdisk.

Det sjuka är att jag körde ut en SHA2-512 checksumma för alla bildfilerna jag talar om ovan. Och även fast nu flertalet bilder inte längre är användbara som förut, så matchar dom ändå 100% vid SHA verifiering. Känns helt UFO för mig faktiskt.

Finns det mjukvarulösningar som tillför paritetskontroll vid/efter överföringar, eller är det enbart hårdvaru för RAID och liknande?

Parchive https://en.wikipedia.org/wiki/Parchive är en metod för att verifiera och korrigera fel med matematiska metoder i mjukvara, men man bör ju ändå ha lite vett och inte lagra allt på en och samma disk/nas för havererar den är kanske även korrektionsfilerna skadade men har man Par-filer och själva datan på flera olika lagringsenheter så bör det gå att pussla ihop det även om det är skador på en enhet. Man kan alltså använda parfiler oberoende av filsystemet och lagringsmetoden som ett extra skyddslager och systemen kan verifiera och reparera fel, hur mycket fel det kan korrigera beror på hur mycket par-block man skapar.
https://hp.vector.co.jp/authors/VA021385/
https://github.com/Yutaka-Sawada/MultiPar

Permalänk
Medlem
Skrivet av evil penguin:

För att reda ut detta lite, du har sparade hashar från när filerna var hela och fungerade? Och när du nu jämför med filernas nuvarande hashar så matchar de fortfarande?

Det är min uppfattning att jag skapade hashen direkt när jag förde över filerna till datorn (från kamera-chipet).

Men om mitt ovanstående inlägg - kl 00:20, från Xxargs teori - stämmer, då ... borde väl SHA3-512 kunnat identifiera detta, tycker jag. Det måste väl i så fall ha varit att jag skapade hashfilen typ några dagar efteråt, fullt övertygad om att alla NEF-filerna fortfarande var fungerande, vilket ett fåtal av dom kanske inte var då.

SHA3-512 checksum-filen är dock skapad samma dag som filerna, ser jag nu, men dock många timmar senare samma dag.

Nog borde väl SHA3-512 kunna märka av ifall alla filerna blivit bara digitalt mos, dvs bara nollor el dyl?

Permalänk
Rekordmedlem
Skrivet av Dooley:

Ja, det är min uppfattning att jag skapade hashen direkt när jag förde över filerna till datorn (från kamera-chipet).

Men om mitt ovanstående inlägg - kl 00:20, från Xxargs teori - stämmer, då ... borde väl SHA3-512 kunnat identifiera detta, tycker jag. Det måste väl i så fall ha varit att jag skapade hashfilen typ några dagar efteråt, fullt övertygad om att alla NEF-filerna fortfarande var fungerande, vilket ett fåtal av dom kanske inte var då.

För nog borde väl SHA3-512 kunna märka av ifall alla filerna blivit bara digitalt mos, dvs bara nollor el dyl?

Jo men är du säker på att första överföringen från minnet i kameran funkade ok ? Det kan ibland vara lömskt, tex att du sett en jpg-icon och inte nef filen, har du alltså verkligen öppnat den överförda filen så du vet satt den överförts ok från första början ?

Permalänk
Medlem
Skrivet av mrqaffe:

Jo men är du säker på att första överföringen från minnet i kameran funkade ok ? Det kan ibland vara lömskt, tex att du sett en jpg-icon och inte nef filen, har du alltså verkligen öppnat den överförda filen så du vet satt den överförts ok från första början ?

Det börjar luta åt att något sånt verkar vara fallet. När jag flyttade över fotona från chipet till disken, så kollade jag inte precis alla filer för 100% funktionalitet, eftersom det är så många, över 100st, och jag tyckte man borde väl (för f-n) kunna lita så pass mycket på systemet.

Jag kommer ihåg tydligt att jag använde Windows Explorers inbyggda funktion för att visa alla filer som "Extra stora ikoner" i mappen, för att se att det dök upp en preview på alla filerna. Jag brukar göra så. Då hade jag garanterat sett/märkt ifall några såg ut som dom gör nu, dvs bara en vanlig JPG-symbol-ikon, och inte en preview.

Verkar rimligt att tro att något hänt mellan tidpunkten då jag överförde från chipet och senare skapade hash-filen. Svordom!

Filerna låg lagrade på en Kingston UV400, 500gb SSD med standard Windows NTFS partition på. Jag flyttar över dom till en mekanisk disk just nu, för att rädda upp lite vad som räddas kan.

Permalänk
Rekordmedlem
Skrivet av Dooley:

Det börjar luta åt att något sånt verkar vara fallet. När jag flyttade över fotona från chipet till disken, så kollade jag inte precis alla filer för 100% funktionalitet, eftersom det är så många, över 100st, och jag tyckte man borde väl (för f-n) kunna lita så pass mycket på systemet.

Jag kommer ihåg tydligt att jag använde Windows Explorers inbyggda funktion för att visa alla filer som "Extra stora ikoner" i mappen, för att se att det dök upp en preview på alla filerna. Jag brukar göra så. Då hade jag garanterat sett/märkt ifall några såg ut som dom gör nu, dvs bara en vanlig JPG-symbol-ikon, och inte en preview.

Verkar rimligt att tro att något hänt mellan tidpunkten då jag överförde från chipet och senare skapade hash-filen. Svordom!

Filerna låg lagrade på en Kingston UV400, 500gb SSD med standard Windows NTFS partition på. Jag flyttar över dom till en mekanisk disk just nu, för att rädda upp lite vad som räddas kan.

Ska du flytta viktiga filer så kopiera och verifiera dem innan du raderar något i stället för att använda klipp ut och klistra in, det går att göra på flera olika sätt via separata program eller tex xcopy https://docs.microsoft.com/en-us/windows-server/administratio...

Permalänk
Medlem

Att sha256 skulle missa en förändrad fil är osannolikt, ja det händer inte kort sagt, så hade du skapat hash-filer direkt efter överföring så har det inte hänt något i filhanteringen efterhand utan felen fanns redan när du tömde SD-minnet från kameran.

Och nej, du kan inte lita på någon förhandsvisning eller thumb då det brukar vara cachat någonstans som minibild i eller utanför raw-filen utan du måste öppna _varenda_ fil och kontrollera att innehållet är intakt efter att du kopierat (obs kopiera - inte flytta filen) från SD-minnet. det finns inga genvägar då en hash-summa kan inte avgöra om filen har något vettigt i sig eller inte.

Snabbmetoden som verkade fungera att avgöra om filen har innehåll eller är tomma verkar vara att prova att komprimera en kopia av filen.

När det gäller varför det blir fel i SD-minnet är att bra sådan som har minneschip som tål lika många skrivningar som en chip för kvalitativ SSD så kostar de 10 ggr mer per GB än det du köper i gubbdagis som kingston och sandisk - vi pratar om industriklassade SD, de har förvisso inte bättre felhantering än innan men kvaliten på använda minneschip är väldigt mycket högre och bättre kontrollers och därmed mindre risk för fel.

Man skall komma ihåg att det som säljs i affärerna är botten på hinken av minneschip som ingen annan vill betala något för då SD-minnen och USB-stickor är avfallshantering av flashminne som inte duger till något annat och vi betalar för det...