ANNONS
Annons

vad händer med bilden....

Produkter
(logga in för att koppla)
Dajo skrev:
Jag flyttar alltid korten från kameran till datorn och får dom då samtidigt raderade.
ja ja, bra, det sättet funkar för dig.
jag respekterar det.
men för mig funkar det inte alls.
dels för att jag då sliter onödigt mycket på kamerabatteriet, och dels för att mina kameror är så pass gamla och långsamma att det faktiskt skulle ta flera timmar att läsa över alla mina kort efter en hel dags plåtning.
då kör jag hellre en dubbelt så snabb kortläsare.
och eftersom jag absolut inte riskerar mina bilder på något sätt (plåtar bröllop) så raderar jag dom alltid i kameran, inte i datorn.

kan vi lämna det här ämnet nu?
 
Rent tekniskt så ligger skillnaden på snabbformatering och vanlig radering i att en snabbformatering precis som sagts innan helt enkelt raderar toc:en, dvs table of contents eller filpekarna. En radering sätter endast filpekarna "ur funktion" dvs filen ligger kvar och pekaren likaså men den är inaktiverad. Det är av denna anledningen man enkelt kan ta tillbaka en fil som är raderad bara genom att ångra sig, så länge sagda fil inte blivit överskriven av en ny. Överskrivning ju tillåten i filsystemet då filen är markerad som raderad. Därav tar det även längre tid att radera än att snabbformatera. Eftersom snabbformateringen helt enkelt bara tar bort pekarna medans raderingen i själva verket kräver lite jobb då ju filerna ska markeras. Sen själva uppbyggnaden eg ser ut beror givetvis på filssystem och mig veterligen finns ingen egentlig standars för filsystem i digitalkameror. Den enda standard jag känner till är gränssnittet utåt mot datorn som gör det möjligt för datoranvändaren att se bilderna som ligger i kameran via datorn. Men vad som händer bakom det gränssnittet är som sagt mig veterligen upp till kameratillverkaren själv.
Missat nått?
 
Filsystemstandarder finns väl? Kör inte alla med någon FAT-format? (FAT12/FAT16/FAT32)

Eller va kanske inte så du menade med filsystem...
 
Det är framförallt äldre versioner av windows som kör detta filsystem. Nyare kör ntfs. Mac har ett eget. Likaså har Unix/linux egna filssystem. Det är dock fullt möjligt att kamerorna använder FAT, men på inget sätt en självklarhet. Eftersom det finns ett gränssnitt från kameran till datorn med exempelvis funktioner som lista alla objekt, radera markerade objekt osv. Detta gränssnitt innehåller alltså funktioner för datorn att använda när den är ansluten med kameran, men hur sedan kameran bär sig åt för att göra de begärda anropen har inte datorn med att göra och därmed kan det vara i princip ett "hemmabyggt" filsystem i kameran. Detta är inte bara möjligt utan även troligt då filsystemet i kameran inte har samma krav på sig som ett pc/mac operativsystem ställer på sitt filsystem och man brukar ju inte göra saker mer komplicerade än nödvändigt. Det ska dock tilläggas att jag inte har den blekaste aning om vad kamerorna faktiskt kör för filsystem.
 
Skulle med största sannolikhet gissa på att alla kameror som popar upp som en enhet i windows/mac/*nix kör med någon version av FAT.
Vet att äldre kameror var man tvungen att köra tillverkarens egna programvara för att komma åt bilder men nu förtiden är det nog inte så.

I regel så är det nog FAT12 på mindre minneskort och FAT32 på de lite större.

(FAT12 är det filsystem som gamla MS-DOS disketter har.)
 
Nikon kör iaf FAT på sina minneskort, skulle tro att de övriga tillverkarna med största sannolikhet gör det också. Min gamla Fujifilm från 2000 körde också FAT.

Finns ingen anledning att köra ett eget filformat och det skulle faktiskt komplicera det mer då kameran måste annars måste översätta det interna filsystemet i kameran till det datorn använder, samtidigt kortläsare och bärbara lagringsmedia bli nära nog oanvändbara då de inte skulle kunna läsa filsystemet på minneskortet från olika kameror utan drivrutiner, något som inte alla ens skulle bry sig om att ta fram.
 
FAT12?

Det torde vara _gamla_ kamror som skulle använda det :)

Gränsen för FAT12 är partitioner om 16mb.

Gränsen för FAT16 är 2048mb eller 2gb vilket skulle innebära att det är värdelöst att använda större kort än så.

FAT32 tillåter partitioner om 2tb ( teoretiskt i alla fall ) vilket väl borde bli 2000gb ungefär.

NTFS klarar samma som FAT32 i storlek. Vad gäller Mac och Unix har jag inte en suck.

Innebär detta att kamerorna kör FAT32 eller har tillverkarna löst det på annat sätt? Någon teknikkunnig som vet?

/Håkan E.
 
Tittade in på San-Disk sida och kunde läsa mig till att korten använder FAT file system som är kompatibelt med DOS. Det är då troligen FAT32

Angående NTFS kapacitet så är den så stor som
2^64 bytes (16 exabytes eller för att vara exakt 18,446,744,073,709,551,616 bytes).
Dvs 16000 PB eller 16000000 TB eller 16000000000 GB(många nollor blir det;) ). Overheaden, dvs platsen som går åt till själva filsystemet och inte blir lagringsbar yta för egna filer är också betydligt större i NTFS. Den ligger på ca 4 Mb / 100Mb lagringsyta. Bara lite teori...
 
Senast ändrad:
Skrev givetvis fel, vet inte varför ja nämnde FAT12. Klart det är FAT16 på de flesta minneskorten, större nyare minneskort (+2GB) har dok FAT32.

FAT32 har en annan lite mindre bra begränsning som inte NTFS/HFS+ eller Linux filsystem har, nämnligen så funkar det inge vidare å spara filer som är större än 4GB på en FAT32 disk, fast det e ju lite OT då det kommer å dröja ett tag tills varje bild är större än 4GB. :)
 
Om kameror formaterar korten i standardformat som FAT borde alltså korten funka att använda direkt i kameran om man formaterar dem med FAT med datorn via en kortläsare.
Som jag fattat det så måste korten formateras i kameran för att det ska funka.

Nån som provat?
 
japp, har testat å formatet ett xD-kort i Mac OS X till FAT16 format å det funkar i min kamera, dok så blev kortet väldigt segt.
 
Gutta skrev:
Det är framförallt äldre versioner av windows som kör detta filsystem. Nyare kör ntfs. Mac har ett eget. Likaså har Unix/linux egna filssystem. Det är dock fullt möjligt att kamerorna använder FAT, men på inget sätt en självklarhet. Eftersom det finns ett gränssnitt från kameran till datorn med exempelvis funktioner som lista alla objekt, radera markerade objekt osv. Detta gränssnitt innehåller alltså funktioner för datorn att använda när den är ansluten med kameran, men hur sedan kameran bär sig åt för att göra de begärda anropen har inte datorn med att göra och därmed kan det vara i princip ett "hemmabyggt" filsystem i kameran. Detta är inte bara möjligt utan även troligt då filsystemet i kameran inte har samma krav på sig som ett pc/mac operativsystem ställer på sitt filsystem och man brukar ju inte göra saker mer komplicerade än nödvändigt. Det ska dock tilläggas att jag inte har den blekaste aning om vad kamerorna faktiskt kör för filsystem.

Nästan alla digitalkameror kör med FAT.
 
Gutta skrev:
Tittade in på San-Disk sida och kunde läsa mig till att korten använder FAT file system som är kompatibelt med DOS. Det är då troligen FAT32

Angående NTFS kapacitet så är den så stor som
2^64 bytes (16 exabytes eller för att vara exakt 18,446,744,073,709,551,616 bytes).
Dvs 16000 PB eller 16000000 TB eller 16000000000 GB(många nollor blir det;) ). Overheaden, dvs platsen som går åt till själva filsystemet och inte blir lagringsbar yta för egna filer är också betydligt större i NTFS. Den ligger på ca 4 Mb / 100Mb lagringsyta. Bara lite teori...

Du kan nog lägga vilket filsystem du vill på ett CF-kort tex. Varför inte köra med ext3. Inte för att att kommer att gå att läsa i kameran, men det går att formatera kortet det för det filsystemet. NTFS också för den delen.
 
Re: FAT12?

Håkan Erlandsson skrev:
Det torde vara _gamla_ kamror som skulle använda det :)

Gränsen för FAT12 är partitioner om 16mb.

Gränsen för FAT16 är 2048mb eller 2gb vilket skulle innebära att det är värdelöst att använda större kort än så.

FAT32 tillåter partitioner om 2tb ( teoretiskt i alla fall ) vilket väl borde bli 2000gb ungefär.

NTFS klarar samma som FAT32 i storlek. Vad gäller Mac och Unix har jag inte en suck.

Innebär detta att kamerorna kör FAT32 eller har tillverkarna löst det på annat sätt? Någon teknikkunnig som vet?

/Håkan E.

Alla kameror som jag känner till som klarar STORA kort kör med FAT32.

FAT12 har en största clusterstorlek på 4kb vilket ger 16MB, FAT16 har en maximal clusterstorlek om 32kb vilket ger 2GB, FAT32 har en maximal clusterstorlek om 32kb vilket ger - orkar inte räkna.
 
epep skrev:
Du kan nog lägga vilket filsystem du vill på ett CF-kort tex. Varför inte köra med ext3. Inte för att att kommer att gå att läsa i kameran, men det går att formatera kortet det för det filsystemet. NTFS också för den delen.

och han skrev också

Alla kameror som jag känner till som klarar STORA kort kör med FAT32.

FAT12 har en största clusterstorlek på 4kb vilket ger 16MB, FAT16 har en maximal clusterstorlek om 32kb vilket ger 2GB, FAT32 har en maximal clusterstorlek om 32kb vilket ger - orkar inte räkna.

...du får läsa på lite...

http://support.microsoft.com/kb/310561/
http://support.microsoft.com/kb/310525/
http://support.microsoft.com/kb/100108/
...lr så förklarar jag...=)
Jag säger det igen. FAT är inget filsystem utan en filsystemsmetodik. Hur den är implementerad är till viss del upp till kodaren/designern. Det är riktigt som du säger att Fat16 bara stödjer 2 Gb, men detta gäller endast under MS-Dos. Använder man tex XP så är maximal storlek istället 4 GB och för FAT32 gäller då hela 8 TB max (maximal klusterstorlek 32kb * maximalt antal kluster 268435445). Hur bra en sådan partition sedan fungerar i praktiken är en annan fråga men den teoretiska gränsen går där.

Angående klusterstorlek är det något man väljer beroende på vilken typ av filer man tänker lägga på disken. Har man mycket små filer och då pratar vi 10 tusentals till 100 tusentals så ska man gå på mindre klusterstorlek eftersom man får mindre diskspill då. Använder man däremot disken till filer som bilder, mp3:eek:r eller filmer som är från ett par Mb uppåt så ska man köra med större klusterstorlek. Detta eftersom större filer gör att det helt enkelt inte får plats så många filer på disken och även om diskförlusten per fil blir större med större kluster så blir den totala diskförlusten ganska liten med så få filer. Vinsten är ett betydligt snabbare filsystem och mindre fragmentering. Varför? Ta en fil som består av ett antal kluster(från 1 till så många som är möjligt) och det sista klustert blir inte helt utnyttjat då filen inte är exakt lika stor som antalet kluster * klusterstorleken. Exempel
en fil är 18kb stor. Man har en klusterstorlek på 4kb. Då tar filen upp 20kb på disk eftersom 16kb(4 kluster * 4kb) inte räcker så får den ju ta ytterligare ett kluster på 4kb och det blir alltså 20kb. Vi har alltså förlorat 2kb på en fil. Om du räknar att du har en genomsnittlig förlust på just 2kb/fil vid klusterstorlek 4kb(sannolikhetslära) och har säg 250 000 filer så har du en diskförlust på 500Mb (250000*2). Men har du istället bara 10000 filer (bilder, mp3 eller dyl) så blir förlusten inte mer än 20Mb(10000*2) med 4kb kluster. Öka klusterstorleken till 32 kb och få ett betydligt snabbare filsystem som dessutom är mindre fragmenterat och därmed stabilere så får du på dina 10000 filer en diskförlust på (räknar då med en genomsnittlig förlust på 16 kb per fil) 160Mb(10000*16. Hänger du med? Har man förstått det så inser man också varför man ska ha stora kluster vid stora filer och små kluster vid många små filer? Har man flera diskar i sin burk så kan man alltså med fördel formatera sin operativsystemsdisk till en klusterstorlek på typ 4-8 kb men formatera sina bild/mp3/film/iso/... diskar till en klusterstorlek på tex 32-64kb(om det är möjligt, beroende på os och filsystem då)

Att man kan formatera sina kort till vilket filsystem som helst är ju ganska självklart, det är ju bara ett RAM. Men nyttan med det är ju som du själv säger ganska liten och det var inte heller det vi diskuterade utan vilket system man faktiskt använder? Detta vet jag fortfarande inte men flera andra har ju sagt att det är FAT32(inkl. du) vilket jag också tycker är troligt.

Sandisk erbjuder förövrigt en "flagga" för att sätta deras eget filsystem ur spel så man kan implementera ett eget. Detta gäller alltså för deras SDK (halvfärdig kod för utvecklare på svenska).
 
ursäkta det blev långt och tråkigt och inte helt i linje med ursprungsfrågan...men filsystem är avancerade grejor=)
 
Om vi bortser från diverse teknikaliteter så är det visst så att din bild kan tappa kvalitet när den flyttas (eller kopieras).

Om bilden från början är i jpeg-format så har kameran behandlat den (och tappat lite information). När du sedan pillar i photoshop och spar den igen (i jpeg-format) tappar bilden lite till och så vidare.

Om du bara flyttar runt/kopierar originalfilen tappar du inget.
 
Gutta skrev:
...du får läsa på lite...

http://support.microsoft.com/kb/310561/
http://support.microsoft.com/kb/310525/
http://support.microsoft.com/kb/100108/
...lr så förklarar jag...=)
Jag säger det igen. FAT är inget filsystem utan en filsystemsmetodik. Hur den är implementerad är

FAT är i väl ett filsystem som namngetts av FAT - file allocation table. Den datastruktur som bygger upp hela systemet. I början hade fat inga kataloger utan endast en "root" som kunde innehålla ett visst antal filer. Så är det fortfarande, även om jag inte kommer ihåg antalet filer, men jag tror det är 1024. Varje fil innehåller bla 2 olika uppsättningar information. Dels filnamnet och dels en pekare in i Filallokeringstabellen. Varje enhet (12, 16 eller 32 bitar) i tabellen motsvarar 1 bestämt kluster på hårddisken. Efter att filen i roten pekat ut den första "enheten" i FAT så följer en kedja där varje enhet i FAT pekar på nästa FAT-enhet som ingår i filen. Denna kedja motsvarar sedan som angivits direkt de kluster som filen hittas under. Underkataloger, dvs alla kataloger andra än roten, är egentligen vanliga filer men som har en katalog flagga. Operativsystemet tolkar sedan innehållet i dessa filer på samma sätt som det tolkar innehållet i rootkatalogen, dvs som filnamn med pekare in i fat osv. Så kom inte och snacka om att jag inte kan FAT. Och, på vilket sätt menar du att FAT inte är ett filsystem? Det är i allra högsta grad ett filsystem! Det är dessutom inte upp till den som kodar att välja hur FAT ska "implementeras" ur filsystemsperspektiv. Kodaren kan möjligen välja hur programkoden som ska använda ett FAT-filsystem ska se ut, men koden skall följa den information som finns ovan. Implementering följer sålunda till del direkt av ovan, dessutom skall de olika delarna enligt ovan ligga på bestämda ställen på hårddisken. Är det något av detta du inte förstår så finns en förträfflig beskrivning av hur FAT fungerar och var de olika delarna av filsystemet ska ligga på en hårddisk under:
http://en.wikipedia.org/wiki/File_Allocation_Table
Där ser du även sådan lågnivåinformation som byteoffset för de olika delarna av informationen. Så något utrymme för valfri implementering finns inte.
 
Senast ändrad:
ANNONS
Upp till 6000:- Cashback på Sony-prylar