Jump to content
  • Welcome to HigherLevel, the Dutch business forum

    Do you have a business question, do you want feedback on your business plan or do you want to advise others? Then you are at the right place at a higher level. Here entrepreneurs come together to take each other to the next level.
    Ask your question, get a quick answer and share your experiences with entrepreneurs. The moment it suits you!
    During the day, evening and weekend 24/7 free advice and exchange of experience with entrepreneurs who understand!
Ron Berk

Extreme compressie

Recommended Posts

Is iemand de supercompressie van Jan Sloot aan het reanimeren? ;D

 

Hahahaha... was dat maar waar :P

 

Gewoon geweldig om te zien dat er met 4079 bytes een realistische HQ film van 03:35 gemaakt

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

 

It's the time after Jan Sloot ;D

 

 

TLC

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 ???

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 :-\

Share this post


Link to post
Share on other sites

Extreme compressie met DNA ???

 

 

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

 

Tom L. Corneis.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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


Next Pulse

Freelance software engineer

Share this post


Link to post
Share on other sites
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 :-\

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

... 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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Bring your business plan to a higher level!

    All topics related to entrepreneurship are discussed on this forum.

    • Ask your entrepreneur questions
    • Answers / solutions from fellow entrepreneurs
    • > 65,000 registered members
    • > 100,000 visitors per month
    •  Available 24/7 / within <6 hours of response
    •  Always free

  • Who's Online

    Er zijn 15 leden online en 421 gasten

    (See full list)    
  • Ondernemersplein



EN

×

Cookies on HigherLevel.nl

Cookies are necessary for Higherlevel.nl to function properly. By using HigherLevel.nl you declare to have read and accepted our terms and conditions.

 More information   I accept