• 0

Extreme compressie

Bij toeval kwam ik enige tijd geleden op het idee voor een nieuwe manier van compressie van data.

Deze manier staat totaal los van alle huidige compressie methoden en zou vele malen efficienter zijn. In mijn berekeningen kom ik uit op een bestand van 1TB wat te comprimeren is tot slechts enkele MB's.

 

Tijdens het ontwikkelen van het algoritme had ik even een moment van bezinning en vroeg mezelf af wat de impact van deze vinding zou zijn?

 

Vandaar mijn vraag aan jullie, hoever zouden deze gevolgen gaan?

 

Ik denk zelf aan de mogelijkheid dat werkelijk alles kan worden opgeslagen met de huidige capaciteit. Maar wat gebeurd er met de hele hardware branche? Een DVD waar duizend films op passen (zonder kwaliteitsverlies). En wat gebeurd er met het internet?

 

Over het algoritme kan ik nog weinig zeggen omdat ondanks dat de eerste versie mislukt is, ik nog steeds mogelijkheden zie om een werkend model te ontwikkelen. Het is logisch dat dit voor veel mensen direct afgedaan zal worden als onzin (we kennen allemaal het verhaal van Jan Sloot en Philips). Data reproduceren uit niets (zeer weinig) is onmogelijk en ook wiskundig te onderbouwen. Zonder de methode uit de doeken te doen zal niemand dit dan ook geloven, vandaar dit ik me nu op de 'etische' kant wil richten.

 

Ik zie namelijk zelf nog steeds mogelijkheden om dit te ontwikkelen, maar wat zouden de gevolgen zijn als het daadwerkelijk lukt?

Link naar reactie

Aanbevolen berichten

  • 0

En dan te bedenken wat die 4079 bytes aan (nuttige) megabytes genereert mbv algo's.

Meh...laat me Pirates of the Caribbean in 4K zien en ik ben onder de indruk. Sterker nog - slechts 100MB is ook goed.

 

Edlt: en dan ook zonder dat alle virusscanners afgaan. Desnoods ongecomprimeerd - mag het zelf 200MB zijn van mij.

Zal niet lukken zonder vector_table van 8gB ???

Link naar reactie
  • 0

Ik zie nu dat in de url de naam Jan Sloot ook voorkomt. >;(

 

 

Zal niet lukken zonder vector_table van 8gB ???

 

En wat is die 8Gb vector tabel? Is die voor alle films hetzelfde?

 

 

@TLC Wat is jou belang bij deze Jan Sloot onzin?

Link naar reactie
  • 0

als videomaker ontvang en verzend ik veel megabytes, dus ben zeer geïnteresseerd in deze compressie.

is het nou veilig om te gebruiken of niet?

 

Van: Noreply [noreply@telcomsoft.nl]

Aan: S*@home.nl

Onderwerp: Re: False Positiv

 

06-05-2011

 

Beste heer Tom L. Corneis.

 

Sub: False positiv

-------------------------

N.a.v. uw schrijven daterend 05 mei 2011 kan ik uw informatie bevestigen

dat de PE header en/of decompressor (~200 bytes) van crinkler gelijkenissen

vertonen van kwaadwillende bestanden waardoor virusscanners geïrriteerd kunnen

raken. De overige bytes genereren digitale gegevens van ongeveer 50mb raw data

(Non_Rev compressratio van 1:12500).

 

Het moge U duidelijk zijn dat genoemde extern ontwikkelde demo geheel losstaat

met de technologie van dhr. J.Sloot en enkel ter illustratie bedoeld is van genoemde ratio.

 

In de toekomst zullen ook andere voorbeelden beschikbaar gesteld worden (E_Compression)

waarbij berekeningen enkel d.m.v. bitschuiving geschied. De ratio hiervan is source-afhankelijk.

 

Hopende met dit schrijven uw vragen beantwoord te zijn.

 

M.vr.gr. Johan

 

 

Let op ! Dit bericht kunt u niet beantwoorden !

Ga hiervoor naar: http://jansloot.telcomsoft.nl/Sources-1/Contact/Contact.php

 

 

edit: De demo stond op die website en achteraf vond ik 'm ook al op Youtube waar ik ook geen belang in heb :)

Het thema was "Extreme compressie", tja en 1:12500 is niet weinig & vind hem nog steeds indrukwekkend :P

Link naar reactie
  • 0

En wat is de relatie met het onderwerp van dit draadje?

Vandaar mijn vraag aan jullie, hoever zouden deze gevolgen gaan?

Klopt, je hebt gelijk... een afdwalertje ,misleid door de topic-header :-[

Zal niet meer gebeuren :-\

Link naar reactie
  • 0
Extreme compressie met DNA

 

 

... enzo ja, wat zijn de gevolgen (topic-follow)

 

Tom L. Corneis.

Extreme compressie met DNA ???

 

Dat is een algoritme met een referentietabel, vertelt het filmpje. Met een voldoende grote referentietabel kun je elk digitaal bestand met de Huffman-codering in 1 bit opslaan.

Heeft dat voordelen t.o.v. huidige compressie-technieken ?

 

http://jansloot.telcomsoft.nl/Forum/viewtopic.php?f=281&t=264

 

Op afbeelding is de tabel best groot ja.

 

Tom L. Corneis.

Link naar reactie
  • 0

Heeft dat voordelen t.o.v. huidige compressie-technieken ?

 

http://jansloot.telcomsoft.nl/Forum/viewtopic.php?f=281&t=264

 

Op afbeelding is de tabel best groot ja.

 

Tom L. Corneis.

Hoogstwaarschijnlijk? Absoluut geen. De methode die renep aanhaalt kun je zien als het doorsturen van een oneindig grote hoevelheid boeken waarin je alle informatie stopt. Als je deze boeken hebt verstuurd naar een ontvanger dan kun je door enkel het bladzijdenummer door te geven met enorme snelheid informatie opzoeken. Is dit dan ook echt compressie? Niet bepaald, die enorme set data moet je nu eenmaal eerst zien te delen voordat je hiervan profiteert.

 

Je kunt hier nog wel wat winst mee behalen wanneer je bijvoorbeeld data verstuurt die enige regelmaat kent. Wanneer je bijvoorbeeld als fictief voorbeeld elke dag teksten uit wetboeken overstuurt kun je bijvoorbeeld een bepaalde zin die regelmatig voorkomt voor versturen te vervangen door een afkorting en na ontvangen weer terug om te zetten. Huidige compressiemethoden werken door die afkortingen per keer opnieuw te berekenen waardoor zo'n eindeloze opzoektabel niet nodig is, wat al meteen suggereert dat de te behalen winst hiermee niet interessant genoeg is op deze manier.

 

De inefficiëntie hiervan kun je ook al een beetje zien op het aangehaalde bericht op telefomsoft.nl; om die set bestanden van pakweg 100MB in totaal te kunnen 'uitpakken' er is een 'DNA'-bestand van 771MB gebruikt, in principe is de "compressie" hiermee dus van 100 naar 771MB (de grootte van de sleutels is verwaarloosbaar), een toename van de totale grootte in plaats van een afname.

 

Nu kan je hiermee wellicht in gevallen waarop je veel enigszins regelmatige data moet versturen wel winst opleveren doordat je stukjes die regelmatig voorkomen als het ware kunt "afkorten" met

Link naar reactie
  • 0
Op afbeelding is de tabel best groot ja.

Zelfs een stuk groter dan al die bestanden die er boven staan samen! ;D

 

Als dit supercompressie is, dan heeft de ANWB al jaren geleden heel Nederland extreem gecomprimeerd toen ze wegwijzers plaatsten op de Nederlandse wegen...

 

Edit, voor je geheugen:

En wat is de relatie met het onderwerp van dit draadje?

Vandaar mijn vraag aan jullie, hoever zouden deze gevolgen gaan?

Klopt, je hebt gelijk... een afdwalertje ,misleid door de topic-header :-[

Zal niet meer gebeuren :-\

Link naar reactie
  • 0
Heeft dat voordelen t.o.v. huidige compressie-technieken ?

 

Het ís een huidige compressietechniek. Microsoft wil het zelfs toepassen voor dynamisch geheugenbeheer in Windows 8, las ik laatst (kopje "Memory combining").

 

Sinds de jaren 70 doen operating systems hun best om memory pages met identieke inhoud te combineren en pas fysieke kopieën te maken als een van de pages wordt gewijzigd (copy on write).

 

Zoiets kun je ook doen met de inhoud van bestanden. Je gaat op zoek naar meervoudig voorkomende blokken data en vervangt die door verwijzingen naar één exemplaar ervan in een referentietabel. Daar kun je spectaculaire demootjes mee maken, want een referentie is veel kleiner dan de data die het vervangt. Bij een niet-kritisch publiek kun je zelfs het element 'meervoudig' laten vallen en gewoon de inhoud van de bestanden in de referentietabel stoppen. Wel zo makkelijk. Je gecomprimeerde bestanden zijn dan piepklein (desgewenst past een bepaald bestand in 1 bit, maar 256 bytes klinkt spannender), maar je referentietabel is navenant groter.

Link naar reactie
  • 0

Edit, voor je geheugen:

 

 

... enzo ja, wat zijn de gevolgen (topic-follow)

 

Vandaar mijn vraag aan jullie, hoever zouden deze gevolgen gaan?

 

Memory ok !

 

Reacties van Leftblank & Renep geven meer mij meer diepgang/verheldering. :)

 

Groet TLC

Link naar reactie
  • 0

... de referentietabel stoppen. Wel zo makkelijk. Je gecomprimeerde bestanden zijn dan piepklein (desgewenst past een bepaald bestand in 1 bit, maar 256 bytes klinkt spannender), maar je referentietabel is navenant groter.

Als ik het in het forum goed gelezen heb dan is de minimale grootte 32 bytes maar 256 blijkt beter te zijn voor het tabel. Verder begrijp ik gelezen te hebben dat de tabel niet groter zou zijn 740mB. Hoeveel bestanden daarin zitten is me onduidelijk omdat het een snapshot betreft.

 

Bedankt voor je info.

 

Tom.

 

Link naar reactie
  • 0
Memory ok !

Inzicht alleen niet. Dit is geen compressie, dit is codering. Net als "Hoofdstuk 1" verwijst naar 100 pagina's tekst. Hoe meer pagina's tekst, hoe kleiner de overlap met andere hoofdstukken (en films, en MP3's, etc.), en hoe dichter je bij 'unieke blokjes' van 1 byte komt, en dus een 'compressie' van 1:1.

 

Als je hier een serieuze discussie wilt hebben zul je mensen moeten overtuigen, en dat kan alleen door je algoritme te plaatsen. Zolang je dat niet doet zul je door de meesten als fantast nummertje zoveel worden weggezet.

Link naar reactie
  • 0

Memory ok !

Inzicht alleen niet. Dit is geen compressie, dit is codering. Net als "Hoofdstuk 1" verwijst naar 100 pagina's tekst. Hoe meer pagina's tekst, hoe kleiner de overlap met andere hoofdstukken (en films, en MP3's, etc.), en hoe dichter je bij 'unieke blokjes' van 1 byte komt, en dus een 'compressie' van 1:1.

 

Als je hier een serieuze discussie wilt hebben zul je mensen moeten overtuigen, en dat kan alleen door je algoritme te plaatsen. Zolang je dat niet doet zul je door de meesten als fantast nummertje zoveel worden weggezet.

Schijnbaar heb je jou huiswerk niet goed gemaakt, lees wat ik schrijf/vraag >;( (al de 2de keer)

It's him again ::)

 

Btw: ~Auteur <> je <> doorgeslagen ;)

 

TLC

 

Link naar reactie
  • -1

Ik heb gelezen wat je schrijft, en ik geef er mijn mening over, die jij vervolgens negeert omdat het niet is wat je wilt horen.

 

Nummertje zoveel, dus. Succes!

... waarin jij dicteert welke criteria jij nodig acht om een discussie te voeren.

... waarbij geen directe reactie een eigen interpretatie kent: iets niet willen horen.

 

Prima, gelukkig zijn er die daar geen last van hebben getuige bovenstaande en gewoon terzake komen waarvoor mijn dank.

 

Nummero uno dus.

 

Suk6 2

 

TLC

Link naar reactie
  • 0
Bij een niet-kritisch publiek kun je zelfs het element 'meervoudig' laten vallen en gewoon de inhoud van de bestanden in de referentietabel stoppen. Wel zo makkelijk. Je gecomprimeerde bestanden zijn dan piepklein (desgewenst past een bepaald bestand in 1 bit, maar 256 bytes klinkt spannender), maar je referentietabel is navenant groter.

Onzin. Coderen is niet hetzelfde als comprimeren. Het bestand past niet in die ene bit maar komt in je referentie tabel. Met een referentie van 1 bit groot kun je maar naar twee bestanden cq. bestandsondeerdelen refereren. Practisch onbruikbaar dus. Met een grote key (bv. 256 bytes) kun je naar heel veel bestanden cq. bestandsondeerdelen refereren, maar nog steeds niet oneindig veel en zoals eerder genoemd vereist ieder nieuw stukje data z'n plek in de referentie tabel, die bij beperkte grootte een beperkt aantal bestanden kan genereren.

 

Dedupliceren kan wel degelijk ruimte besparen en als onderdeel van een compressie-algoritme is dat zeker effectief (zie oa. RLE en Huffman). Echter, dit zal never nooit extreme compressie voor alle soorten bestanden opleveren. Uitdaging: probeer reeds gecomprimeerde bestanden (bv. MP3) eens significant (meerdere factoren) kleiner te krijgen.

 

@TLC: Geef svp. eens een inhoudelijke reactie die van inzicht getuigt.

Lees voor inhoudelijk zinnige repliek en achtergrond informatie deze en deze teksten op wikipedia. Op de laatstgenoemde pagina wordt zelfs naar je site verwezen als (overigens best uitgebreide) verzamelplaats van informatie over SDCS en soortgelijke gedachten. Helaas besteedt je site nauwelijks tot geen aandacht aan de critici en hun inhoudelijke argumenten. Wat mij betreft een gemiste kans.

 

Relevante quotes o.a.:

Op een vergelijkbare manier heeft Claude Shannon in 1948 bewezen dat er een limiet is aan lossless compressie. Om die reden is de nooit gerealiseerde uitvinding van Jan Sloot, waarbij 16 willekeurige speelfilms lossless in 64 kilobyte zouden passen, theoretisch onmogelijk.

 

Een goed compressiealgoritme moet dus toegesneden zijn op de eigenschappen, zoals statistiek etc, van de te comprimeren bestanden. Wanneer de werkelijkheid afwijkt van de veronderstellingen waarop de compressor is gebaseerd, kunnen ernstige teleurstellingen het resultaat zijn.

 

In veel verhalen over de vinding van Jan Sloot wordt vermeld dat hij films kon terugbrengen tot een vaste grootte van 1 kilobyte. Het is eenvoudig te bewijzen dat dit onmogelijk is.
Link naar reactie
  • 0

Hallo mmint

@TLC: Geef svp. eens een inhoudelijke reactie die van inzicht getuigt.

Eerst wat opheldering. Ben werkzaam in een bedrijf in Z.Nederland die voor klanten veel papierwerk opslaat en digitaliseerd en binnen de markt hebben we een gunstige positie. Enkele jaren is men bezig om datzelfde te doen voor video-content. De kosten voor dergelijke opslag is dermate hoog dat de kostprijs te hoog wordt voor concurrentie. Binnen het bedrijf is een soort award uitgeloofd voor oplossingen en laatst stuitte ik op een video-demo. Zelf heb ik geen kennis van algoritmes en ik heb dan , tot nu toe, geen connecties met de maker van DNA nog het bedrijf wat hier achtersteekt. Voordat ik m'n werkgever blij wil maken met een 'dooie mus', had ik gehoopt hier door de profs meer duidelijkheid te krijgen. Helaas wordt die mogelijkheid hier niet geboden en het waarom laat ik aan de lezer over.

 

Bedankt voor de moeite.

 

Tom L. Corneis

 

Link naar reactie
  • 0
Zelf heb ik geen kennis van algoritmes

 

In plaats van awards uit te delen voor een beetje googlen, kan je werkgever misschien beter studieboeken uitdelen, of geschoolde werknemers in dienst nemen. Niks nieuws onder de zon, compressie wordt behandeld bij het vak informatietheorie in de opleiding wiskunde, informatica of elektrotechniek. Hop, aan de studie.

 

Maar om de een of andere reden zit compressie in de hoek van koude kernfusie, bolbliksem en perpetuum mobile, waar steeds weer andere schimmige uitvinders de suggestie levend weten te houden dat ze iets bijzonders bedacht hebben, en waar mensen geloven dat je zonder kennis iets spectaculairs kunt creëren.

Link naar reactie
Gast
Dit topic is nu gesloten voor nieuwe reacties.
Hide Sidebar
  • Wil je onze Nieuwsflits ontvangen?
    Deze verzenden we elk kwartaal.

  • Wie is er online?
    9 leden, 270 Gasten

  • Breng jouw businessplan naar een higher level!

    Op dit forum worden alle onderwerpen m.b.t. ondernemerschap besproken.

    • Stel jouw ondernemersvragen
    • Antwoorden/oplossingen van collega ondernemers
    • > 75.000 geregistreerde leden
    • > 100.000 bezoekers per maand
    • 24/7 bereikbaar / binnen < 6 uur antwoord
    •  Altijd gratis

  • Ook interessant:

    Ook interessant:

×
×
  • Nieuwe aanmaken...

Cookies op HigherLevel.nl

We hebben cookies geplaatst op je toestel om deze website voor jou beter te kunnen maken. Je kunt de cookie instellingen aanpassen, anders gaan we er van uit dat het goed is om verder te gaan.