mboost-dp1
Recovery af korrupt billed fil
Newz hjælp!!!
Mine svigerforældre har lige været 10 dage i Kina. De tog billeder med et lomme digitalkamera fra Canon. Nu er det kommet hjem og har fundet fejl på flere af billederne.
Jeg har fundet 2 typer fejl.
1. Noget af billedet er ikke genskabt (grå blok i noget af billedet)
2. Billedet kan ikke åbnes.
Fejltype 1 er billeder som er genskabt fra SD kortet med programmet CardRecovery.
Fejltype 2 er billeder som "bare" er kopieret ind fra SD-kortet men ikke kan vises.
Link til billed med fejltype 1: https://dl.dropbox.com/u/39020984/newz_recovery_Fe...
Link til billed med fejltype 2: https://dl.dropbox.com/u/39020984/newz_recovery_Fe...
Har I erfaring med programmer som kan løse fejlene? Det gør ikke noget hvis programmet koster lidt - men det må gerne være billigere end at tage til Kina igen. :P
Der er ca 200 billeder med fejl 2 og 50 med fejl 1.
Til info
Fejl 2 billederne er taget med et SDHC Sandisk Extreme 32 GB Class 10 kort (købt i Kina)
Fejl 1 billederne er taget med et billigt SD SIGMA 2 GB High Speed kort (købt i Metro i DK)
Anyone?
Mine svigerforældre har lige været 10 dage i Kina. De tog billeder med et lomme digitalkamera fra Canon. Nu er det kommet hjem og har fundet fejl på flere af billederne.
Jeg har fundet 2 typer fejl.
1. Noget af billedet er ikke genskabt (grå blok i noget af billedet)
2. Billedet kan ikke åbnes.
Fejltype 1 er billeder som er genskabt fra SD kortet med programmet CardRecovery.
Fejltype 2 er billeder som "bare" er kopieret ind fra SD-kortet men ikke kan vises.
Link til billed med fejltype 1: https://dl.dropbox.com/u/39020984/newz_recovery_Fe...
Link til billed med fejltype 2: https://dl.dropbox.com/u/39020984/newz_recovery_Fe...
Har I erfaring med programmer som kan løse fejlene? Det gør ikke noget hvis programmet koster lidt - men det må gerne være billigere end at tage til Kina igen. :P
Der er ca 200 billeder med fejl 2 og 50 med fejl 1.
Til info
Fejl 2 billederne er taget med et SDHC Sandisk Extreme 32 GB Class 10 kort (købt i Kina)
Fejl 1 billederne er taget med et billigt SD SIGMA 2 GB High Speed kort (købt i Metro i DK)
Anyone?
Jeg vil gerne prøve at hjælpe, men jeg er nok nødt til at selv prøve at læse kortene for at finde ud af noget. Jeg kan ikke finde ud af ret meget udfra de to filer du har uploadet. Har du mulighed for at komme forbi med kortene?
Var kameraet selv i stand til at vise billederne før I prøvede at sætte kortet i en computer?
Var kameraet selv i stand til at vise billederne før I prøvede at sætte kortet i en computer?
Jeg ved godt at det ikke løser problemet, eller hjælper på nogen måder, men for netop at undgå at sådan noget (eller andet ubehageligt), tømte jeg kortene flere gange dagligt, da jeg var på Island. Når man tager på sådan en tur, kan det altså godt betale sig at tage en lille computer med, og evt. købe en til rejsen.
Jeg er ved at lave et image af 32GB kortet. På denne computer plejer der at komme en ikon op for partitionen, når man sætter et SD kort i. Men det gjorde der ikke med dette kort. Den har ellers ikke haft noget problem med at læse partitionstabelen. Men det kan jo betyde så meget forskelligt.
Jeg håber indholdet af kortet kan komprimeres lidt, for der er kun 28GB fri på den disk jeg kopierer det over på. Indtil videre ser det dog ud til at dataene kan komprimeres lidt for godt.
Jeg håber indholdet af kortet kan komprimeres lidt, for der er kun 28GB fri på den disk jeg kopierer det over på. Indtil videre ser det dog ud til at dataene kan komprimeres lidt for godt.
Type 1: Tyder på der mangler dele af selve billedet. Altså 25% af billedet er der og så er de sidste 75% fucked data.
For header og det hele er der og tydeligvis noget af billedet.
Type 2: Filen er jævnt fucked. Hvis man åbner den i en hexeditor så er der ikke engang de tegn der angiver hvornår selve billeddataene begynder (0xffda / ÿÚ). Headeren ligner heller ikke en JPEG-header på nogen måde. Så den ligner en fejllæsning fra start til slut.
For header og det hele er der og tydeligvis noget af billedet.
Type 2: Filen er jævnt fucked. Hvis man åbner den i en hexeditor så er der ikke engang de tegn der angiver hvornår selve billeddataene begynder (0xffda / ÿÚ). Headeren ligner heller ikke en JPEG-header på nogen måde. Så den ligner en fejllæsning fra start til slut.
Hetman Photo Recovery:
http://peecee.dk/uploads/112012/14.jpg
Ligner den bare har trukket thumbnail ud af exif.
http://peecee.dk/uploads/112012/22.jpg
Ligner noget helt forkert offset. Ved at flytte/klippe lidt i billedet ser det da ud til at 80% af det kan genskabes.
http://peecee.dk/uploads/112012/14.jpg
Ligner den bare har trukket thumbnail ud af exif.
http://peecee.dk/uploads/112012/22.jpg
Ligner noget helt forkert offset. Ved at flytte/klippe lidt i billedet ser det da ud til at 80% af det kan genskabes.
Efter de første 1.600.000.000 bytes var blevet læst fra kortet fyldte den komprimerede fil kun 116.367.872 bytes. Nu hvor den indtil videre er kommet igennem 22.400.000.000 bytes af kortet er den komprimerede fil stadigvæk ikke blevet større.kasperd (4) skrev:Indtil videre ser det dog ud til at dataene kan komprimeres lidt for godt.
Jeg har fundet nogle af dataene fra fil nummer to inden for de 116.367.872 bytes. Lidt senere må jeg undersøge om hele den fil ligger der.
Alt i alt 33.553.383.424 bytes image komprimeret ned til 119.809.024 bytes. Nu prøver jeg at læse kortet igen med en anden kortlæser på en anden computer bare for at være sikker på at jeg får et identisk image ud af det.kasperd (7) skrev:Efter de første 1.600.000.000 bytes var blevet læst fra kortet fyldte den komprimerede fil kun 116.367.872 bytes.
Jeg har undersøgt indekset fra den komprimerede version en lille smule. Og indtil videre har jeg fundet en blok som gentages for hver 16MB. Dog gentages den ikke helt fra starten. Gentagelsen begynder først når man har paseret de første 96MB.
Hvis de to tal lægges sammen får man 117.440.512 bytes. Det er lige en anelse større end de 116.367.872 bytes jeg nævnte tidligere. Forskellen stemmer fint overens med hvad man ville forvente at opnå ved komprimering af de første 96MB af mediet.
Mit gæt nu er at kortet i virkeligheden kun er på 128MB og der er fusket lidt med adresselinjerne for at få det til at se ud som et 32GB kort. Det er dog gjort på en sådan måde at starten af mediet ikke bliver korrupt (så ville man have opdaget det meget hurtigt) og man kan for det meste læse det sidste par billeder man har taget, fordi de ikke er blevet overskrevet endnu. Og måske er der et område sidst på mediet som heller ikke bliver overskrevet, hvis jeg har ret i de 128MB, så ville der være 16MB tilbage til det formål.
På nuværende tidspunkt er ovenstående bare en hypotese. Du må vente til i morgen med at få svar på om den holder.
Hvis de to tal lægges sammen får man 117.440.512 bytes. Det er lige en anelse større end de 116.367.872 bytes jeg nævnte tidligere. Forskellen stemmer fint overens med hvad man ville forvente at opnå ved komprimering af de første 96MB af mediet.
Mit gæt nu er at kortet i virkeligheden kun er på 128MB og der er fusket lidt med adresselinjerne for at få det til at se ud som et 32GB kort. Det er dog gjort på en sådan måde at starten af mediet ikke bliver korrupt (så ville man have opdaget det meget hurtigt) og man kan for det meste læse det sidste par billeder man har taget, fordi de ikke er blevet overskrevet endnu. Og måske er der et område sidst på mediet som heller ikke bliver overskrevet, hvis jeg har ret i de 128MB, så ville der være 16MB tilbage til det formål.
På nuværende tidspunkt er ovenstående bare en hypotese. Du må vente til i morgen med at få svar på om den holder.
MD5 af det image jeg har gemt er: 9b679e53de0d3588d8b217425f901cd0
Den anden computer er stadig ved at læse kortet og beregne en MD5 som jeg kan sammenligne med.
Billedet starter med 220160 blokke af 512 bytes, som er i orden. Derefter er der 32768 blokke der gentages hele vejen indtil slutningen af mediet. Reel størrelse af mediet er tilsyneladende 123½MB.
Det vil sige at de samme blokke gentager sig 1993 gange og så kommer de første af blokkene lige en gang mere.
Den anden computer er stadig ved at læse kortet og beregne en MD5 som jeg kan sammenligne med.
Billedet starter med 220160 blokke af 512 bytes, som er i orden. Derefter er der 32768 blokke der gentages hele vejen indtil slutningen af mediet. Reel størrelse af mediet er tilsyneladende 123½MB.
Det vil sige at de samme blokke gentager sig 1993 gange og så kommer de første af blokkene lige en gang mere.
Så blev den anden computer færdig med at læse kortet og fandt samme checksum. Da jeg prøvede at læse filsystemet fik jeg nogle I/O fejl fordi der var pointere som pegede udenfor filsystemet. Sandsynligvis skyldes det at nogle metadata er blevet overskrevet med andre data.kasperd (10) skrev:Den anden computer er stadig ved at læse kortet og beregne en MD5 som jeg kan sammenligne med.
Der er sandsynligvis ikke ret meget mere at rede fra kortet, end hvad du allerede selv har fået ud fra det kort.
Minder mig om den her:
http://politiken.dk/tjek/digitalt/forbrugerelektro...
http://politiken.dk/tjek/digitalt/forbrugerelektro...
kasperd (10) skrev:Reel størrelse af mediet er tilsyneladende 123½MB.
kasperd (11) skrev:Der er sandsynligvis ikke ret meget mere at rede fra kortet, end hvad du allerede selv har fået ud fra det kort.
Hej igen Kasper,
Super flot arbejde!
Jeg melder videre at Sandisk kortet som skulle være 32 GB kun er på 123½ MB.
Har du noget info på de 2 Sigma kort?
Jeg fandt 29 ubeskadigede billeder på 123MB kortet:
Og to billeder, hvor starten af billedet var intakt:
Derudover er der 115KB som jeg ikke ved hvilke filer stammer fra. Da det kun udgør 4% af størrelsen på et enkelt billede er det ikke værd at arbejde videre med de 115KB:
Hvis der er wear leveling på kortet er der en teoretisk mulighed for at der ligger yderligere data gemt, som producenten af kortet ville være i stand til at tilgå. Chancen for at der er noget at komme efter er begrænset, og chancen for at finde ud af hvem der har produceret kortet er heller ikke specielt god.
9162d88cb74b12188f2ce486fd00bdb31c1cde2d IMG_2314.JPG
a0dbc6e95087b551a4b34cc622e7dad95681b8c1 IMG_2315.JPG
8410d94093d4c4c32c3c89eb1048e71f63bf1b66 IMG_2316.JPG
32d5644a3c7fe9ad52c4c3e59535ed766616973a IMG_2317.JPG
f3da7f214d6a87c38e0901dfbb64a719e7e5ada7 IMG_2318.JPG
a8695656f026ff83be63c05144606b987da87489 IMG_2319.JPG
26993e531281e3f970d5d98212ebd6e055b79d00 IMG_2320.JPG
c05f642a8b25987f0f72588239a16b974ce93178 IMG_2321.JPG
2a0d9f6c2c9ad78081d0690029e8937d92178704 IMG_2322.JPG
e896d5bb0d84325daed637f9d049aaa7ce581b1b IMG_2323.JPG
c91e52dbb1b2fc5d5a87781e75fe40a6c496285b IMG_2324.JPG
a1aa3d1d591faa6685e8a760f5e28d628a7eedd0 IMG_2325.JPG
3d33544d8a74e6c8827c5c1524b3a16c2291ae5a IMG_2326.JPG
61078a12cb022c2e2721a17ad508da8dcd489c49 IMG_2327.JPG
4eba0a3182bfc1c54368822d3a6566e1baf04098 IMG_2328.JPG
a3a1c9be8d54bc7d09843747b6623ace3a2ecc89 IMG_2329.JPG
63f4143b8587180be803d56288137a4ca5eeb0f0 IMG_2330.JPG
58eb0f335350d0182fdaee49cd3a3ee71cd9f852 IMG_2331.JPG
e0589ae26abb1c5ee4e0286788fec7a4c5180830 IMG_2332.JPG
15f03566fe282a18b5fd9868824daddf76394edb IMG_2333.JPG
e3e3815022ac6e09c3e69fb33e456431aeec79c2 IMG_2334.JPG
39700367a290f8bb943231efecaa061384fd6842 IMG_2336.JPG
37af9bf3029b5aba57ba4a977474d0e07ee1f93d IMG_2337.JPG
9ac8877f80fe14be10c62c21a04b11f01130cb2e IMG_2340.JPG
2fcc22b50245153dcf22fcac4aa8b4353cc28109 IMG_2511.JPG
2bebed27f981686754841041525d26d2e3b860b9 IMG_2512.JPG
55c5e3cafb05938d5c05a304c3f876c0cd8434aa IMG_2513.JPG
454a8fa8032abdafcd9d6cc47d557c804880e4f7 IMG_2514.JPG
a693d88fce2306b9828e1289b825225aa0ec370a IMG_2515.JPG
Og to billeder, hvor starten af billedet var intakt:
384dd010bcf4fd8b83a03d90e360de4fe6e21a36 IMG_2338.JPG
c90bde6d864ed0822a46b27baa3ed8a764b1ab99 IMG_2341.JPG
Derudover er der 115KB som jeg ikke ved hvilke filer stammer fra. Da det kun udgør 4% af størrelsen på et enkelt billede er det ikke værd at arbejde videre med de 115KB:
b7c974abf1e678e949ef577e547be3406c85536d remaining-sectors-a.bin
c7ae25a079702726bab0d359a21cbd0264cab413 remaining-sectors-b.bin
9d123fc29c387bc7d5b9a5cfcc21ba6cf8214840 remaining-sectors-c.bin
812846871dd40a67cd891b0681c7191c2b86e907 remaining-sectors-d.bin
27f7b5c8f77f60ef6253c92a96985887724c959b remaining-sectors-e.bin
Hvis der er wear leveling på kortet er der en teoretisk mulighed for at der ligger yderligere data gemt, som producenten af kortet ville være i stand til at tilgå. Chancen for at der er noget at komme efter er begrænset, og chancen for at finde ud af hvem der har produceret kortet er heller ikke specielt god.
Jeg har ikke kigget på dem endnu.Hr. Kejser (13) skrev:Har du noget info på de 2 Sigma kort?
De 29 ubeskadede billeder du har fundet har jeg fået reddet. De 2 hvor starten er intakt fik jeg også ud. At de er klippet forkert sammen og der er 2 billeder i 1 er bare øv.
Jeg tror godt vi kan skyde en hvid pil efter at få flere billeder ud af kortet.
Sig lige til når du har fået en chance for at kigge på Sigma kortene - for hvis de ikke er på 2 gb så skal Metro have dem igen.
Jeg tror godt vi kan skyde en hvid pil efter at få flere billeder ud af kortet.
Sig lige til når du har fået en chance for at kigge på Sigma kortene - for hvis de ikke er på 2 gb så skal Metro have dem igen.
Jeg bemærkede at det ene kort er partitioneret og det andet kort har et filsystem direkte på kortet. Det er der som sådan intet galt i, det er bare lidt overraskende at finde sådan en forskel på to tilsyneladende identiske kort som er købt sammen.Hr. Kejser (13) skrev:Har du noget info på de 2 Sigma kort?
Det ene sigma kort skulle formateres før jeg kunne tilgå det med mit recovery program. Det andet kort "virkede" fint bortset fra der kun var 86 MB data på disken.
Det er fordi de har ligget i slutningen af det gode område og lidt ind i det falske område. Dermed er slutningen af de to filer blevet overskrevet. At det er sket for to billeder og ikke kun et enkelt er nok fordi der er blevet slettet et billede.Hr. Kejser (15) skrev:At de er klippet forkert sammen og der er 2 billeder i 1 er bare øv.
IMG_2337.JPG er det sidste billede der har været plads til i det gode område. Dernæst er starten af IMG_2338.JPG skrevet i det gode område og slutningen i det falske område. IMG_2339.JPG er skrevet i det falske område og er gået totalt tabt.
Dernæst er der blevet slettet et billede. Jeg gætter på IMG_2335.JPG den gode plads der blev fri blev så brugt på IMG_2340.JPG og starten af IMG_2341.JPG.
Resten af billederne er skrevet i det falske område. At de sidste fem kunne redes er bare fordi der ikke er skrevet mere. De vil forsvinde, hvis der tilføjes flere filer på kortet.
Og evt. en sag om bedrageri. Et er at man kan komme til at sælge defekt hardware, det er bare hvad der sker. Men at sælge falsk hardware, hvor producenten bevidst har svindlet, bør man ikke slippe ustraffet fra. At blot få pengene igen er ikke en acceptabel kompensation.Hr. Kejser (15) skrev:hvis de ikke er på 2 gb så skal Metro have dem igen.
Og det er så derfor du skulle være kommet til mig, før du gik i gang.Hr. Kejser (17) skrev:Det ene sigma kort skulle formateres før jeg kunne tilgå det med mit recovery program.
Det gør ingen forskel om jeg bruger den ene eller den anden FAT. Jeg er nødt til at køre fsck.vfat to gange før filsystemet er helt repareret. Resultatet er dog ikke opmuntrende, idet man så bare står med et tomt filsystem.kasperd (19) skrev:fsck.vfat fortæller mig
En søgning med strings og grep afslører dog, at der er Exif headers på kortet. Så der er håb om at finde noget. Komprimeret med gzip bliver imaget 93MB, så der kan ikke være voldsomt mange data derpå.
Det andet Sigma kort fylder noget mere komprimeret, men jeg har ikke undersøgt det endnu.
Tilsyneladende fuldt ud gyldigt filsystem. Men tomt.kasperd (20) skrev:Det andet Sigma kort fylder noget mere komprimeret, men jeg har ikke undersøgt det endnu.
Det vil sige at for begge korts vedkommende er filsystemsmetadata ikke brugbare, og det er nødvendigt at sammensætte filerne manuelt ved at sætte blokke sammen fra mediet.
Det vil sige manuelt arbejde, og jo mere fragmenteret mediet er, des større arbejde er det. Og uden metadata er det ikke til at vide hvor fragmenteret mediet er.
Jeg afprøvede lige en hurtig heuristic til at få et overblik
Det gav mig en del linjer med
Men min heuristik til at identificere slutningen af en fil virker ikke. Er der nogen som kan gennemskue fejlen?
#include <stdio.h>
#include <unistd.h>
#include <inttypes.h>
#include <string.h>
int main()
{
uint8_t c=0;
uint8_t zero[512];
uint8_t buf[512];
memset(zero,0,512);
while(read(0,buf,512)==512) {
if(!memcmp(buf,zero,512)) {
putchar('.');
} else if ((buf[0] == 0xff) && (buf[1] == 0xd8)) {
putchar('(');
} else if (memcmp(buf+512-16,zero,16)) {
putchar('#');
} else {
putchar(')');
}
if (!((++c)&63)) putchar('\n');
}
return 0;
}
Det gav mig en del linjer med
(##))))))##(###############(####################################og imellem dem var der mange med
################################################################Tilsyneladende starter alle JPEG filerne på det kort på et multiplum af 32KB. Men hvis det er et FAT16 filsystem på 2GB, så må det også nødvendigvis bruge clusters på 32KB. Så måske bør jeg gentage heuristikken med 32KB ad gangen.
Men min heuristik til at identificere slutningen af en fil virker ikke. Er der nogen som kan gennemskue fejlen?
Dette er afsindigt grimt, men der kommer billeder ud af det:
#include <stdio.h>
#include <unistd.h>
#include <inttypes.h>
#include <string.h>
#include <assert.h>
#define BSIZE 32768
int main()
{
int c=0;
int fd=-1;
uint8_t buf[BSIZE];
while(read(0,buf,BSIZE)==BSIZE) {
if ((fd==-1) ||
((buf[0] == 0xff) && (buf[1] == 0xd8))) {
char name[99];
close(fd);
sprintf(name,"split-part-%d.jpeg",++c);
fd=creat(name,0666);
if (fd==-1) {
perror(name);
return 1;
}
}
assert(write(fd,buf,BSIZE)==BSIZE);
}
return 0;
}
En af de filer der kom ud af det er identisk med https://dl.dropbox.com/u/39020984/newz_recovery_Fe... så der er nok brugt ca. samme algoritme. Men jeg kan gøre det bedre, når jeg har bedre tid til det.kasperd (23) skrev:Dette er afsindigt grimt, men der kommer billeder ud af det
kasperd (19) skrev:Det ene Sigma kort indeholder et filsystem, som er 95% fyldt, selvom der ingen filer er på det. Har der nogensinde ligget nogle billeder på det kort?
Har haft kontakt med svigerforældrene og de har ikke haft brugt de 2 Sigma kort før de drog afsted.
#21-#24 - det lyder som et besværligt job. Tror du kortene er defekte?
I det mindste lyder det til at de vedkender sig deres ansvar. Jeg kan komme i tanke om flere virksomheder med en kundeservice på et lavere niveau end det.Chewy (12) skrev:Minder mig om den her:
http://politiken.dk/tjek/digitalt/forbrugerelektro...
Jeg kunne sagtens forestille mig at komme tilbage til en butik med sådan nogle kort, hvor de ansatte per automatik ville sige at det var min computer som er defekt og at kortene intet fejler.
En ting som kortproducenterne burde gøre var følgende. Lav en reklamevideo som er så lang at den næsten fylder hele kortet op. Beregn dernæst et hashtræ over denne video og sæt en digital signatur derpå. Dette hashtræ og signatur kan måske inkluderes i videofilen, hvis man vælger et format med mulighed for udvidelser.
Videoen lægges på nye medier. Og starter med at sige noget i retning med tillykke med dit nye 32GB kort.
Hvis producenterne gør det, så kan software på en computer eller på kameraet tage stikprøver af filen for at undersøge dens integritet.
På den måde vil det være umuligt at lave et forfalsket kort med lavere kapacitet og stadigvæk inkludere filen.
Når man så har sikret sig at det nyligt købte kort har den rigtige kapacitet, så sletter man selvfølgelig bare videoen, så man kan komme i gang med at fylde kortet op.
Jeg spekulerede bare på om fejlen havde været der fra start af, så de ikke kunne lægge noget på kortet fordi det var helt fyldt fra ny af.Hr. Kejser (25) skrev:Har haft kontakt med svigerforældrene og de har ikke haft brugt de 2 Sigma kort før de drog afsted.
Jeg har endnu ikke fundet nogen symptomer på at de to kort er defekte. Det ligner kun logiske fejl i filsystemet. De kan være opstået af så mange forskellige årsager, men vil nok kunne udbedres med en formatering.Hr. Kejser (25) skrev:#21-#24 - det lyder som et besværligt job. Tror du kortene er defekte?
Det ved jeg ikke. Mængden af data på de to kort er langt under 2GB. Der er ca. 450MB tilsammen på de to kort. Men jeg ved ikke om der vil kunne være 2GB på kortene. For at finde ud af det er jeg enten nødt til at finde nogle tydlige mønstre i de data der ligger derpå, eller overskrive kortene for at finde ud af kapaciteten.Hr. Kejser (27) skrev:Er kapaciteten på 2 GB?
Jeg vil ikke skrive til nogen af kortene før vi er sikker på at vi har fået fat i alle de data vi kan få ud af dem.
kasperd (28) skrev:Jeg vil ikke skrive til nogen af kortene før vi er sikker på at vi har fået fat i alle de data vi kan få ud af dem.
Modtaget!. :D
Jeg har fået genskabt nogle af billederne fra Sigma kortene. Jeg har bare ikke nogen metadata fra filsystemet. Det vil sige at jeg har hverken filnavn eller tidsstempel til dem. Er her nogen som kender et Linux værktøj til at finde et tidsstempel i en Exif header?
Det løber nok op i lidt over 512MB i alt. Hvis du vil have både arkivet med diskimages og selve billederne, så løber det op i det dobbelte, så hvis du har en USB stick med 1.5GB fri, så tag den med.
Det lyder fornuftigt. For at du ikke skal til at køre herud flere gange end nødvendigt, så lad os vente til jeg har noget klart til at kopiere på den.Hr. Kejser (32) skrev:Jeg kan bringe en USB stick til dig hvor vi kan lægge dataen på?
Det løber nok op i lidt over 512MB i alt. Hvis du vil have både arkivet med diskimages og selve billederne, så løber det op i det dobbelte, så hvis du har en USB stick med 1.5GB fri, så tag den med.
Nå, det står der jo som en tekststreng, så strings kommandoen kan barbere den gedkasperd (33) skrev:Er her nogen som kender et Linux værktøj til at finde et tidsstempel i en Exif header?
head -c32k "$F" | strings | grep ^2012: | head -1
SHA1 af nogle billeder jeg indtil videre har fået ud fra et af Sigma kortene:
Måske skal vi omdøbe filerne før du får dem kopieret. Jeg ved ikke om der stadigvæk er operativsystemer, der ikke kan lide : i filnavne.
f10635f7ec88074206f3de1d2beb6e7b2ce06de0 image-2012:11:15-13:00:26.jpegEt af billederne blev rekonstrueret ved et "uheld" fordi jeg fik sat nogle blokke sammen på en anden måde end jeg havde tænkt mig. Det billede har du nok ikke fået ud med det recovery værktøj, du har prøvet. Jeg ved ikke om du allerede har de andre af billederne.
5aaed8229f42ad61b35877b135859b46052f40f1 image-2012:11:15-13:02:12.jpeg
cc9e96eee97b87de655f68e9563a5548e78861a2 image-2012:11:15-13:03:56.jpeg
1dedc5f94e8d19c1bc0b65f86d706e8c533e512a image-2012:11:16-02:38:03.jpeg
8d7eddbc0cb9bf53fad33692591d9d7ed7ebe8d0 image-2012:11:16-02:38:11.jpeg
cf8cfb8793b61a63999948f95c79620e7d5f2093 image-2012:11:16-02:39:22.jpeg
ab306f4d61edb3d90034ea29dfc461e712b7fb8e image-2012:11:16-02:44:38.jpeg
15c8418a2ab1132fb746bf6c51a71ae0e00986e1 image-2012:11:16-03:44:04.jpeg
ce1ab187386a6379d403d8681623f1d8dfd3f04e image-2012:11:16-03:48:56.jpeg
ec34026de9aeb18114ceb9221bc5533fc2d6c9ad image-2012:11:16-03:49:23.jpeg
538f29a89662af2f4ffab6607241b228decbc88f image-2012:11:16-04:11:50.jpeg
f0aa5cdf67dcc95e49a08eb9a7c1937076f92071 image-2012:11:16-05:39:40.jpeg
9c6f1e33260c091933d4e7f651f0669c431db240 image-2012:11:16-06:01:05.jpeg
Måske skal vi omdøbe filerne før du får dem kopieret. Jeg ved ikke om der stadigvæk er operativsystemer, der ikke kan lide : i filnavne.
Er der et Linux værktøj som kan gøre det? Det ville hjælpe noget på det puslespil jeg sidder med fra det andet Sigma kort. Det er lidt svært at finde ud af hvor brikkerne skal side, når man ikke har et billede af det samlede puslespil.Ronson (6) skrev:Ligner den bare har trukket thumbnail ud af exif.
Det kan den sørme også. Denne metode virkede for mig: http://www.imagemagick.org/discourse-server/viewto...BurningShadow (36) skrev:Uden at være sikker, så mener jeg at ImageMagic kan gøre det.
Ved at sammenligne thumbnails fra exif headerne med de brudstykker jeg har fundet uden header har jeg fundet ud af, hvilke filer de fleste brudstykker hører til.
Desværre viser det sig, at de brudstykker der kunne redes er hhv. toppen og bunden af en fil, hvor et betydeligt stykke mangler i midten. Resultatet er ikke særligt brugbart.
Det vil sige at den eneste tilbageværende løsning jeg kan få øje på er at bruge oplysninger fra thumbnail til at placere den nederste del af billedet korrekt og korrigere farverne. (På grund af den måde jpeg fungerer på bliver farverne forskudt, hvis en del af de komprimerede data mangler). Til sidst kan man udfylde den manglende del af billedet ved at opskallere thumbnail.
Jeg ved ikke om man kan få et pænt resultat ud af det. Og jeg ved ikke nær nok om jpeg til at skrive koden til det.
Desværre viser det sig, at de brudstykker der kunne redes er hhv. toppen og bunden af en fil, hvor et betydeligt stykke mangler i midten. Resultatet er ikke særligt brugbart.
Det vil sige at den eneste tilbageværende løsning jeg kan få øje på er at bruge oplysninger fra thumbnail til at placere den nederste del af billedet korrekt og korrigere farverne. (På grund af den måde jpeg fungerer på bliver farverne forskudt, hvis en del af de komprimerede data mangler). Til sidst kan man udfylde den manglende del af billedet ved at opskallere thumbnail.
Jeg ved ikke om man kan få et pænt resultat ud af det. Og jeg ved ikke nær nok om jpeg til at skrive koden til det.
Jeg lavede lige manøvren med et enkelt billede. I alt er der 13 billeder, hvor jeg synes det kan betale sig at beskære det på den måde.kasperd (39) skrev:Der er også nogle enkelte billeder, hvor der er nok i toppen, til at billedet sagtens kan se brugbart ud, hvis bare man får klippet den nederste del af. Jeg ved ikke lige hvor meget der skal manipuleres med jpeg headeren for at realisere det.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Support
Gå til bund