De Broncode

De Broncode

Re: De Broncode

Berichtdoor Michael1954 » za 28 aug 2010, 21:58

From: Geb

Hallo,

Ik heb de meeste opmerkingen gelezen maar mijn idee niet gezien. Dus bij deze.
Het probleem is om in een bit meerdere bits op te slaan. Binair gaat dat niet lukken.

Maar stel dat ik die bit een kleur kan geven dan kan ik in een "bit" 24 bits vastleggen. (RGB kleurcode FF FF FF)
Deze "bit" weer omzetten in 24 bits is simpel. Dit levert een compressiefactor 24 op. Ongetwijfeld kan het kleurenspectrum nog verder worden opgesplitst zodat een verdere verdichting van de informatie mogelijk is.

Ik ben benieuwd naar reacties.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » za 28 aug 2010, 21:58

From: Cycloon

Iedereen kan wel op zo'n idee komen. Of we gebruiken een spanning van 0 tot 30V en we splitsen dit interval op in 30 stukken, dan hebben we zelf een compressie van factor 30!!!

Het probleem is gewoon dat je onmogelijk "kleuren" kan opslaan en onmogelijk correct kan uitlezen. Ook moet dit nog eens enorm klein te produceren zijn, weinig verbruiken, snel genoeg zijn en liefst ook herschrijfbaar natuurlijk.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » za 28 aug 2010, 22:00

From: Geb

(Cycloon)
Iedereen kan wel op zo'n idee komen. Of we gebruiken een spanning van 0 tot 30V en we splitsen dit interval op in 30 stukken, dan hebben we zelf een compressie van factor 30!!!

Het probleem is gewoon dat je onmogelijk "kleuren" kan opslaan en onmogelijk correct kan uitlezen. Ook moet dit nog eens enorm klein te produceren zijn, weinig verbruiken, snel genoeg zijn en liefst ook herschrijfbaar natuurlijk.

Hoezo "onmogelijk kleuren opslaan?" Nog nooit kleurenfoto gezien? Hoeveel "bits" staan daar wel niet op? En geloof me je kunt ze exact uitlezen. Met wat lensjes, een prisma, filters en wat lichtgevoelige cellen stelt dat niet zo veel voor. Ga maar eens met een kleurenstaaltje naar de schilder en hij mengt voor je de zelfde kleur. (zelfde principe) Dat het ook klein kan twijfel ik niet aan. Waarom zou het verbruik hoog zijn? Die paar ledjes? Ook de snelheid kan geen probleem zijn want door het lezen van EEN "bit" krijg je 24 binaire bits binnen. Blijft de herschrijfbaarheid. Dat is iets dat Sloot ook niet heeft laten zien. Ook met het verzenden van de informatie had hij problemen. Want hoe moest hij deze kleurencode verzenden?
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » za 28 aug 2010, 22:09

From: Qrnlk

(Geb)
Hallo,

Ik heb de meeste opmerkingen gelezen maar mijn idee niet gezien. Dus bij deze.
Het probleem is om in een bit meerdere bits op te slaan.

Dus het probleem is dat je, om maar een illustratie te gebruiken, in een 1 liter emmer meerdere liters vloeistof wilt op slaan? Dat lijkt mij min of meer onmogelijk zo op het eerste gezicht.
(Geb)
Binair gaat dat niet lukken.

Wat je dus eigenlijk zegt is dat dit niet mogelijk is met bits? Ik denk dat dit correct is: 1 bit kan namelijk per definitie slechts 1 van twee waarden hebben True of False. Bits zijn dus per definitie binair, de naam zegt het al Binary Digit.
(Geb)
Maar stel dat ik die bit een kleur kan geven dan kan ik in een "bit" 24 bits vastleggen. (RGB kleurcode FF FF FF)

Kleur? Bits zijn abstractie platonische begrippen, geen concrete fysieke objecten die licht van een bepaalde golflengte weerkaatsen.

Om terug te komen bij die emmer: Je stelt voor dat je instaat bent om 16777216 liter aan vloeistof in 1 emmer met een inhoud van 1 liter te stoppen als je elke liter vloeistof van een iets andere kleur zou voorzien? Ik denk niet dat het universum zo werkt.
(Geb)
Deze "bit" weer omzetten in 24 bits is simpel. Dit levert een compressiefactor 24 op. Ongetwijfeld kan het kleurenspectrum nog verder worden opgesplitst zodat een verdere verdichting van de informatie mogelijk is.

:D Vergelijk aub deze termen eens: Symbol, Baud, Bit.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » za 28 aug 2010, 22:10

From: Cycloon

(Geb)
Hoezo "onmogelijk kleuren opslaan?" Nog nooit kleurenfoto gezien? Hoeveel "bits" staan daar wel niet op? En geloof me je kunt ze exact uitlezen.

Nu ben je analoge zaken met digitale zaken aan het wisselen. Zelf al zet je maar 1 gekleurd puntje op je blad dan heb je in principe in het analoge domein al een oneindig aantal gegevens voor handen. En zoals qrnlk al zei, stap even af van de naam 'bit' omdat het in deze situatie geen steek houdt.

Anyway, denk even verder na: Een beeld is een combinatie van kleurschakeringen, wat jij wil doen is aan de hand van (een kleiner aantal) kleurschakeringen een bepaalde patroon van kleurschakeringen genereren (het uiteindelijke beeld van de film). Je voelt toch wel dat er iets mis gaat?

Op zich is er niks revolutionair aan je idee, iedereen beseft wel dat je als je "iets" meerdere staten kan geven je er ook meer info kan in opslaan. De huidige computers gebruiken een 1 of een 0, er is een spanning of er is geen spanning. Je kan dus even goed in spanning gaan variëren ipv in kleuren, op zich zou dat zelf makkelijker zijn vermits je niet zomaar een kleur gaat genereren "on demand" in een computer en je dat met spanningen wel kan. Het probleem is en blijft gewoon dat het niet zo makkelijk is om die verschillende staten automatisch te gaan uitlezen (en dat ook 100% correct te doen!).

In het beste geval hadden we gewoon analoge computers en konden we alle gegevens die we nodig hadden opslaan in 1 atoom bij wijze van spreken.

Dus kom nu maar met een systeem die jouw idee van kleuren gebruikt om data automatisch in te lezen en weg te schrijven.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » za 28 aug 2010, 22:12

From: Fbituner

Qrnlk schreef:
Om terug te komen bij die emmer: Je stelt voor dat je instaat bent om 16777216 liter aan vloeistof in 1 emmer met een inhoud van 1 liter te stoppen als je elke liter vloeistof van een iets andere kleur zou voorzien? Ik denk niet dat het universum zo werkt.


Op zich is dit onmogelijk, maar stel dat je de emmer van kleur kan laten veranderen dan krijg je er zoveel kleuren water in als je maar wilt... ;)
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » za 28 aug 2010, 22:14

From: Fbituner

Anonymous schreef:
Als ik een nieuw alfabet zou bedenken, denk aan runen, kan ik met vision technologie en 2 runen miljoenen combinaties uitwerken? Denk 3 D !

Dit 3D alfabet is inderdaad een zeer interessant idee als je weet dat een analoog beeldsignaal wordt opgebouwd uit 3 waarden

1. fase bepaalt de kleur
2. amplitude de verzadiging van die kleur.
3. helderheid

Denk maar eens aan de mogelijkheden... Elke as van de 3D letter houdt een waarde in van het analoog beeldsignaal. Zo heb je een machtig kleurenalfabet.

En volgens mij lagen daar nu de "netwerk problemen" die Jan Sloot had... Hoe moest hij nu die "analoge" signalen over een "digitaal" netwerk gaan versturen ZONDER VERLIES.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » zo 29 aug 2010, 04:44

From: Rogier

Omdat er al zó verschrikkelijk veel onzin over de fabel van Jan Sloot is geschreven, laten we bij eventuele suggesties hoe het toch mogelijk zou zijn even helder krijgen waar het precies over gaat:

1: een film in weinig informatie proppen (dus krachtige compressie / codering / hoe je het ook noemt)
of
2: informatie in kleine fysiek medium proppen (dus een efficiënte informatie-opslag / data-drager)

Nummer 1 gaat over tot hoe weinig informatie je een film kunt reduceren om hem toch te kunnen afspelen (op voldoende kwaliteit, een beetje kwaliteitsverlies mag wel, dat doen avi filmpjes van nu ook). In dit geval maakt het niet uit hoe je de informatie fysiek opslaat.

Nummer 2 gaat erover hoe je informatie fysiek opslaat. Dus wat voor freaky analoog medium of 3D runen-kleitablet of hypermagnetisch diskoppervlak of wat je dan ook verzint om veel informatie in weinig oppervlak of volume kwijt te kunnen. In dit geval maakt het niet uit wat voor data je opslaat, of dat nu een film is, een boek, of seismografische meetgegevens van de Vesivius.

Voor de duidelijkheid:

Bij nr. 1 zit de prestatie hem in het logisch verkleinen van een film. Dat drukken we uit in kilo- en megabytes, wat iets abstracts is.
Bij nr. 2 zit de prestatie hem in het fysiek verkleinen van informatie. Dat drukken we uit in vierkante of kubieke millimeters, wat iets fysieks is.

Kan iemand die de ideeën van die gekleurde emmers en 3D alfabetten begrijpt even aangeven in welke categorie deze vallen? Dan valt er op een zinnige manier over te praten.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » zo 29 aug 2010, 04:45

From: Schwartz

nr1:
Je kunt ook data comprimeren zonder kwaliteits verlies.
Kwaliteitsverlies is instelbaar maar men kan het op 0% laten staan.

Een probleem met compressie zijn fouten bij het opslaan, verzenden en ophalen van de data.
Bij een grote compressie worden de fouten uitvergroot tot lelijke zichtbare dingen.
Een goede compressie methode houdt hiermee rekening.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » zo 29 aug 2010, 04:47

From: Rogier

Schwartz schreef:
nr1:
Je kunt ook data comprimeren zonder kwaliteits verlies.
Kwaliteitsverlies is instelbaar maar men kan het op 0% laten staan.

Uiteraard, ja, andere data dan multimedia (beeld & geluid) wordt doorgaans altijd lossless gecomprimeerd.

Instelbaar kwaliteitsverlies dat ook tot 0% gaat is trouwens niet zo heel gangbaar. Jpeg2000 is zo'n standaard, maar jpeg bijvoorbeeld niet (een "100% kwaliteit" jpeg is niet verliesvrij) en avi ook niet (de ene codec doet lossless, de andere lossy, maar het is niet zomaar schaalbaar tussen niet, een beetje of veel verlies).
Een probleem met compressie zijn fouten bij het opslaan, verzenden en ophalen van de data.
Bij een grote compressie worden de fouten uitvergroot tot lelijke zichtbare dingen.
Een goede compressie methode houdt hiermee rekening.

Idealiter is dat vooral de verantwoordelijkheid van de verzend- en ophaalprotocollen (die moeten bijvoorbeeld error correction bits meesturen of checksums om blokken data opnieuw te doen als ze niet goed zijn aangekomen).
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

VorigeVolgende

Keer terug naar Wetenschapsforum.nl (0112)

cron