Stelling: alles is al gefotografeerd

[Paultje3181]

Zojuist op reviews: Waar blijft de opvolger van jpeg? - De 'strijd' om een nieuw beeldfo...
een interessante discussie gelezen die me aan het denken zette.
Opslag = kosten = milieuschade etc. Vanuit dit maatschappelijk oogpunt alleen al, is het wenselijk dat we niet zomaar dom blijven fotograferen en alles online blijven plempen.

Maar wat als we dit eens omdraaien:
We zijn mensen en kuddedieren die alles zomaar online gooien. We hebben bedrijven als Facebook en Google die alles, maar dan ook letterlijk alles indexeren.

Waarom daar geen gebruik van maken en met algoritmes een foto opslaan t.o.v. een basis uit een hele grote database. Die database groeit natuurlijk alleen maar meer.

Als ik in de Grand Canyon ben en maak een foto van 12MP. Logischerwijs wil ik het uitzicht hebben met mijzelf er op. Ik wil nog wat van het uitzicht zien dus mijn lichaam beslaat +- 15% van de foto. Dit is 1,6MP. Daar komt bovenop dat ik een jeans draag en een wit T-shirt. Ook dat is echt wel ooit gefotografeerd dus van die 1,6MP is ook nog eens 1,2MP al "bekend". Effectief gezien dus 400.000 pixels die Lossless opgeslagen moeten worden (al is dat natuurlijk ook relatief) en 15,6MP die a.d.h.v. verschillen van de basis gaan.

Het lijkt mij dat dit een veel kleiner bestand op kan leveren dan je met wat voor compressie ook kan behalen.

Ja, maar en mijn privacy dan? Terecht punt, maar de basis ligt in wat al bekend is en wat al gedeeld is. Uiteraard zit er een aan/uit-deelknop in het systeem. Maar dit heeft grotere bestanden tot gevolg (immers je gezicht bijvoorbeeld moet steeds in detail opgeslagen worden). Een duidelijke gezichtsfoto laten indexeren bijvoorbeeld kan heel nuttig zijn voor dit systeem. En uiteraard boeit het voor het systeem niet of je de foto nu paultje3181, donaldtrump of justinbieber noemt...

De nadelen lijken me ook duidelijk: op de camera moet je in RAW schieten (evt. met basis index optie, vaak genoeg dat je 10 shots neemt van die ene macrovlieg) en uiteindelijk worden al je foto's stuk voor stuk gecontroleerd t.o.v. index. Dus redelijk tijdrovend. Maar dit zou ook kunnen betekenen dat je een dynamische bestandsgrootte krijgt voor je foto's. Immers, als ik vandaag bovenstaande foto maak en volgende week mijn dubbelganger uit Michigan, Ohio dan wordt het voor beide ineens minder gegevens. Mijn gegevens worden t.o.v. zijn foto gespiegeld en andersom. Omdat je met verschillen werkt t.o.v. zou dit moeten kunnen lijkt mij. Ja, er zal ergens een master moeten zijn van een man tegen de achtergrond van de Grand Canyon, maar that's it.

Ik hoop dat mijn brainfart gevolgd wordt en dat er vanuit verschillende invalshoeken gekeken kan worden naar dit idee. Wat zijn de voordelen? Wat zijn de nadelen? Waarom zou dit nooit kunnen werken, waarom juist wel?

Disclaimer: mocht een bedrijf dit idee op willen pikken en dit verder uit willen werken, dan mag dit uiteraard tegen een x% van de opbrengst.

[ralpje]

Lees je eens in op 'data deduplication'

[AlterEgo]

Stelling: alles is al gefotografeerd

Maar niet door mij. Dus blijf van mijn hobby af

[Paultje3181]

ralpje schreef op maandag 16 juli 2018 @ 13:37:
Lees je eens in op 'data deduplication'

Inderdaad. Al kende ik de term zo niet. Maar dit principe ligt er aan ten grondslag. Al krijg ik wel een kip-ei principe erbij. Maar zolang de basis-index groot genoeg is, denk ik dat een dynamische container best een interessant idee kan zijn voor de opslag van foto's.

AlterEgo schreef op maandag 16 juli 2018 @ 13:40:
[...]

Maar niet door mij. Dus blijf van mijn hobby af

Ik kom er ook niet aan. Sterker nog, ik daag je uit om origineel te zijn en de index te vergroten

[ Voor 24% gewijzigd door Paultje3181 op 16-07-2018 13:47 ]

[-36-]

Zou mooi zijn,maar alleen je witte T-Shirt kan al een oneindig aantal vormen en plooien aannemen. Laat staan de grand canyon. Ik denk dat dit idee pas gaat werken als de hele wereld eerst in 3d gerenderd word en we de wereld vervolgens zo goed snappen dat we de 3d wereld foutloos gelijk kunnen laten lopen aan de echte wereld (en dus indirect ook de toekomst kunnen voorspellen, vrije wil is een illusie ) mocht het zover komen dan vermoed ik dat foto's tegen die tijd een achterhaald principe zijn.

En als 'ongeveer' goed genoeg is zou je idd wel met een automagische fotosoep copy/paste aan de slag kunnen maar ik denk niet dat het resultaat erg overtuigend zal zijn. En zo heel duur is opslag nu ook weer niet

[ Voor 17% gewijzigd door -36- op 16-07-2018 14:18 ]

[NiGeLaToR]

AlterEgo schreef op maandag 16 juli 2018 @ 13:40:
[...]

Maar niet door mij. Dus blijf van mijn hobby af

Je kunt ook beter je geheugenkaartje thuis laten, want foto's nemen is 1, maar ze bewaren.. waarom eigenlijk? Ik hoef jouw foto's niet te zien - tenzij ze exceptioneel mooi zijn. Maar laten we eerlijk zijn.. tis je hobby met een reden

Je ziet het overigens al met de telefoons die zo'n mooi wazig DoF toevoegen met software.. nog even en je ziet het verschil tussen een echte camera met grote sensor en een telefoonfoto niet meer. Dan kan ook nog eens iedereen overal dat soort mooie foto's maken..

---

Even een andere visie op zaken: ik denk dat iedereen alles opnieuw zal moeten blijven fotograferen, omdat je alleen het recht hebt om zo'n foto te gebruiken als je hem zelf genomen hebt. En omdat stockfoto sites vaak best prijzig zijn is het als je het toch leuk vindt best prima om dezelfde foto opnieuw te maken.. kun je hem zelf tenminste ook nog 's gebruiken.

[Paultje3181]

Ik merk dat mijn stelling prikkelt. Maar mijn doel was te kijken naar het opslaan van de data, en eigenlijk niet naar de content. Voor jou is de foto van je 5 minuten oude baby het meest waardevolle wat er is. Maar voor ieder ander (m.u.v. je familie natuurlijk) is het een pasgeboren baby waarvan er al erg veel foto's zijn en waarvan de verschillen tussen de foto's minimaal zijn.
https://www.google.nl/sea...j0i13i30j0i30.HDTN3G02OyA
Door te focussen op die verschillen in de foto en die op te slaan, kom je tot een unieke foto (voor jou) met een minimale bestandsgrootte.

[Tsjipmanz]

Wat jij suggereert is volgens mij delta encoding, een beetje googlen laat zien dat hier wel eens een onderzoekje naar gedaan is: http://www.diva-portal.or...va2:817831/FULLTEXT01.pdf

[CH4OS]

Paultje3181 schreef op maandag 16 juli 2018 @ 13:58:
Ik merk dat mijn stelling prikkelt. Maar mijn doel was te kijken naar het opslaan van de data, en eigenlijk niet naar de content.

Hoezo is in deze stelling data en content verschillend?

[Droefsnoet]

Paultje3181 schreef op maandag 16 juli 2018 @ 13:58:
Ik merk dat mijn stelling prikkelt. Maar mijn doel was te kijken naar het opslaan van de data, en eigenlijk niet naar de content.

Door te focussen op die verschillen in de foto en die op te slaan, kom je tot een unieke foto (voor jou) met een minimale bestandsgrootte.

Maar je maakt een foto ook niet voor iemand anders. Je maakt de foto voor jezelf. Het is jouw momentopname, jouw herinnering, jouw ervaring. En deze kan je dan delen met anderen.

Wat moet ik met een gegenereerde unieke foto van de Grand Canyon als ik er zelf ben? Dat is niet mijn foto, niet mijn herinnering. Je kan je dan afvragen waarom je überhaupt ergens naar toe zou gaan, want je kan al genoeg foto's zien van plekken. Waarom zou ik naar Zuid-Afrika willen gaan, als Floortje Dessing daar al is geweest. Heb met een zak chips op de bank haar safari tocht gezien, dan hoef ik zelf niet meer te gaan. Scheelt weer een 128GB geheugenkaartje.

[Paultje3181]

CH4OS schreef op maandag 16 juli 2018 @ 14:10:
[...]
Hoezo is in deze stelling data en content verschillend?

De content is wat op het plaatje staat: ik op de Grand Canyon. De data is de enen en de nullen die het plaatje maken. (.jpeg). En juist deze manier van opslaan (de data) is hetgeen wat ik wil bediscussiëren. jpg, png, gif, tiff, flif of deze manier via een index en het opslaan van de verschillen. (.pifdif, picture index file difference zojuist uit mijn mouw geschud)

[PageFault]

Wanneer ik alleen je titel lees, haal ik je stelling onderuit met de volgende bewijzen:

- Er is geen foto waarbij Donald en Melanie Trump gelukkig op staan
- Er is geen foto waar Donald intelligent op staat
- Er is geen foto van God, Allah of welk vergelijkbaar verzinsel dan ook
- Er is geen van een aantrekkelijke Patty Brard

Wanneer ik je verhaal lees, moet ik altijd aan een vroegere manager denken: op vakantie maakte hij nooit foto's. Hij kocht ansichtkaarten, want hij was van mening dat die fotografen toch betere plaatjes konden maken dan hijzelf.

Wat betreft jouw betoog: we kunnen dus allemaal voor een green screen gaan staat en dan een willekeurige touristische plek erachter monteren +o

[CH4OS]

Paultje3181 schreef op maandag 16 juli 2018 @ 14:41:
[...]

De content is wat op het plaatje staat: ik op de Grand Canyon. De data is de enen en de nullen die het plaatje maken. (.jpeg). En juist deze manier van opslaan (de data) is hetgeen wat ik wil bediscussiëren. jpg, png, gif, tiff, flif of deze manier via een index en het opslaan van de verschillen. (.pifdif, picture index file difference zojuist uit mijn mouw geschud)

Tja, in die zin kun je je natuurlijk wel afvragen waarom je dan de foto met jou in de grand canyon nog niet gephotoshopped hebt, dat is in feite dan toch hetzelfde? Doordat jij er op staat maakt dat de foto uniek toch?

[Paultje3181]

@PageFault @CH4OS @Droefsnoet Dit zijn juist allemaal voorbeelden van content. Mijn focus voor deze discussie ligt op de manier van compressie toepassen en de opslagcontainer. Hoe krijg je een zo klein mogelijk plaatje met maximale kwaliteit.

@Tsjipmanz Dit lijkt inderdaad precies te zijn wat ik bedoel. De conclusie is dus dat het idee werkt, maar individuele png optimisatie toch beter is, maar veel langzamer is. Mijn vraag is dan in de eerste plaats: wat als je referentiekader groter is (de index), zodat je hier veel minder van weg hoeft te schrijven en je je puur kunt focussen op het echte verschil (namelijk de persoon die er op staat). In 2015 was het verschil een factor 10 minimaal in tijd. Als die tijd besteed wordt aan het doorzoeken van de veel grotere database, krijg je ongetwijfeld een grotere compressie. Tenslotte valt en staat alles met de juiste keuze van de bron in je index. Als je kijkt naar set 1 en 2 in je referentie, zie je een verschil van 2,5% tussen de beste PNG en de binary/ImagoO vergelijking. Als je hierin een grote index opneemt in plaats van het random kiezen welke toevallig de eerste is, zal dit dus werken. Vraag is alleen hoe je begint met vergelijken.

Upload -> Random -> kijk naar referentiematches en ga filteren om zo de beste match te krijgen. En dus de kleinste patch.
He, kak. Dus toch niet origineel genoeg
@PageFault :

Good enough for me. Lijkt redelijk gelukkig. Goed genoeg iig om een vergelijking te maken. En anders is de patch file tussen deze twee niet al te groot. Vooral de monden

[ Voor 13% gewijzigd door Paultje3181 op 16-07-2018 15:49 ]

[Droefsnoet]

Paultje3181 schreef op maandag 16 juli 2018 @ 15:43:
@PageFault @CH4OS @Droefsnoet Dit zijn juist allemaal voorbeelden van content. Mijn focus voor deze discussie ligt op de manier van compressie toepassen en de opslagcontainer. Hoe krijg je een zo klein mogelijk plaatje met maximale kwaliteit.

Ik denk dat wij je OP allemaal anders hebben begrepen, namelijk waarom je zelf foto's zou maken als je vanuit een database een foto kan genereren. Nu ik het nog een keer goed lees lijkt het erop dat je het meer bedoelt zoals een animated gif optimaliseren. Waarbij je per frame alleen de unieke pixels toont. En dat wil je dan ook met statische foto's doen, dus een foto slaat alleen de unieke gegevens op en haalt de rest uit een database met foto's.

[CH4OS]

Paultje3181 schreef op maandag 16 juli 2018 @ 15:43:
@PageFault @CH4OS @Droefsnoet Dit zijn juist allemaal voorbeelden van content. Mijn focus voor deze discussie ligt op de manier van compressie toepassen en de opslagcontainer. Hoe krijg je een zo klein mogelijk plaatje met maximale kwaliteit.

Tja, aan de andere kant, de populaire lossy en lossless audio formaten zijn ook groter dan een MP3, bijvoorbeeld. JPEG is (in mijn optiek) de MP3 voor afbeeldingen, de andere formaten zijn of verouderd, of de lossy danwel lossless formaten. Een zo klein mogelijk formaat kan alleen door informatie weg te doen en voor afbeeldingen betekend dat wel kwaliteitsverlies. Vraag is in hoeverre dat acceptabel is.

[Paultje3181]

Dat ligt dan vooral aan mij gok ik zo Maar ja, inderdaad zoiets. Alleen dan veel breder getrokken en uitgaande van de stelling dat alles ooit al gefotografeerd is heeft google/facebook/whoever al de content om de index te maken. Jouw nieuwe foto van de grandcanyon wordt dan opgeslagen als

code:

ref=[hash van master]
refmatch=0.9999994
ref2=[hash ander bestand wat lijkt]
ref2match=0.99991
dif=[patch]

Waarbij de patch groter is (en dus de bestandsgrootte) als jouw stuk meer afwijkt van de master => Vandaar de mogelijkheid om de juiste master te kiezen. Maar als je een optimum vindt tussen de best and worst match (top 20 van beide?), kun je gaan filteren.
Nieuw bestand=match 0.01 => Ga naar slechtste referentie om daar 0.99999999 te scoren bij wijze van.

CH4OS schreef op maandag 16 juli 2018 @ 15:59:
[...]
Tja, aan de andere kant, de populaire lossy en lossless audio formaten zijn ook groter dan een MP3, bijvoorbeeld. JPEG is (in mijn optiek) de MP3 voor afbeeldingen, de andere formaten zijn of verouderd, of de lossy danwel lossless formaten. Een zo klein mogelijk formaat kan alleen door informatie weg te doen en voor afbeeldingen betekend dat wel kwaliteitsverlies. Vraag is in hoeverre dat acceptabel is.

Zo dacht ik er dus ook over, maar het artikel van tweakers heeft me doen nadenken. Dat hoeft dus helemaal niet. MPEG2 werd ook ooit gezien als het beste wat er was, en toen divx en ga zo maar door.

[ Voor 31% gewijzigd door Paultje3181 op 16-07-2018 16:01 ]

[DirtyBird]

Ah, vemödalen

[Tomino]

Paultje3181 schreef op maandag 16 juli 2018 @ 15:59:
Dat ligt dan vooral aan mij gok ik zo Maar ja, inderdaad zoiets. Alleen dan veel breder getrokken en uitgaande van de stelling dat alles ooit al gefotografeerd is heeft google/facebook/whoever al de content om de index te maken. Jouw nieuwe foto van de grandcanyon wordt dan opgeslagen als

code:

ref=[hash van master]
refmatch=0.9999994
ref2=[hash ander bestand wat lijkt]
ref2match=0.99991
dif=[patch]

Waarbij de patch groter is (en dus de bestandsgrootte) als jouw stuk meer afwijkt van de master => Vandaar de mogelijkheid om de juiste master te kiezen. Maar als je een optimum vindt tussen de best and worst match (top 20 van beide?), kun je gaan filteren.
Nieuw bestand=match 0.01 => Ga naar slechtste referentie om daar 0.99999999 te scoren bij wijze van.


[...]

Zo dacht ik er dus ook over, maar het artikel van tweakers heeft me doen nadenken. Dat hoeft dus helemaal niet. MPEG2 werd ook ooit gezien als het beste wat er was, en toen divx en ga zo maar door.

De code kan dan verwerkt worden in de Camera Restricta

Algorithms are already looking through the viewfinder alongside with you: they adjust settings, scan faces and take a photo when you smile. What if your grin wasn't the only thing they cared about?

Camera Restricta is a speculative design of a new kind of camera. It locates itself via GPS and searches online for photos that have been geotagged nearby.
If the camera decides that too many photos have been taken at your location, it retracts the shutter and blocks the viewfinder. You can't take any more pictures here

.

[heuveltje]

Paultje3181 schreef op maandag 16 juli 2018 @ 15:43:
@PageFault @CH4OS @Droefsnoet Dit zijn juist allemaal voorbeelden van content. Mijn focus voor deze discussie ligt op de manier van compressie toepassen en de opslagcontainer. Hoe krijg je een zo klein mogelijk plaatje met maximale kwaliteit.

@Tsjipmanz Dit lijkt inderdaad precies te zijn wat ik bedoel. De conclusie is dus dat het idee werkt, maar individuele png optimisatie toch beter is, maar veel langzamer is. Mijn vraag is dan in de eerste plaats: wat als je referentiekader groter is (de index), zodat je hier veel minder van weg hoeft te schrijven en je je puur kunt focussen op het echte verschil (namelijk de persoon die er op staat). In 2015 was het verschil een factor 10 minimaal in tijd. Als die tijd besteed wordt aan het doorzoeken van de veel grotere database, krijg je ongetwijfeld een grotere compressie. Tenslotte valt en staat alles met de juiste keuze van de bron in je index. Als je kijkt naar set 1 en 2 in je referentie, zie je een verschil van 2,5% tussen de beste PNG en de binary/ImagoO vergelijking. Als je hierin een grote index opneemt in plaats van het random kiezen welke toevallig de eerste is, zal dit dus werken. Vraag is alleen hoe je begint met vergelijken.

Upload -> Random -> kijk naar referentiematches en ga filteren om zo de beste match te krijgen. En dus de kleinste patch.
He, kak. Dus toch niet origineel genoeg
@PageFault :
[afbeelding]
Good enough for me. Lijkt redelijk gelukkig. Goed genoeg iig om een vergelijking te maken. En anders is de patch file tussen deze twee niet al te groot. Vooral de monden [afbeelding]

Ik denk dat je de huidige techniek wat overschat.
Er is een foto van jouw, maar ook in die hoek, met die belichting, met net die blik op je ogen etc.
Je zou eigenlijk geen foto moeten hebben, maar een 3d model, dan moet je noch je precieze kleding, vermoeidheid, groei van je baard en weet ik nog meer wat voor exotische variablen.

Dan zou je in theorie kunnen proberen de foto te renderen. wat een supercomputer moet worden, want die moet de huidige wind berekenen, en hoe dat invloed heeft op jouw haar
Of je slaat hem gewoon op natuurlijk

tldr. Wat je nu beschrijft is 3d modeling, geen fotografie

[Paultje3181]

DirtyBird schreef op maandag 16 juli 2018 @ 16:01:
Ah, vemödalen

Inderdaad, maar dan dat (geniaal woord overigens) gebruiken om je opslag te optimaliseren. Voor jou is het plaatje speciaal, maar het bestaat allang. Geen reden om hem dan maar weg te flikkeren... Maar om op te slaan waarom het plaatje voor jou speciaal is.

[CH4OS]

Punt is natuurlijk wel, dat de technieken ook niet stil staan, dus ergens is het ook wel kort door de bocht om te zeggen dat alles al eens gefotografeerd is. Ik maak een HDR-foto liever met nieuwere foto's dan met oude, bijvoorbeeld omdat de nieuwere foto's veel gedetailleerder zijn, omdat ze veel meer pixels bevatten. En daarbij zit ik er ook niet op te wachten om oud en nieuw samen te moeten voegen.

[ Voor 11% gewijzigd door CH4OS op 16-07-2018 16:09 ]

[715289]

Nav deze stelling is het volgende artikel wellicht de moeite van het lezen waard.

https://petapixel.com/201...ly-shot-millisecond-time/

[Paultje3181]

715289 schreef op maandag 16 juli 2018 @ 21:09:
Nav deze stelling is het volgende artikel wellicht de moeite van het lezen waard.

https://petapixel.com/201...ly-shot-millisecond-time/

Dat lijkt me ook echt wel heel erg bizar. Wel leuk om te testen wat in zo'n geval de bestandsgrootte zou worden in mijn "container". Maar dit is wel een extreem voorbeeld van mijn idee....l

[Gomez12]

Paultje3181 schreef op maandag 16 juli 2018 @ 23:37:
[...]

Dat lijkt me ook echt wel heel erg bizar. Wel leuk om te testen wat in zo'n geval de bestandsgrootte zou worden in mijn "container". Maar dit is wel een extreem voorbeeld van mijn idee....l

Maar ik denk wel dat dit juist heel mooi de problematiek van jouw idee weergeeft.

Want de bestandsgrootte zal net afhankelijk van hoe je wilt coderen klein of groot zijn.
Zeker als je verschillen wilt gaan beschrijven dan gaat het een groot bestand worden, want er zijn veel, heel veel verschillen. En een verschil beschrijven zal altijd meer info zijn dan een pixel-kleur beschrijven.

Het probleem met jouw idee is dat we ondertussen op nivo's zitten qua fotografie dat we met het menselijke oog geen verschillen meer zien die er nog steeds inzitten.
Elke foto van de grand canyon is op pixel-nivo anders, elke foto van een t-shirt is op pixel nivo anders.
Oftewel je sterft aan de verschillen.

Wat je zou kunnen doen is :
- Eerst de foto downscalen naar een redelijk klein formaat (zeg 1000x1000)
- Dan gooi je hier een blur eroverheen, deze werkt de pixel-verschillen weg.

Anders gaat op een 12 MP RAW-foto grofweg de helft van de pixels anders zijn ook al zie jij 0 verschil met je ogen, nog even daargelaten dat een andere lens 100% andere pixels gaat geven, laat staan een andere camera.

Wat je theoretisch zou kunnen doen is je 12 MP RAW-foto in delen opdelen en dan in je library gaan kijken naar waar die delen ook voorkomen, alleen dan heb je wel een gigantische library nodig want een stukje van 100x100pixels van een nikon camera in een grand-canyon foto kan dan opeens overeenkomen met een 100x100 pixels stukje van een canon camera van de egyptische sahara, terwijl het nergens overeenkomt met 10.000 foto's van de grand canyon.
Alleen dit laatste is niets nieuws, dit is (super simplistisch gezegd) ook hoe jpg/png werken, alleen heeft jpg dan 8x8 blokken en is de library de rest van het plaatje.

[ehtweak]

Ok, stof tot nadenken.

Opslag = kosten = milieuschade etc. Vanuit dit maatschappelijk oogpunt alleen al, is het wenselijk dat we niet zomaar dom blijven fotograferen en alles online blijven plempen.

-Kosten? Milieuschade? 'Dom' fotograferen? Beetje (erg, heel erg) kortzichtig.
Laten we dan beginnen met de aanschaf van al die megapixel gear. Alleen al de ontwikkeling en productie daarvan is 'dom'. Nergens voor nodig. Immers, alles is al gefotografeerd! Toch?

-Oh, maar wacht ff. Dan moeten al die reizen naar al die al lang gefotografeerde plekken ook uitgebannen worden! Nergens voor nodig; is allemaal al gefotografeerd! Toch?

-Al die websites, al die reclame, al die marketing, al die productie, al dat transport. Alleen maar om die plaatjes te maken die al gemaakt zijn! Toch?

Maar ff met beide benen op de grond:
Heb ik wel eens wat gefotografeerd wat al gefotografeerd was? Vast wel. Maar om nou te zeggen dat dat altijd hetzelfde resultaat opleverde, laat staan überhaupt in de buurt kwam? Nou.... nee!
https://www.flickr.com/photos/chasa-imago/albums

Leuk voorbeeld: voordat ik klaar was met de pp van deze opname:

KaprunStauseen38 by Erik Haak, on Flickr
heb ik diverse websites afgezocht om te kijken of iemand het op die wijze en in die kwaliteit in beeld had gebracht. En dat kon ik niet vinden...

[Ventieldopje]

ralpje schreef op maandag 16 juli 2018 @ 13:37:
Lees je eens in op 'data deduplication'

Ja, nou, dit dus. Wordt oa gebruikt om backups en voor zover ik weet voornamelijk statische data op te slaan die niet vaak nodig is.

Het op pixel niveau (of benadering er van) doen voor fotos is misschien interessanter maar lossy compressie als JPG gooit al snel roet in het eten ben ik bang. De kracht die het kost en weegt niet op tegen wat je wint als je het vergelijkt met een modern formaat als WebP of BPG.

Met RAW fotos kun je het vergeten om het op pixel niceau te doen want je wil dat alle data behouden blijft, los van de gebruikelijke problemen om RAWs te ontleden. Gewone data-deduplication kan dan beter helpen.

Overigens, meer data betekend niet direct meer stroom verbruik omdat schijven ook steeds groter worden. Als je even nagaat dat je vroeger voor 1TB opslag een woonwijk nodig had met dito stroomvoorziening Daarbij zijn datacenters ook telkens aan het innoveren op het gebied van duurzaamheid.

[ehtweak]

En? Is alles al gefotografeerd?

blijkbaar wel... ik zie weinig nieuwe foto's...