Nja, det är väl snarare så att vi får hoppas att Arne inte känner alltför stort behov av att härma varje inlägg han läser på detta forum.
Herr Chang har talat.
Mja, det är väl snarare så att vi får hoppas att Fodervärden inte känner alltför stort behov av att kommentera varje inlägg jag skrivet på detta forum.
Retstickan Arne
Korrekt, och ju mindre komprimerat ergo ju mindre skit av resultatet
Vadå?
Dålig musik blir ju inte bättre genom mindre komprimering och inte blir ett ansikte på bilden vackrare m.h.a. några fler bytes.
//Singha711
Vadå?
Dålig musik blir ju inte bättre genom mindre komprimering och inte blir ett ansikte på bilden vackrare m.h.a. några fler bytes.
//Singha711
Exakt, och din avatar är ett jättebra exempel på detta 
Exakt, och din avatar är ett jättebra exempel på detta
Ja exakt, och skönheten lär ju komma innifrån och definitivt inte utifrån som tex en flaska Chang Beer.
Prova med Singha nästa gång, så får du kollar skillnaden i spegeln.
Lycka till!
//Singha
Ja exakt, och skönheten lär ju komma innifrån och definitivt inte utifrån som tex en flaska Chang Beer.
Prova med Singha nästa gång, så får du kollar skillnaden i spegeln.
Lycka till!
//Singha
Prova med att dricka en Singha, byt sedan till en Chang, prova sen att ta en Singha igen...
Omöjligt, går att byta från Singha till Chang men inte tillbaka av en enkel anledning.
Chang smakar öl!!! 
Prova med att dricka en Singha, byt sedan till en Chang, prova sen att ta en Singha igen...
Omöjligt, går att byta från Singha till Chang men inte tillbaka av en enkel anledning.
Chang smakar öl!!!
Vadå byta?
Jag börjar med en Singha, sen kollar jag i spegeln om jag har blivit vackrare. Om så är fallet, tar jag en Singha till. Och så går jag till spegeln igen tills jag har blivit helt oemotståndlig .
En gång fick jag av misstag en flaska Chang. I god tro svepte jag ner den och jag tyckte väl att det smakade nåt vidrigt besk. Men jag var ganska ”vacker” i det läge, så jag brydde mig inte så mycket om det då. Därefter kollade jag i spegeln igen. FyyyyFaaaaan, vilken ful gubbe som tittade på mig då!
Jag gör aldrig om detta misstag igen!
P.S. Titta på en fotbollsmatch och byt till Singha när ditt lag håller på att förlora. Det funkar!
//Singha711
P.S. Titta på en fotbollsmatch och byt till Singha när ditt lag håller på att förlora. Det funkar!
Mitt lag håller på att förlora? Fotboll borde förbjudas
Mitt lag håller på att förlora? Fotboll borde förbjudas
Ja exakt, det finns inga dåliga fotbollslag, det finns bara dålig öl!
P.S. Har Gudrun övergivit dig? Prova med en Singha, det kanske hjälper...
//Singha711
Tror Gudrun håller på med att läsa på om jpg och kluster just nu
Tror Gudrun håller på med att läsa på om jpg och kluster just nu
Jag tror att Gudrun kan sin sak men hon kanske leker "Sant eller Falskt" med MPR.
//Singha711
Ingen aning om vad Gudrun kan eller ej Singha711, kan inte läsa in i andras hjärnor.
"Hon" har ju dock vänt från att en jpg skall ha lager till att där inte finns några, men "hennes" långa inlägg är ju fortfarande bla bla bla och påhitt. Säger som NoBuzz, kul att läsa dom 
Ingen aning om vad Gudrun kan eller ej Singha711, kan inte läsa in i andras hjärnor.
"Hon" har ju dock vänt från att en jpg skall ha lager till att där inte finns några, men "hennes" långa inlägg är ju fortfarande bla bla bla och påhitt. Säger som NoBuzz, kul att läsa dom
Det tror jag är en missuppfattning.
Om man jämför med en borttagen bild på en digitalkamera. Det går aldrig att garantera att den finns kvar, men chansen finns ju. Samtidigt är det är fel att säga att den aldrig kan finnas kvar.
Det är mellan dessa ytterligheterna som diskussionen rör sig.
//Singha711
Mja, det är väl snarare så att vi får hoppas att Fodervärden inte känner alltför stort behov av att kommentera varje inlägg jag skrivet på detta forum.
Retstickan Arne
Arne, det är min plikt som moderator.
Känner du en plikt som officiell hovnarr?
Herr Chang har talat.
GmT, det var ett väldigt långt svar för att tala om en så enkel sak som att du hade fel från början, eller hur?
Nu har du ju till och med läst på och kommit fram till att där inte finns några lager i en jpg-bild om jag tolkade det rätt?
Förmodar att du pratar om dom så kallade klustrena som finns på hårddisken? Korrekt att där kan finnas lite skräp kvar där som säkerligen går att plocka fram med nått analysprogram. Ditt svar är ändå återigen fel av två anledningar. Dels så är en jpg endast en fil, så där blir bara ett kluster kvar i slutet som det kan finnas något kvar i, sen så är ju den överskrivna bilden en kopia av ett original somm finns kvar. Så det skräpet som finns i slutet kommer i så fall från en annan fil.
"Finn fem fel, Farang" är dagens motto och då passar det utmärkt med att vi börjar granska dina inlägg. Men innan jag börjar med att går in på den konkreta problematiken, tycker jag att några ord om en djupare förståelse av IT-frågor är på sin plats här:
Vi närmar oss professionell nivå nu och då är det lätt att missförstå sakernas egentliga tillstånd, i synnerhet när det gäller IT-frågor. Och det är det fina med IT-kunskaper: man kan komma ganska långt med enbart en "konceptuell" förståelse. Avancerade systems uppgift är bl.a. att dölja den underliggande komplexiteten för användaren och ju bättre man lyckas med det, desto bättre är systemet. Men likförbannat finns det fortfarande en verklighet kvar på lägre nivåer i förståelsepyramiden som följer helt andra lagar än nästhögre nivå.
Kort sagt kan ett datasystems funktionalitet beskrivas som en pyramid, där användargränssnittet utgör toppen och som är riktat mot människan som skall lösa en uppgift med hjälp av systemet, medan de lägsta skikten är riktade mot maskinen som ska utföra detaljerade instruktioner. Mellan toppen och botten finns det ett antal "lager" som representerar hierarkin av redan färdigutvecklade komponenter för att lösa "generella" problem, som t.ex. att skriva ett datablock till disken oberoende innehåll och applikation.
På denna nivå är det ointressant om applikationen används för att redigera en bild eller för att sköta bokföringen i ett företag. Dess uppgift är ändå samma, nämligen att skriva ett datablock av en vis typ, med en vis storlek och med ett visst innehåll till disken. Du kan jämföra med en SJ-anställd på en rangergård som sammanställer ett tågekipage efter vissa instruktioner. Han/hon är helt ointresserad vad som finns i godvagnarna, varifrån t.ex. Chang-lådan kommer ifrån och vem som slutligen dricker en viss burk i lådan. Han/hon gör sitt jobb, that's all, och han/hon vet bäst inom sitt gebit.
Vi återvänder till vår pyramid och sammanfattar: På toppen finns det en användarorienterad "logisk" förståelse, på botten finns det en "fysisk" maskinorienterad verklighet och däremellan finns det en hierarki av "tjänster" som bryter ner och anpassar de uppifrån mottagna instruktioner till nästlägre nivå. Denna anpassningsprocess medför en omorganisation av instruktionerna, dvs en förändring pga en hel annan verklighet som råder på detta nivå. Dessa tjänster är också ett resultat av ett gigantiskt arbete som datapionjärerna har åstadkommit under 50 års tid, oftast med extrem knappa CPU-resurser, i syfte att inte behöva uppfinna hjulet varje gång. Detta glöms tyvärr ofta bort idag.
Och nu kommer vi till kärnan av mitt budskap: Det går inte att tillfullo förstå problematiken på en nivå utan att ha en grundläggande uppfattning om problematiken i angränsande nivåer. Detta gäller all kunskap och det tycks finnas en viss tröghet i den mänskliga naturen att inse detta, vilket givetvis inkluderar även mig.
Ok, tillbaks till den konkreta frågeställningen: så "let's get physical".
När det gäller forensiska plugin, föreslår jag att du istället söker på engelska med "forensic plugin". Prova och se: http://www.google.co...sic+plugin&meta=
Vidare har du fel när du antar att jag pratar om din hårddisk. Givetvis utgår jag ifrån enbart en jpg-fil som källa för rekonstruktion. Hade man haft tillgång till din hårddisk, hade det inte tagit lång tid att hitta användbara rester även på det område som kallas för "unallocated space", dvs. "deletade" filer etc. Om det inte har gått allt för lång tid och om disken inte är precis proppfull och hopplöst fragmenterad, är chanserna väldigt goda för att antingen hitta användbara bitar ur originalbilden eller temporära filer från bildredigeringen. Kom ihåg också att en skicklig hacker också kan komma över denna information m.h.a. trojaner etc. innan antivirusprogrammen upptäcker intrånget. Fortfarande finns det mängder med varianter kvar som inte har blivit rapporterade. Dessa går faktiskt också att köpa. Men varför gå över ån för vatten när man har en användbar jpg-fil?
Sedan har du totalt fel när det gäller fysisk skrivning av data till disken, i detta fall en jpg-fil. En jpg-fil innehåller en header- och en footerblock vars utseende är exakt specificerat genom JPEG-standarden. Den fysiska blockstorleken bestäms av filsystemet, inte av programmet som skriver i dem. Programmet kan dock ta reda på det genom operativsystemet som samordnar samspelet . Det kan inte codec-processen, som är en underprocess i programmet och som i det avseende är "blind" eftersom den måste fungera likartat oberoende "uppdragsgivare" och filsystem. Alltså har programmet möjlighet att manipulera codec-processens output m.a.p. blockens innehåll innan den slutgiltiga överlämningen till operativsystemet(=stängning) sker.
Vidare har uttrycket "ström" med sin association till en sekventiell struktur enbart ett berättigande vid läsning, dvs bearbetning genom en player (=uppspelning). Detta är en nödvändighet i synnerhet för audio- och videoströmmar då vår musik- och filmuppfattning är sekventiell. Vi skulle inte gilla musik eller film där tonerna och bilderna skulle komma i en "random"-sekvens. Men detta gäller inte i lika hög grad för en enskild bild. Om det bara går tillräkligt fort så bryr vi oss inte om i viken ordning pixlarna blir projicerade på bildskärmen. Men eftersom en videoström består av enskilda bilder i sekvens, tillämpar man även för stillbildsmedia begreppet ström. En effektiv buffring förutsätter också en sekventiell indataström.
När det gäller tillverkning av en mediaström (=skrivning) råder dock helt andra villkor. Det skulle ta oerhört mycket längre tid och kräva oerhörda CPU- och minnesresurser om första blocket som innehåller viktig styrinformation om hela filen i ackumulerad form (summor etc) först kunde skrivas när allting var klar, eftersom en summa t.ex. först står fast när alla poster har räknats. Och sen hade vi pga. resursbrist bara kunnat hålla kvar de första x-antal poster i minnet. Resten hade vi behövt överge och sedan skapa på nytt igen. Nej, det skulle aldrig gå att tillverka en jpg-fil på detta sätt, så någon annan metod måste till.
Lösningen ur dilemmat blir att skriva "random"-vis. Man skickar i den ordningen som passar programmet bäst paket med olika längd och innehåll till operativsystemet som i sin tur vidarebefordrar dessa till filsystemet som fördelar dem till större block och rapporterar tillbaks till programmet på vilket block de olika paketen har hamnat. Men det är ändå viktigt att blocken i slutändan innehåller de paket som hör ihop i den ordning som strömmen kräver. Tänk på en postsorteringsterminal med alla sorteringssäckar(=datablock) som tar emot brev och paket huller om buller.
Detta förfarande är väldig smidigt men innebär att filsystemet bara kan hålla ett begränsat antal datablock (=sorteringssäckar) i minnet och därför måste hämta upp ett och samma block många gånger, dvs. läsa den ifrån disken vilket är en förhållandevis långsam process jämfört med minneoperationer. Det finns dock fiffiga metoder att minimera detta problem så att rätt bock "råkar" finnas kvar i minnet med en viss sannolikhet utan att filsystemet vet vilket program leveransen kommer ifrån och hur detta program "tänker" för att någorlunda kunna förutsäga nästa leverans. En nackdel med dessa metoder är dock att man ogärna vill fylla blocket helt innan man rekvirerar nästa nya block. Anledningen är att just denna uppgift tar mycket tid, men å andra sidan kan den utföras parallellt. Allstå begär man ett nytt block när det gamla blocket bara halvvägs är fyllt, så att det nya blocket kommer fram i tid och flödet inte behöver stoppas. Allt detta har till följd att det finns en massa block som inte är helt fyllda när allt är klar.
Och nu har programmet en lista över alla paket och i vilka block de har hamnat och givetvis vilket "tomrum" som finns kvar. Denna "gyllene chans" utnyttjar varje programleverantör med självaktning för just sina ändamål. Enda problemet är att man är låst när det gäller tillgängligt utrymme. Ibland blir det mycket över, ibland förhållandevis lite. Alltså behöver man prioritera och man fyller sedan ut tomrummet med just den information som man tycker är viktigast. Även här håller man en egen lista över all "överskottsinformation" vars root-index skrivs i den för programleverantörsinfo avsedd plats i JPEG's format-layout. "Överskottsinformationen" är inget som JPEG vet något om eller brys sig om eller kommer i konflikt med. JPEG har sin egen lista (index) och bara ser sitt medan programleverantören kan "tolka" sin information i sina system.
Jag hoppas att jag har kunnat visa att det "principiellt" är möjligt att lägga upp information om bildlager i en jpg-fil utan att dess längd eller bildinnehåll påverkas. Det är det som du bestrider "kategoriskt". Den ronden gick därför till mig, Farang.
Nu hinner jag inte redogöra hur Adobe eller andra programleverantörer har implementerat överskottsinformation m.a.p. bildlager i sina system, men jag återkommer med mer detaljer snarast möjligt. Under tiden kan du ju googla på ämnet genom att söka på "forensic plugin" (enl länken ovan) för att få lite spännande läsning om vad man kan få ur en jpg-fil.
"The invisible ghost CAN be revealed"! GmT
Nu har jag läst ditt inlägg flera gånger GmT. Bla bla bla...
Kan du inte helt enkelt förklara hur du kommer åt sql filerna med din JPEG fil?
Kan du också förklara hur det kommer sig att denna vetskap inte har drabbat alla forum på internet redan?
Det finns garanterat folk som sitter och önskar att denna fräna funktion skulle vara så enkel. Hur mycket skada kunde man inte göra då på internet?
Det enda sättet som jag ser det, som skulle få det att fungera, är att om din JPEG fil frågar efter lösen och användare för att synas, och jag är så onykter att jag skriver in dessa till sql databasen...
Men det funkar ju inte på IPB ändå.
Lycka till, då GmT.
Logga in för att svara.
