[Wiskunde/excel] area van overlappende driehoeken berekenen

[Anoniem: 303530]

Men neme 2 driehoeken:



Deze 2 driehoeken overlappen elkaar altijd. De mate waarin kan wel verschillen.

De vraag is dan: hoe bereken is de area van het gedeelte waar de driehoeken zich overlappen, in dit geval het gele gedeelte.

Met google is bar weinig te vinden over dit onderwerp: niets op stackoverflow en andere fora, de hits bestaan voor het grootste deel uit dezelfde vraag als in dit topic word gesteld zonder antwoord

Dit is geen huiswerkopdracht, ik zoek een manier om, bij voorkeur met excel, de dekking in procenten te berekenen.

---

Ik dacht dat ik kon berekenen welke driehoek het kleinste is, vervolgens bereken je via-via de arena van de driehoek die buiten de andere driehoek ligt. Maar om diverse redenen bleek dat niet te werken. Met name als het gedeelte buiten de driehoek meer dan 3 zijden heeft.

[Wouter.S]

Zijn er ook begrenzingen op het aantal vrijheidsgraden? Denk bijvoorbeeld aan valt er steeds een hoekpunt samen ed ? Of is de enige zekere/vaste factor dat er minstens een stuk overlapping is en voor de rest compleet random ?

[Anoniem: 303530]

Compleet random, de coordinaten zijn altijd positief en vallen binnen het CIE 1913 color space:



edit: een real-life voorbeeld ziet er ongeveer zo uit:



de vraag is dus hoe groot de area is waar het blauwe vlak het rode overlapt, daaruit volgt een percentage wat in dit geval rond de 99% zal liggen.

[ Voor 43% gewijzigd door Anoniem: 303530 op 21-01-2011 16:52 ]

[Kid Jansen]

Alle punten liggen altijd in dat gekleurde vlak (inclusief de rand). Je weet altijd van alle hoekpunten de x en y coördinaten, voor de rest zijn er niet echt beperkingen voor zover ik weet.

EDIT: Darkstone was me voor, dus even post aangepast.

[ Voor 28% gewijzigd door Kid Jansen op 21-01-2011 16:47 ]

[Feanathiel]

Zie het als twee losse operaties. In de eerste operatie los je het overlappende deel op (gele)[1], ook wel clipping genoemd, en in de tweede operatie bereken je de oppervlakte van die polygon die je overhoudt [2].

1: http://cs1.bradley.edu/public/jcm/weileratherton.html
2: http://local.wasp.uwa.edu.au/~pbourke/geometry/polyarea/

[ Voor 15% gewijzigd door Feanathiel op 21-01-2011 16:56 ]

[AutCha]

Je berekent de snijpunten van de driehoeken, en dat beschouw je als een convexe polygoon waar je vervolgens dit algoritme op loslaat: http://www.mathwords.com/a/area_convex_polygon.htm

Zoiets?

[Wouter.S]

Een mogelijke oplossing is om van elke zijde van je driehoeken de vergelijking te berekenen. Dan stel je rond je uiterste punten een vierkant of rechthoekig kader op waar beide driehoeken binnen vallen. Dit kader deel je dan op in een rooster. Elk centrum van een roostervakje heeft dan een x-y coordinaat. Dan ga je voor elk punt na of het in de driehoek ligt aan de hand van de vergelijkingen van de zijden. Dan heb je bijvoorbeeld dat de ene driehoek 10 000 punten bevat en dat er van die 10 0000 7000 ook in de andere driehoek liggen.
Hoe fijner je rooster hoe accurater de oplossing.

Edit: AutCha zijn oplossing lijkt me iets eenvoudiger, maar bij nader inzien zal niet elke situatie snijpunten opleveren dus moet er toch nog wat getweaked worden.

[ Voor 11% gewijzigd door Wouter.S op 21-01-2011 16:56 ]

[Japidoff]

maar van het binnentse deel 2 nieuwe driehoeken door een lijn te tekenen van hoek 1 naar hoek 3 van de veelhoek, nu heb je 2 driehoeken waar je makkelijk de oppervlakte van kan uitrekenen.

ik zou zelf voor Wouter.S zn opslossing gaan bij nader inzien...

offtopic:
gratz wouter

[ Voor 22% gewijzigd door Japidoff op 21-01-2011 17:00 ]

[Anoniem: 303530]

Wouter.S schreef op vrijdag 21 januari 2011 @ 16:48:
Een mogelijke oplossing is om van elke zijde van je driehoeken de vergelijking te berekenen. Dan stel je rond je uiterste punten een vierkant of rechthoekig kader op waar beide driehoeken binnen vallen. Dit kader deel je dan op in een rooster. Elk centrum van een roostervakje heeft dan een x-y coordinaat. Dan ga je voor elk punt na of het in de driehoek ligt aan de hand van de vergelijkingen van de zijden. Dan heb je bijvoorbeeld dat de ene driehoek 10 000 punten bevat en dat er van die 10 0000 7000 ook in de andere driehoek liggen.
Hoe fijner je rooster hoe accurater de oplossing.

Dat zou in principe voldoen, ik vraag me alleen of hoe je dat met excel voor elkaar wilt krijgen? De performance maakt in principe niet uit, maar deze oplossing ziet eruit alsof hij wel even kan duren.

Feanathiel schreef op vrijdag 21 januari 2011 @ 16:46:
Zie het als twee losse operaties. In de eerste operatie los je het overlappende deel op (gele)\[1], ook wel clipping genoemd, en in de tweede operatie bereken je de oppervlakte van die polygon die je overhoudt \[2].

1: http://cs1.bradley.edu/public/jcm/weileratherton.html
2: http://local.wasp.uwa.edu.au/~pbourke/geometry/polyarea/

Dat ziet er leuk uit, ik ga me even inlezen op de dat clipping algoritme.

[Soultaker]

Wat je zoekt is intersectie van (convexe) polygonen. Dit is een niet al te ingewikkeld meetkundig probleem. Het makkelijkst is het te implementeren door een polygoon te clippen tegen een enkel lijnstuk; dan kun je vervolgens tegen een driehoek clippen door simpelweg tegen elke zijde te clippen.

AutCha's aanpak werkt ook goed, met een kanttekening: als je het op meerdere driehoeken tegelijk wil toepassen, moet je nog van alle snijpunten controleren of ze binnen alle driehoeken liggen. Vandaar dat het misschien handiger is om één voor één te clippen.

[Japidoff]

wat voor ding heb je nou precies?
een bitmap? een lijst met coordinaten of iets met vectoren ofzo?

[Anoniem: 303530]

Japidoff schreef op vrijdag 21 januari 2011 @ 17:09:
wat voor ding heb je nou precies?
een bitmap? een lijst met coordinaten of iets met vectoren ofzo?

Een lijst met Coordinaten van de driehoeken.

[Kid Jansen]

Misschien wordt het wat simpeler als er één driehoek altijd hetzelfde is, of eigenlijk twee mogelijke situaties:

Adobe RGB:
Rx 0,640
Ry 0,330
Gx 0,210
Gy 0,710
Bx 0,150
By 0,060

sRGB:
Rx 0,640
Ry 0,330
Gx 0,300
Gy 0,600
Bx 0,150
By 0,060

Eventueel kunnen daar nog een aantal situaties bij, maar meer dan 10 zullen het er niet snel worden, zie ook Wikipedia: RGB color space

R, G en B slaan op rood, groen en blauw. Waar Darkstone en ik dit voor willen gebruiken is het berekenen van de dekking voor de Adobe RGB en sRGB kleurruimtes van beeldschermpanelen. (zie ook [Oproep] Screenies MonitorAssetManager voor panelDB laptops)

Voor de andere driehoek, de willekeurige driehoek, heb je met de volgende bereiken denk ik wel vrijwel alle schermen.

Rx 0,550 - 0,700
Ry 0,290 - 0,360
Gx 0,175 - 0,350
Gy 0,525 - 0,725
Bx 0,140 - 0,170
By 0,040 - 0,160

Dan blijven er natuurlijk nog steeds heel veel combinaties over, maar het maakt het probleem al een heel stuk specifieker.

[ Voor 24% gewijzigd door Kid Jansen op 21-01-2011 20:14 ]

[Maethor2]

Mijn eerste idee zou zijn om de punten in de driehoek op te schrijven als lineaire combinaties van de punten van de driehoek.

Driehoek 1:

x = ax₁ + bx₂ + cx₃
y = ay₁ + by₂ + by₃
a + b + c = 1

Driehoek 2:

v = dx₁ + ex₂ + fx₃
w = dy₁ + ey₂ + fy₃
d + e + f = 1

Stelsel oplossen waar x = v en y = w met restricties a + b+ c = 1 en d + e + f = 1

ax₁ + bx₂ + cx₃ = dx₁ + ex₂ + fx₃
ay₁ + by₂ + by₃ = dy₁ + ey₂ + fy₃
a + b + c = 1
d + e + f = 1

Dit zou uiteindelijk iets moeten opleveren dat de punten in je doorsnede weergeeft als lineaire combinaties van de hoekpunten ervan. Vervolgens kun je de oppervlakte berekenen.

Geen idee of het wat oplevert, als ik wat tijd heb ga ik eens rekenen. Voor hetzelfde geld sla ik de bal hier compleet mis.

[KopjeThee]

Misschien dat dit artikeltje helpt A simple linear algorithm for intersecting convex polygons. Is wel iets algemener, maar zou voor 2 direhoeken vrij eenvoudig moeten zijn.

[Anoniem: 303530]

Weet je zeker dat dat de goede is? het lijkt nergens op, en de extensie .ps, wat blijkbaar postscript betekent ken ik niet.

Maethor2 schreef op vrijdag 21 januari 2011 @ 19:26:
a + b + c = 1

[Soultaker]

Tip: je kunt de extensie in de URL vervangen door PDF en dan werkt 'ie ook. Zijn wel je pagina's verkeerd om.

[.oisyn]

Anoniem: 303530 schreef op vrijdag 21 januari 2011 @ 21:10:

barycentric coordinates

[Maethor2]

Anoniem: 303530 schreef op vrijdag 21 januari 2011 @ 21:10:
[...]

De restrictie dient om ervoor te zorgen dat de punten binnen de driehoek liggen. Als je zou toelaten dat de waarde groter is dan laat je alle waarden in het vlak toe en zal de oplossing altijd het vlak zijn.

Naamgeving was wel verkeerd gisteren:

Gegeven:

Twee driehoeken met coôrdinaten
{(x₁,y₁),(x₂,y₂),(x₃,y₃)}
{(x₄,y₄),(x₅,y₅),(x₆,y₆)}

-->

ax₁ + bx₂ + cx₃ = dx₄ + ex₅ + fx₆
ay₁ + by₂ + by₃ = dy₄ + ey₅ + fy₆
a + b + c = 1
d + e + f = 1

~

ax₁ + bx₂ + cx₃ - dx₄ - ex₅ - fx₆ = 0
ay₁ + by₂ + by₃ - dy₄ - ey₅ - fy₆ = 0
a + b + c - 1 = 0
d + e + f - 1 = 0

Punten invullen, even in de rekenmachine/maple stoppen en je zou moeten weten wat de uitdrukkingen voor a,b,c,d,e,f zijn. Je vult die waarden in je oorspronkelijke vgl met de coördinaten als vrije parameters en dan heb je een uitdrukking voor je intersectie. Daarvan bereken je de oppervlakte.

Die barycentrische coördinaten hierboven zien eruit alsof ze niet toelaten dat a,b,c,d,e,f waarden kunnen aannemen tussen 0 en 1, maar enkel 0 en 1. Dat is hier niet het geval want we willen de complete driehoek beschrijven. Kan het mis hebben ook, nog nooit gehoord van die dingen.

[Anoniem: 334914]

2 Manieren, de eerste zoals hierboven al beschreven staat om je driehoek te clippen met de andere driehoek, en de rest te trianguleren.
En de 2e is en lijkt mij het snelst te programmeren is om eerst de ene driehoek te tekenen( bijvoorbeeld met rood) dan vervolgens teken(met blending aan) de andere driehoek( met rood ) . En tel het aantal pixels dat paars is;)

[Aloys]

Jag, ik wilde net bovenstaande oplossing aanbevelen. Misschien niet de meeste nette oplossing, maar in elk geval heb je het qua code zo gepiept .

[Anoniem: 303530]

Volgens mij hebben een aantal mensen het "excel" gedeelte in de titel gemist.

Ik kom er nog niet uit, het is een stuk moeilijker dan het lijkt om met excel snijpunten van een stel lijnen te berekenen, jammer dat er geen shortcut bestaat.

[Mijzelf]

Volgens mij hebben een aantal mensen het "excel" gedeelte in de titel gemist.

In Excel kun je toch ook VBA script uitvoeren? Dat maakt het allemaal een stuk eenvoudiger.

[.oisyn]

Maethor2 schreef op zaterdag 22 januari 2011 @ 10:06:
Die barycentrische coördinaten hierboven zien eruit alsof ze niet toelaten dat a,b,c,d,e,f waarden kunnen aannemen tussen 0 en 1, maar enkel 0 en 1. Dat is hier niet het geval want we willen de complete driehoek beschrijven. Kan het mis hebben ook, nog nooit gehoord van die dingen.

Nee, wat jij beschrijft is gewoon een barycentrisch coördinatenstelsel. De (a,b,c) vormen de coördinaten voor de punten in het vlak. En bij a+b+c=1 liggen ze binnen het driehoek. En aangezien (d,e,f) ook punten in datzelfde vlak beschrijven, kun je (d,e,f) transformeren naar (a,b,c). Verder geldt dat a+b+c=1, dus c=1-a-b. Dit brengt de vergelijking terug naar slechts 2 onbekenden. Leesvoer.

Of je verder wat aan je aanpak hebt betwijfel ik ten zeerste. Je moet uiteindelijk de polygoon van de intersectie beschrijven in dat coördinatenstelsel, en dan ook nog eens aan de hand van een vergelijking met onbekenden. Dan is een simpel Sutherland-Hodgman clipping algoritme een heel stuk pragmatischer.

[ Voor 30% gewijzigd door .oisyn op 22-01-2011 15:00 ]

[SmiGueL]

Ik vind het wel een leuke opdracht,
Zal vanmiddag eens kijken of ik mijn VBA kennis (2 jaar geleden gebruikt) nog een beetje beheers, en het dan op Wouter.S's methode op kan lossen
(uiteraard variabele gridgrootte, afhankelijk van benodigde precisie en aanvaardbare rekentijd)

[Anoniem: 303530]

De benodigde precicie is niet zo heel groot, ik wil het percentage weten waarin het rode vlak (zie 3e plaatje) gedekt is, 2 decimalen voldoet.

[blackangel]

Mag je aannames doen over de driehoeken?

Ik zou zelf werken met om en nabij: Voor lijn PQ, knip alles wat links van PQ ligt (that is, buiten PQR) weg. Dat is een driehoek. Voor lijn QR en RP hetzelfde. In jouw voorbeelden gaat dat goed, in algemene gevallen niet.


Anders wat complexer, kies de hoekpunten a,b,c van ABC en p,q,r van PQR.

(I) Neem aan dat alle hoekpunten van PQR buiten ABC liggen. Ga vervolgens tellen hoeveel punten van ABC buiten PQR liggen:
0: ABC ligt binnen PQR (result=area(ABC))
1: a ligt buiten PQR. Zoek de snijpunten s1,s2 van ABC met PQR, bereken het oppervlak a,s1,s2 dat valt buiten ABC, de rest binnen (result= area(ABC)-area(a,s1,s2))
2: a,b, liggen buiten PQR. Kies de zijde die a van c afscheid: ligt b aan dezelfde kans als a; de driehoek s1,s2,c is alles wat binnen PQR ligt =area(s1,s2,C). Ligt b niet aan dezelfde zijde, doe 2x (1) (result=~ area(ABC)-area(a,s1,s2)-area(b,s3,s4)))
3: Of ABC en PQR overlappen niet, of a en b liggen aan dezelfde zijde (doe 2) en c niet (1).

(II) Andersom ook als alle punten van PQR binnen ABC vallen, zelfde methode.

(III) Het laatste geval is onhandig om uit te leggen, maar er ligt a in PQR en een p in ABC. Kies de snijpunten s1, s2 van de driehoeken, en het area(a,s1,s2)+area(p,s1,s2) is het oppervlak.


Het zal een rotwerk worden om dit te implementeren in Excel, maar het is redelijk straight forward. Juist omdat je met maar een beperkt aantal hoekpunten zit, hoef je het niet iteratief te doen. Verder het probleem wat je hebt is wat doe je als een hoekpunt op een zijde ligt? Ik ga er nu vanuit dat het dan niet buiten de driehoek ligt, maar juist in geval (III) zul je moeilijk moeten doen. Maar as I said, misschien kun je het makkelijkste gewoon aannames doen dat dit niet mag voorkomen

[Kid Jansen]

Ik heb de bereiken van de coördinaten al gegeven, vrijwel altijd drie significante cijfers per coördinaat, alleen By is soms maar twee significante cijfers. Als de precisie van het algoritme met vier of vijf significante cijfers werkt intern moet het wel al genoeg zijn, meer dan dat voegt echt niks toe.

Resultaat in twee of drie significante cijfers (bijvoorbeeld 96.3% Adobe RGB, maar 96% ook goed).

[.oisyn]

blackangel schreef op zaterdag 22 januari 2011 @ 17:11:
Mag je aannames doen over de driehoeken?

Ik zou zelf werken met om en nabij: Voor lijn PQ, knip alles wat links van PQ ligt (that is, buiten PQR) weg. Dat is een driehoek. Voor lijn QR en RP hetzelfde. In jouw voorbeelden gaat dat goed, in algemene gevallen niet.

Dat is dus gewoon Sutherland-Hodgman. In het algemene geval hou je hooguit een zeshoek over.

code:

V = vertices of triangle A.
for each edge 'e' in B
{
    NewV = { }
    for each vertex 'v' in V
    {
        if (v in front of e)
            NewV.add(v)
        if ((v in front of e) != (next(v) in front of e)
            NewV.add(e.intersect(v, next(v))
    }
    V = NewV
}

V bevat nu de vertices van de intersection van A en B. Die is leeg als ze helemaal niet overlappen, 1 als ze elkaar op een vertex raken, 2 als ze elkaar met een edge raken, of 3 t/m 6 vertices als ze elkaar overlappen.

[ Voor 34% gewijzigd door .oisyn op 22-01-2011 17:30 ]

[Soultaker]

Wat voor programmeeromgeving heeft Excel eigenlijk? Is er support voor .NET integratie bijvoorbeeld? (Dat lijkt me win-win voor Microsoft: enerzijds bindt je Office-gebruikers aan .NET, en anderzijds kunnen Office-gebruikers gebruik maken van een programmeeromgeving die een stuk zinniger is dan halfbakken macro/scripttalen die doorgaans in dit soort suites verwerkt zitten.)

Op zich zijn dit soort dingen in elke taal wel op te lossen (zeker als performance niet van groot belang is) als je een beetje kunt rekenen en simpele datastructuren als lijsten kunt manipuleren.

Ik heb mijn eerder genoemde aanpak uitgewerkt, en dat lijkt wel redelijk te werken: http://pastebin.com/deahuEUH

Het komt feitelijk neer op het Sutherland-Hodgman algoritme dat al genoemd was, maar simpeler, omdat alleen convexe polygonen gebruikt worden. (Met concave of complexe polygonen wordt de clip() functie ingewikkelder.)

Ik hou er meestal niet van om kant-en-klare code te posten, maar in dit geval maak ik een uitzondering omdat je ten eerste de code zelf naar Excel moet converteren, en ten tweede omdat de code nauwelijks getest is, dus moet je 'm sowieso nog even goed doorpluizen.

(Ik moet ook zeggen dat ik de eigen inzet een beetje mis in dit topic; van een moderator -- uit een ander subforum, maar toch -- valt me dat een beetje tegen. Er zijn genoeg mogelijkheden genoemd waarmee je zeker aan de slag zou kunnen!)

[Anoniem: 303530]

Soultaker schreef op zaterdag 22 januari 2011 @ 17:37:
(Ik moet ook zeggen dat ik de eigen inzet een beetje mis in dit topic; van een moderator -- uit een ander subforum, maar toch -- valt me dat een beetje tegen. Er zijn genoeg mogelijkheden genoemd waarmee je zeker aan de slag zou kunnen!)

Dat doe ik ook, ik ben op dit moment aan het bedenken hoe ik met excel bereken waar de snijpunten van de driehoeken liggen, met name omdat je dan een variabel aantal punten hebt levert dat nogal wat problemen op: voor zover ik weet heeft excel geen lijsten of iets dergelijks.

Mijn wiskunde kennis is ook nogal weggezakt..

[ Voor 3% gewijzigd door Anoniem: 303530 op 22-01-2011 17:46 ]

[DrBOB101]

Ziet er uit als een leuke uitdaging Welke versie Excel heb je?
Wil je het met formules doen in cellen, of mag er best een macro achter zitten?

[KopjeThee]

Anoniem: 303530 schreef op zaterdag 22 januari 2011 @ 17:44:
[...]

Dat doe ik ook, ik ben op dit moment aan het bedenken hoe ik met excel bereken waar de snijpunten van de driehoeken liggen, met name omdat je dan een variabel aantal punten hebt levert dat nogal wat problemen op: voor zover ik weet heeft excel geen lijsten of iets dergelijks.

Mijn wiskunde kennis is ook nogal weggezakt..

Excel is niet veel meer dan lijsten, volgens mij

Je zult je een beetje moeten verdiepen in VBA,

Een snijpunt berekenen, gegeven 2 paar punten is niet zo lastig (onderbouw middelbare school). Dit zal je moeten doen voor elke lijn in de ene driehoek met alle lijnen uit de andere driehoek.

Zeg dat we 2 lijnen hebben AB en CD en we willen het snijpunt berekenen.
De x en y coordinaat van punt A noteer ik even als Ax en Ay, zo ook voor de andere punten.

De algemene fomule voor een lijn is:
y = ax + b
a is de richting van de lijn.
b is de y coordinaat die bij x=0 hoort. De hoogte.

De formule voor lijn AB is:
y = aAB*x + bAB
aAB is de richting van lijn AB
bAB is de hoogte van lijn AB
aAB = (By-Ay)/(Bx-Ax)

b moeten we nog bepalen, we weten dat de lijn door punt A gaat, dus:
Ay = aAB*Ax + bAB. Dus:
bAB = Ay - aAB*Ax

De formule voor lijn CD is vergelijkbaar, dus:
y = aCD*x + bCD

De x coordinaat van het snijpunt van AB en CD is dus waar:
aAB*x + bAB = aCD*x + bCD Dus
x*(aAB-aCD) = bCD - bAB Dus
x = (bCD - bAB)/(aAB-aCD)

De y coordinaat is eenvoudig in te vullen:
y = aAB*x + bAB invullen levert:
y = aAB*(bCD - bAB)/(aAB-aCD) + bAB

Dit gaat alleen mis als aAB = aCD, dan wordt door 0 gedeeld. Dit is de situatie waar AB en CD evenwijdig zijn.

[.oisyn]

Soultaker schreef op zaterdag 22 januari 2011 @ 17:37:
Het komt feitelijk neer op het Sutherland-Hodgman algoritme dat al genoemd was, maar simpeler, omdat alleen convexe polygonen gebruikt worden. (Met concave of complexe polygonen wordt de clip() functie ingewikkelder.)

Sutherland-Hodgman werkt sowieso alleen met convexe clipping polygons, en voor concave en complexe polygons heeft het verder geen speciale handling.

KopjeThee schreef op zaterdag 22 januari 2011 @ 18:32:
Een snijpunt berekenen, gegeven 2 paar punten is niet zo lastig (onderbouw middelbare school). Dit zal je moeten doen voor elke lijn in de ene driehoek met alle lijnen uit de andere driehoek.

Ik zou lijnstukken met lijnstukken snijden laten voor wat het is, daar je het niet nodig hebt en het de boel alleen maar complexer maakt dan het is. Een driehoek is altijd convex, dus je hoeft in feite alleen maar lijnstukken te snijden met een lijn (een lijnstuk is eindig, een lijn is oneindig).

[ Voor 38% gewijzigd door .oisyn op 22-01-2011 18:51 ]

[Soultaker]

Ik dacht dat je wel een niet-convexe polygoon kon clippen (tegen een convexe clipping polygon dus) of heb ik dat verkeerd? In dat geval wordt de functie die een polygoon clipt tegen een semiplane wel ingewikkelder, toch? (Je zou kunnen stellen dat dat buiten het algoritme op zich valt, natuurlijk.)

[ Voor 15% gewijzigd door Soultaker op 22-01-2011 18:45 ]

[.oisyn]

Het punt is dat Sutherland-Hodgman is niet geschikt voor cases waarin je output meerdere polygonen zijn. Of althans, die meerdere polygonen zullen dan aan elkaar verbonden zijn met degenerate edges. Het algoritme houdt dus verder geen rekening met die cases, waardoor de implementatie voor convexe input net zo simpel is als die voor comcave input. Met complexe polygonen doet het algoritme sowieso niets, aangezien het uitgaat van 1 cycle van verts

[ Voor 39% gewijzigd door .oisyn op 22-01-2011 19:00 ]

[Caelorum]

Soultaker schreef op zaterdag 22 januari 2011 @ 17:37:
Wat voor programmeeromgeving heeft Excel eigenlijk? Is er support voor .NET integratie bijvoorbeeld? (Dat lijkt me win-win voor Microsoft: enerzijds bindt je Office-gebruikers aan .NET, en anderzijds kunnen Office-gebruikers gebruik maken van een programmeeromgeving die een stuk zinniger is dan halfbakken macro/scripttalen die doorgaans in dit soort suites verwerkt zitten.)

In Excel 2007 en 2010 is het mogelijk om C# addins en workbooks etc te maken., zie bijv. http://blogs.msdn.com/b/g...e-how-does-that-work.aspx.

[Anoniem: 334914]

Hehe of gewoon 2 bsp-tree's( bestaan die nog; ) van de 2 input triangles maken en die tegen elkaar clippen, hou je perfecte convex geometry over( in dit geval )

[SmiGueL]

Whoooooooooooooohoo got it!

1. Vul de dikgedrukte velden in (aka: coordinaten van hoekpunten van driehoeken)
2. Let erop dat dit per driehoek met de klok mee gebeurd (anders klopt het soms niet, heb niet zoveel zin om dit te fixxen XD)
3. Vul voor gridsize een getal tussen de 1000 en 10000 in.
1000 geeft een 'check' van 1000 x 1000 = 1000000 coördinaten of er een overlap is (duurt halve sec.)
10000 geeft een 'check' van 10000 x 10000 = 100 miljoen coördinaten of er een overlap is (duurt half minuutje op redelijke pc)
4. Klik op Bereken.

Onderaan wordt de overlap t.o.v. Driehoek 1 en Driehoek 2 weergegeven (Weet niet welke je nodig bent?)

Bij vragen meldt maar

*Er worden geen rechten ontleend aan bovenstaand bestand. Ik heb het met enkele simpele driehoeken getest waarvan ik de uitkomsten zelf ongeveer kon schatten, maar probeer dit aub zelf ook eerst ff

[ Voor 16% gewijzigd door SmiGueL op 22-01-2011 20:17 ]

[Anoniem: 303530]

Ik waardeer de moeite ten zeerste Maar bij het openen van het document krijg ik een fine melding dat word er niet in is geslaagd de corrupte macro's te recoveren (excel 2010)

[Kid Jansen]

Ik wilde alweer gaan gillen hij werkt niet, maar dat was mijn fout (iets met lezen en zo...)

Held!

Je moet inderdaad met de klok mee invullen, dus in plaats van RGB wordt het dan RBG (of BGR, of GRB).

Ik heb even een paar geprobeerd en het werkt, wat me alleen opviel met het DreamColor 2 scherm voor de EliteBook 8540w is dat ik een overlap van meer dan 100% kreeg, omdat de Adobe RGB kleurruimte in z'n geheel in het DreamColor 2 kleurbereik past. Komt dat door afronding? (het was 100.0112%)

Kan je ook nog hoger dan die 10000 grid? (niet dat het nodig is)

Nu alleen nog even die CIE 1931 xy diagram als achtergrond instellen bij de grafiek en dat ding is helemaal perfect, heel erg bedankt!

[Anoniem: 303530]

Bij mij doet hij het niet?

maar als hij het bij jou wel doet maakt dat weinig uit..

[SmiGueL]

Als omdraaien makkelijker is zal ik ff kijken of ik dat kan veranderen, moet niet heeel moeilijk zijn om dat te veranderen
(Alleen om BEIDE kanten op een goed resultaat te geven moet ik wss wat langer prutsen, en kost langer rekenwerk ivm meer checks in de berekening)

10000 is natuurlijk niet de max, als jij 100000 x 100000 = 10 miljard points wil dan veel plezier ermee
Rekenen zal dan alleen 100x langer duren, wat neer komt op 20 sec. x 100 = 2000 sec. = een dik half uur

Maargoed, probeer is 10.000, 20,000, (en/of 40.000)? als deze resultaten heeeel dicht bij elkaar liggen (verwaarloosbaar) weet je dat je 100.000 niet eens hoeft te proberen

[Kid Jansen]

Ik gebruik Excel 2007, misschien ligt het daar aan, of die macro voelt zich te goed voor jouw PC

Trouwens nog een vraagje, hoe verander ik de tekst "bereken" van die knop in "calculate"?

EDIT: RGB is inderdaad makkelijker, dus als je dat zou kunnen omdraaien zou dat geweldig zijn. Nu moet je RBG invullen, dus de tweede wordt met de derde verwisseld.

[ Voor 30% gewijzigd door Kid Jansen op 22-01-2011 21:14 ]

[Anoniem: 303530]

kid jansen schreef op zaterdag 22 januari 2011 @ 21:03:
EDIT: RGB is inderdaad makkelijker, dus als je dat zou kunnen omdraaien zou dat geweldig zijn. Nu moet je RBG invullen, dus de tweede wordt met de derde verwisseld.

In sheet 2 van de al bestaande berekenaar stoppen, en een simpele verwijzing maken?

[Wouter.S]

Grappig om 'mijn methode' werkend te zien. Het is waarschijnlijk niet de meest efficiënte aanpak maar het lijkt me een vrij straightforward numerieke benadering van het probleem (een beetje zoals numerieke integratie) en meer is waarschijnlijk ook niet nodig in dit geval

[Kid Jansen]

Nee inderdaad, als de eerste drie à vier significante cijfers maar kloppen, de rest maakt niet uit. Een exacte oplossing is onzin, aangezien die opgegeven coördinaten ook niet exact zijn.

[SmiGueL]

Wouter.S schreef op zaterdag 22 januari 2011 @ 21:17:
Grappig om 'mijn methode' werkend te zien. Het is waarschijnlijk niet de meest efficiënte aanpak maar het lijkt me een vrij straightforward numerieke benadering van het probleem (een beetje zoals numerieke integratie) en meer is waarschijnlijk ook niet nodig in dit geval

Ik heb op deze manier vaker iets opgelost (X-as en Y-as elkaar loopen), dus was er zelf ook al op gekomen
Idd niet erg efficiënt, maar je kan het zo nauwkeurig maken als je zelf wilt
Wordt idd minder grappig als je een 100.000 grid wilt oplossen als er ook een z-as bij komt:P
Kost je kleine 10 jaar om te solven

Doet inderdaad ook zwaar denken aan integreren XD
Wat je dus berekend is de oppervlakte van deze balkjes en dus niet precies die binnen/onder/tussen de lijntjes.
(Nu is het wel zo dat mijn manier een combi is van de dikke blauwe blokjes links, en de lichte blokjes rechts, waardoor de 'fout' reeedelijk opgeheven wordt, en lang niet zo onnaukeurig is als op dit plaatje)
Vandaar dat er altijd een (kleine) afwijking zal zijn


Nu geef ik meteen toe dat mijn code wss zwaaaaaaaaar inefficient is, maar voor huidige toepassing kost het meer tijd om hem te verbeteren dan dat je er uiteindelijk mee opschiet in de berekening

[ Voor 21% gewijzigd door SmiGueL op 22-01-2011 21:50 ]

[Kid Jansen]

Dat hangt er vanaf hoe veel winst je krijgt en hoe lang je daar mee bezig bent. Als jij met een uur sleutelen 10 seconde sneller kan zijn (met 10000 grid), dan halen we het er wel uit, die 360 panelen komen we echt wel aan

don't get me wrong, we zijn hier al heel erg blij mee

[Anoniem: 303530]

Mijn exacte implementatie is bijna kaar, ik zit op dit moment te worstelen met het orderen van de snijpunten, als dat klaar is kopieer ik 4x het gebruikelijke alghoritme voor het berekenen van de oppervlak van een driehoek en tel ik dat bij elkaar op.

Dat was de theorie, nu de praktijk.

[.oisyn]

Anoniem: 303530 schreef op zaterdag 22 januari 2011 @ 22:14:
Mijn exacte implementatie is bijna kaar, ik zit op dit moment te worstelen met het orderen van de snijpunten

Tja, je hebt zeker KopjeThee's suggestie gevolgd?
Je kunt er bijv. een convex hull algoritme overheen halen om de juiste volgorde te vinden

[Anoniem: 303530]

Ja dat klopt. met behulp van wat aannames staan de snijpunten nu in de goede volgorde, ik heb alleen problemen de volgense fictive set van getallen:

code:

0
5
3
0
0
0
6
(...)

om te toveren naar:

code:

5
3
6
0
0
0
0
(...)

Dwz, de padding van nullen moet verwijderd worden. Maar dat gaat mij wel lukken deze avond

Met excel lijkt alles zo verschrikkelijk moeilijk.

edit: Done

[ Voor 8% gewijzigd door Anoniem: 303530 op 22-01-2011 22:36 ]

[Kid Jansen]

Klaar?

[Anoniem: 303530]

Ik zou 5 minuten geleden klaar zijn als ik niet op het laatste moment een division by 0 bug ontdekte in het stuk wat de snijpunten berekent Bij een bepaalde combinatie waar ik nog niet achter ben weigert mn sheet de juiste coordinaten uit te poepen.

[SmiGueL]

Nieuwe versie!

Whehe, aantal bugfixxies:

- Bereken veranderd naar Calculate
- Ipv een ongebruikelijke RBG invoer kan nu RGB ingevoerd worden
- Blad2 laat een mooie(re) grafiek zien (laatste regel van post)
- Performanceimprovement , dikke 50% sneller nu

Mocht je echt honderden monitoren willen testen, dan stel ik voor:

Zet de X & Y coordinaten even in een lijstje onder elkaar:

code:

X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 Y5 X6 Y6
X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 Y5 X6 Y6
X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 Y5 X6 Y6
X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 Y5 X6 Y6
X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 Y5 X6 Y6

(Dit zijn dus 5 schermen, tot xxxx mogelijk dus )

Dan pruts ik wel ff een auto-import en export script in elkaar,
die na een nacht rekenen gewoon de resultaten voor alle honderden schermen in 1x eruit knalt

[ Voor 7% gewijzigd door SmiGueL op 06-06-2011 23:03 ]

[Anoniem: 303530]

Mijn exacte methode wil niet vlotten, het werkt nu op een punt na: mijn algoritme controleert niet of een punt binnen of buiten de driehoek ligt, dat zou overigens niet al te moeilijk moeten zijn om op te lossen. een IF van een meter lang op een bepaalde plek voldoet

offtopic:
Wat ben ik blij met mijn full-hd scherm, ik werk op 90% zoom en de sheet past er net op..

[ Voor 15% gewijzigd door Anoniem: 303530 op 23-01-2011 00:55 ]

[Kid Jansen]

Een lijst heb ik al, van laptoppanelen een stuk of 30 en van desktoppanelen een stuk of 70.

Staan allemaal in deze format:

Paneel fabrikant+type	Rx	Ry	Gx	Gy	Bx	By	% NTSC color gamut	% Adobe RGB color gamut	% sRGB color gamut
AU Optronics bla bla bla	0,640	0,330	0,210	0,710	0,150	0,060	X %	X %	X %

Dus als je hem daar op zou kunnen aanpassen zou dat natuurlijk al helemaal geweldig zijn. Overigens hoeven alleen Adobe RGB en sRGB op deze manier berekend te worden, voor NTSC is relatieve grootte gebruikelijk, daar wordt overlap/dekking bijna nooit bij gebruikt.

In totaal zitten we nu al tegen de 1400 datasheets aan, een deel daarvan staan geen kleurcoördinaten in, maar 1000 komen we wel aan denk ik. Het grootste deel moet dus alleen nog in Excel gezet worden.

EDIT: deze versie is inderdaad een stuk sneller (ik zie dat je ook een timer hebt toegevoegd).

Overigens had ik zelf kolom A als volgt ingevuld:

R1 x,y
B1 x,y
G1 x,y

R2 x,y
B2 x,y
G2 x,y

Grid:

Area red triangle (1)
Area blue triangle (2)

Step size:
Overlap within 1x1

Overlap blue (2) with red (1)
Overlap red (1) with blue (2)


Dat had ik gedaan zodat die Simon Baker van TFT Central dat ding ook kan gebruiken (daar is het allemaal mee begonnen, zie daarvoor ook de startpost van [Oproep] Screenies MonitorAssetManager voor panelDB laptops)

Met die nieuwe versie kan dat natuurlijk in RGB volgorde, in plaats van RBG.

EDIT2: grid boven de 10000 geeft overigens foute resultaten, de gegeven percentages zijn dan te laag (iets wat 97% moest zijn werd 73% met een grid van 12000).

[ Voor 38% gewijzigd door Kid Jansen op 23-01-2011 01:42 ]

[H!GHGuY]

Let op dat veel fabrikanten de size ratio specifieren ipv de coverage:
size(mygamut) / size(referencegamut) = X%
waarbij X gerust groter dan 100% kan zijn.

@hieronder:
Je kan niet verwachten dat ik per post iedereen aan een background check onderwerp.
Trouwens was mijn post niet aan jou maar aan de TS gericht.

[ Voor 33% gewijzigd door H!GHGuY op 23-01-2011 12:18 ]

[Kid Jansen]

Als je even naar mijn eerdere posts op GoT of naar m'n beeldschermreviews had gekeken, dan had je gezien dat ik dat echt al lang wist. Het staat zelfs in de post hierboven:

kid jansen schreef op zondag 23 januari 2011 @ 01:10:
...Overigens hoeven alleen Adobe RGB en sRGB op deze manier berekend te worden, voor NTSC is relatieve grootte gebruikelijk, daar wordt overlap/dekking bijna nooit bij gebruikt...

Lijkt me duidelijk dat ik met relatieve grootte, de grootte van het kleurbereik van de monitor gedeeld door de grootte van het NTSC kleurbereik bedoel.

[Anoniem: 303530]

Hij doet het



rechtsonderin zie je de oplossing, de totale oppervlakte van het blauwe driehoek is 0,11205, in dit geval dus een dekking van precies 84,0249888% (overkill, maargoed.)

Een kleine uitleg over mijn methode: Ik gebruik het alghoritme van theekopje voor het berekenen van de snijpunten, vervolgens word er bepaald welke van de hoekpunten bij de ontstane polygon hoorden.
De polygon word vervolgens opgedeeld in een aantal driehoeken waarvan ik de area bereken, dit kan omdat de hoeken van de polygon altijd kleiner zijn van 180°.

http://dl.dropbox.com/u/18772348/overlapping.xls
werkt alleen indien in RGB opgegeven

Allen bedankt voor de hulp.

[SmiGueL]

kid jansen schreef op zondag 23 januari 2011 @ 01:10:
EDIT2: grid boven de 10000 geeft overigens foute resultaten, de gegeven percentages zijn dan te laag (iets wat 97% moest zijn werd 73% met een grid van 12000).

Weet je zeker dat je daarna weer op Calculate gedrukt hebt?

De 'overlapfactor' wordt berekend door het aantal overlappende punten binnen de hele grid te delen door het totaal aantal punten binnen de driehoek (aka: de oppervlakte )
Stel: je stelt een grid van 1000x1000 in, en er zijn na het drukken op Calculate 500.000 overlappende punten
dan wordt het antwoord dus 0,5 (want: 500.000 / 1000.000)
Maar verander je nu de grid naar 2000x2000 dan wordt het antwoord dus 500.000 / 4000.000 = 0,125
Pas na het drukken op Calculate zal het aantal overlappende punten ook aangepast worden naar ca. 2000.000
waardoor het antwoord weer op 2000.000 / 4000.000 = 0,5 komt

edit:
Klein gokje dat het maximum aantal punten binnen de grid is bereikt.

Whehe, 16777216 is de max dus. Aka een 3 bytes getal (3 byte = 24 bit = 2^24 = 16777216 )
Ga ik gelijk ff fixxen

edit2:
Werkt nu met een Double, aka 8 byte --> 64 bits --> 40 bits meer = grid kan 1 048 576 maal zo groot worden

[ Voor 17% gewijzigd door SmiGueL op 23-01-2011 19:19 ]

[Kid Jansen]

offtopic:
Ik ga ze allebei bekijken, hoewel ik niet kan beloven dat ik dat vanavond nog doe, want ik ben behoorlijk brak van rugby

[Kid Jansen]

Hij werkt nu wel goed met een grid>10000, maar het lijkt er op dat de fout die je krijgt door de afrondingen (doordat het een numerieke in plaats van algebraïsche methode is) niet kleiner worden daarvan.

Met 10k grid had ik bijvoorbeeld bij het DreamColor 2 paneel voor de 8540w 100.0112% Adobe RGB, en met 30k grid kom ik op 100.0645%. Lijkt me niet helemaal logisch, je zou verwachten dat hoe hoger het getal bij grid, hoe nauwkeuriger het resultaat, maar dat blijkt dus niet zo te zijn.

Overigens heb ik ook de sheet van Darkstone bekeken, die lijkt me toch beter. Die is niet alleen nauwkeuriger, maar ook nog eens veel sneller, het resultaat staat er meteen en zo nauwkeurig als je het kan krijgen.

Enige nadeel is dat die van Darkstone alleen % sRGB en % Adobe RGB kan geven, twee panelen met elkaar vergelijken kan dus niet. Ze zijn dus allebei nuttig, geen verspilde moeite.


Nu dit topic er toch is, kan ik hier nog wel drie dingen vragen:

Het CIE 1931 xy chromacity diagram ontstaat uit de drie zogenaamde color matching functions, maar ik snap niet echt hoe. De numerieke waarde van de color matching functions zijn gegeven van 300 nm t/m 780 nm in stappen van 5 nm en te vinden in deze excelsheet (tabblad "1931 col observer"). Snappen jullie wel hoe die rare hoefijzervorm uit die drie functies ontstaat?

Dan de vraag, als je dat eenmaal hebt, hoe bereken je dan de oppervlakte (in die x,y schaal) van dat CIE 1931 xy chromacity diagram?

En dan nog een laatste vraag, hoe bereken je met welke coördinaten in dat diagram je de hoogste dekking haalt? Met drie subpixels per pixel krijg je een driehoek in dat diagram en voor die situatie heb ik al een keer met http://www.ledtuning.nl/cie.php bepaald dat je maximaal zo'n 72.8% van de xyY kleurruimte (komt overeen met de kleuren die een gemiddeld mens kan zien) kan dekken door monochroom licht te gebruiken met golflengtes van 433, 518 en 700 nm. Ik zou dus graag willen weten hoe je dat netjes uitrekent, liefst ook voor 4, 5 en 6 subpixels per pixel.

[Anoniem: 303530]

kid jansen schreef op maandag 24 januari 2011 @ 14:19:
Enige nadeel is dat die van Darkstone alleen % sRGB en % Adobe RGB kan geven, twee panelen met elkaar vergelijken kan dus niet. Ze zijn dus allebei nuttig, geen verspilde moeite.

Dat kan wel hoor, dan kopieer je de hele sheet over en verander je daarin de 6 coördinaten die links van (xRGB) staan, vervolgens bereken je de area daarvan en deel je daarmee.

Ik kan het aanpassen als je wilt.

[Kid Jansen]

Ja doe maar, wel zo handig, kan alles in één ding. Maar doe het maar wel als extra optie erbij, niet dat je ook iedere keer de coördinaten van Adobe RGB of sRGB in moet vullen als je daar mee wilt vergelijken.

[Kid Jansen]

SmiGueL schreef op zondag 23 januari 2011 @ 00:11:
...Mocht je echt honderden monitoren willen testen, dan stel ik voor:

Zet de X & Y coordinaten even in een lijstje onder elkaar:

code:

X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 Y5 X6 Y6
X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 Y5 X6 Y6
X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 Y5 X6 Y6
X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 Y5 X6 Y6
X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 Y5 X6 Y6

(Dit zijn dus 5 schermen, tot xxxx mogelijk dus )

Dan pruts ik wel ff een auto-import en export script in elkaar,
die na een nacht rekenen gewoon de resultaten voor alle honden schermen in 1x eruit knalt

Ben je al aan dat auto-import script begonnen?

[SmiGueL]

kid jansen schreef op dinsdag 25 januari 2011 @ 14:30:
Ben je al aan dat auto-import script begonnen?

Nope, Ik zit momenteel niet op mijn eigen PC (geen Office met VBA er op)

Maar als jij het liever op de exacte manier doet, (aka: de sheet van Darkstone)
dan kan ik die ook eventueel wel aanpassen dit weekend.

Kom er alleen niet zo snel achter welke waarden je nodig hebt.
(Die 0,11115 uit zijn sheet lijkt me duidelijk , maargoed wat geeft dat aan?
Ik heb in mijn sheet als uitkomst de overlap binnen de rode driehoek, en de overlap binnen de blauwe driehoek.) Dat was ook de vraag d8 ik

Wat/welke geeft die 0,11115 aan?

En, hoe staan deze getallen in verhouding tot:
- % NTSC color gamut
- % Adobe RGB color gamut
- % sRGB color gamut

Ik heb helaas niet zoveel verstand van monitoren (en momenteel weinig tijd om me hier in te verdiepen/alles uit te pluizen)
Nee ondanks dat ik ook in Enschede woon, aan de zelfde school studeer, ook Mechanical Engineering doe, en ook over een paar maand even oud wordt, heb ik dit nooit gehad tijdens de colleges

Als Darkstone hem nou ff aan kan passen zodat de input, en de output duidelijk in de sheet staat, dan bak ik dit weekend wel ff iets in elkaar zodat de berekening van 1000 monitoren in een klik en een zucht gedaan zijn

Kun jij anders ff een (.xls) lijstje (met de 6 punten van 10, 100 of 1000 monitoren) doorsturen?
Met dat ene stukje tabel in de post hierboven kan ik vrij weinig

kid jansen schreef op maandag 24 januari 2011 @ 14:19:
Met 10k grid had ik bijvoorbeeld bij het DreamColor 2 paneel voor de 8540w 100.0112% Adobe RGB, en met 30k grid kom ik op 100.0645%. Lijkt me niet helemaal logisch, je zou verwachten dat hoe hoger het getal bij grid, hoe nauwkeuriger het resultaat, maar dat blijkt dus niet zo te zijn.

Dit vond ik inderdaad ook redelijk frappant, waardoor ik het ff heb uitgezocht.
Het blijkt dat de berekende waarde geleidelijk dichter naar 1 loopt (de exacte waarde), maar met de afwijking van een steeds kleiner wordende sinusvorm (zie hieronder voor de duidelijkheid)
Horizontaal de Gridsize, en Verticaal de bijbehordende berekende waarde.


(klikbaar)

[Anoniem: 303530]

Die 0,11205 (ik ga ervanuit dat je dat bedoelt) is het oppervlak van het sRGB spectrum welke ik al eerder had uitgerekend als je dat deelt door de oppervlak van wat je hebt berekend weet je de dekking.

Maar ik ka hem wel aanpassen, sterker nog: dat had ik al gedaan: http://dl.dropbox.com/u/18772348/Gamut%20berekenaar.xls spreekt voor zich denk ik.

[Kid Jansen]

Ik zit nu op m'n werk, ik zal vanavond even die Excel van me aanpassen zodat jij er wat aan hebt.

SmiGueL schreef op dinsdag 25 januari 2011 @ 18:56:
Nee ondanks dat ik ook in Enschede woon, aan de zelfde school studeer, ook Mechanical Engineering doe, en ook over een paar maand even oud wordt, heb ik dit nooit gehad tijdens de colleges

offtopic:
die kennis komt inderdaad niet van WB, overigens ben jij degene die ouder is, ik word 22 april 23, jij al 14 maart.

[Kid Jansen]

Bij deze dan

Het zijn 69 desktop panelen en 58 laptoppanelen, daarmee moet je een redelijk eind komen lijkt me.

• Kolom A spreekt voor zich
• B t/m G zijn de kleurcoördinaten in dat gekleurde vlak
• I is het oppervlak van de driehoek die wordt gevormd door de extremen van rood, groen en blauw
• J is het percentage van het gehele gekleurde vlak wat dat paneel weer kan geven
• K is de relatieve grootte van het kleurbereik van een paneel uitgedrukt in % NTSC 1953
• L moet berekend worden, daar moet het % Adobe RGB dekking komen
• M moet ook berekend worden, daar moet het % sRGB dekking komen

[ Voor 7% gewijzigd door Kid Jansen op 09-02-2011 11:30 ]

[Anoniem: 294759]

Holy mother of god.. Ik wist niet dat je dit kon doen met Excel.

[ Voor 4% gewijzigd door Anoniem: 294759 op 27-01-2011 18:55 ]

[Kid Jansen]

Ik ook niet toen ik het aan Darkstone vroeg en Darkstone ook niet toen hij het vervolgens hier vroeg

[SmiGueL]

Fixxed!

1. Open je eigen file.
2. Open mijn Excel file.
3. Zorg dat ze beide gewoon open staan, en druk op de "Calculate" knop.
4. Wacht enkele seconden, en zie dat hierna in jou "coordinaten panelen.xlsx" alle velden zijn ingevuld

Het mooie is dat na de toevoeging van een panel in je eigen .xlsx, er alleen 1x op de "Calculate" knop gedrukt hoeft te worden om het bestand bij te werken

[Kid Jansen]

WOW! Dat is echt awesome, dat duurde misschien 5 seconde voor 127 panelen en dan ook nog eens 100% exact. Zo kunnen we het voor alle 1400 panelen in ongeveer een minuut uitrekenen.

Dat zet me eigenlijk aan het denken, is het ook niet mogelijk om die PDF's op de één of andere manier automatisch uit te lezen? Alle voor ons interessante informatie staat vaak verspreid over 2 of 3 pagina's in de datasheet. Die pagina's zijn per fabrikant verschillend, maar voor dezelfde fabrikant zien ze er altijd (vrijwel exact) hetzelfde uit, ze zitten alleen niet altijd op hetzelfde paginanummer, wel altijd zelfde hoofdstuk en paragraaf.

[ Voor 20% gewijzigd door Kid Jansen op 09-02-2011 11:31 ]

[Anoniem: 303530]

Kan je ze niet naar plan text conversen met een of andere tool, en vervolgens het 2e getal achter "Bx"enz. uitlezen?

Ik zal het wel even proberen.

[Bolukan]

Wiskundig:
Het snijpunt van lijn A-B met K-L formuleer je door:
X=Kx+((By-Ay)*(Kx-Ax)-(Bx-Ax)*(Ky-Ay))/((Ly-Ky)*(Bx-Ax)-(Lx-Kx)*(By-Ay))*(Lx-Kx)
Y=Ky+((By-Ay)*(Kx-Ax)-(Bx-Ax)*(Ky-Ay))/((Ly-Ky)*(Bx-Ax)-(Lx-Kx)*(By-Ay))*(Ly-Ky)

Daarbij zijn er geen of oneindig aantal oplossingen als ((Ly-Ky)*(Bx-Ax)-(Lx-Kx)*(By-Ay)) = 0.
NB: Als ((By-Ay)*(Kx-Ax)-(Bx-Ax)*(Ky-Ay)) = 0 dan zijn er oneindig aantal oplossingen en anders geen.

((By-Ay)*(Kx-Ax)-(Bx-Ax)*(Ky-Ay))/((Ly-Ky)*(Bx-Ax)-(Lx-Kx)*(By-Ay)) moet tussen 0 en 1 liggen anders ligt het snijpunt in het verlengde van lijn K-L.
((Ly-Ky)*(Ax-Kx)-(Lx-Kx)*(Ay-Ky))/((By-Ay)*(Lx-Kx)-(Bx-Ax)*(Ly-Ky)) moet tussen 0 en 1 liggen anders ligt het snijpunt in het verlengde van lijn A-B.

Dit wilde ik jullie niet onthouden

[Big Womly]

1) Snijpunten van de 2 driehoeken bepalen
2) oppervlaktes van de driehoeken bepalen met 2 hoekpunten als snijpunten en de 3e hoek (0, 0)
3) door optellen/aftrekken van die oppervlaktes heb je de oppervlakte van je gele figuur

[Anoniem: 303530]

Dudes, het probleem is al opgelost

[Kid Jansen]

Misschien even de startpost (en topictitel?) aanpassen, zijn nog wel een aantal dingen die open staan:

Kid Jansen in "\[Wiskunde/excel] area van overlappende d..."

Kid Jansen in "\[Wiskunde/excel] area van overlappende d..."

[SmiGueL]

Nieuwe versie

Fixxes:
- Kolom I wordt ook exact berekend (huidige kolom wordt overschreven)
- Snelheidsimprovement --> kan nu 100 panelen/seconde verwerken, test met 1000 ging in 10 seconden

[Kid Jansen]

en K ook toch? (relatieve grootte in % NTSC)

EDIT: ja dus. Wat is trouwens het verschil tussen fast en fancy? Het is allebei toch exact? Op fast is hij trouwens echt rete snel, het stond er in echt een fractie van een seconde voor alle panelen (terwijl hij nu 4 kolommen moet berekenen in plaats van 2).

[ Voor 74% gewijzigd door Kid Jansen op 30-01-2011 11:52 ]

[SmiGueL]

Kolom K werd (zie DM ) hiervoor ook al berekend via de Calculate sheet.
(Jou ingevulde kolom K werd dus al overschreven )

Verschil tussen Fast en Fancy is dat de ene gwoon retesnel is (en ofc. exact)
en de ander er mooi fancy uitziet (net als de vorige versie)
Verschil zit hem in dat de sheet na elke berekening geupdate wordt, en je dus alle getalletjes ziet veranderen
Omdat jij zei:

Kid Jansen schreef op vrijdag 28 januari 2011 @ 11:45:
Zo kunnen we het voor alle 1400 panelen in ongeveer een minuut uitrekenen.

en dus de tijd een belangrijk issue vindt, heb ik ook ff een versie gemaakt die het in een oogwenk berekend

*omdat het kan*

[Kid Jansen]

Fast haalt alle coördinaten in één keer binnen en schrijft alle percentages in één keer weg bedoel je?

Het was me overigens nog niet opgevallen dat kolom K al berekend werd in de vorige versie.

Zoals ik op de vorige pagina al zei is het nu alleen nog zoeken naar een manier om alle informatie uit de datasheets geautomatiseerd uit te lezen (wat een heel stuk moeilijker is denk, aangezien de datasheets per fabrikant er anders uit zien).

[Anoniem: 303530]

Je kan ze naar txt converten, en vervolgens uitlezen met een tool...maar ik vermoed dat het even gaat duren voordat er 1500 pdf's zijn geconverteerd..

edit: nee, duurt kort, maar het uitlezen is niet echt gemakkelijk, bijvoorbeeld:

Item White Luminance ILED=20mA R L Viewing Angle H L Luminance Uniformity Luminance Uniformity Contrast Ratio Cross talk 5P 13P CR % Tr Response Time Tf TRT Red Rx Ry Color / Chromaticity Coodinates Green Gx Gy Bx Blue By Wx White NTSC Wy % CIE 1931 Rising Falling Rising + Falling 0.646 0.283 0.187 0.631 0.112 0.037 0.263 0.279 -6 2 8 0.676 0.313 0.217 0.661 0.142 0.067 0.313 0.329 95 Vertical (Upper) CR = 10 (Lower) 5 Points 13 Points Symbol Conditions 5 points average Horizontal CR = 10 (Right) (Left) Min. 230 60 60 45 50 300

Komt er uit gerold.. deze tool is erg snel: http://www.foolabs.com/xpdf/download.html

edit: toch wel, laat me even klooien

[ Voor 72% gewijzigd door Anoniem: 303530 op 30-01-2011 17:55 ]

[Kid Jansen]

via DM afgehandeld

[ Voor 116% gewijzigd door Kid Jansen op 09-02-2011 11:29 ]

[Kid Jansen]

Nieuw topic aangemaakt voor de vraag die ik hier had staan: Netto kleurdiepte berekenen

[ Voor 96% gewijzigd door Kid Jansen op 09-02-2011 11:49 ]

[Soultaker]

Even een meta-vraagje: wat is nu precies de relatie tussen Kid Jansen, SmiGuel en Darkstone? Zijn jullie collega's of iets dergelijks? Ik vraag me dit af omdat ik Kid Jansen eigenlijk niets anders zie doen dan vragen om features die SmiGuel vervolgens moet implementeren, maar voor scriptrequests is dit forum nadrukkelijk niet bedoeld. (Darkstone zie ik daarintegen wel zelf aan de slag gaan.)

Als jullie met z'n drieën aan een project werken is het misschien handiger de discussie gewoon per DM/e-mail voort te zetten en een nieuw topic te openen als je weer een specifieke vraag hebt waar de hele community input op kan geven (en waarbij de vraag dus expliciet niet is "wie implementeert dit even voor mij?").

[Anoniem: 303530]

Ik ken SmiGuel niet buiten dit topic, dit topic is gestart toen ik voor het bekende [Oproep] Screenies MonitorAssetManager voor panelDB laptops een manier zocht om de color gamut te berekenen, dat werkt nu, enkel hebben we nu 1500 datasheets die we moeten invullen. Dat moet makkelijker kunnen.

Echter is dat niet bijster on-topic en lukt dat ook wel zonder deskundige^(c) hulp, daarom houd is de duscussie daarover grotendeels buiten dit topic.

[Kid Jansen]

Ik heb zelf begin november een Excel calculator gemaakt die het relatieve kleurbereik in % NTSC kan berekenen. Dat was niet zo lastig, want je moet alleen de lengte van de zijden berekenen en daarna kan je de methode die wordt beschreven op deze site gebruiken om het oppervlak te berekenen.

Ik ben daarna (begin december ergens) ook zelf gaan kijken of ik een methode kon bedenken om de dekking van een bepaalde kleurruimte te berekenen, maar daar ben ik niet echt ver mee gekomen. Ik kon het wel voor elk individueel geval handmatig uitrekenen (wat heel lang duurde), maar ik kon geen algemene methode vinden die altijd werkte.

Toen heeft dat heel lang stil gelegen en vervolgens heb ik 21 januari in een DM conversatie aan Darkstone gevraagd of hij wist hoe dat moest. Dat wist hij niet op dat moment, maar hij dacht dat ze dat in dit subforum misschien wel zouden weten dus daarom heeft hij dit topic geopend.

[Kid Jansen]

De eerste resultaten zijn nu te zien op TFT Central, voor alle 22" t/m 30" panelen waar we de kleurcoördinaten van hebben staat nu de dekking van Adobe RGB en sRGB in de Monitor Panel Part Database.

Bij de kleinere panelen ga ik het deze week ook nog toevoegen, daarna is de Laptop Panel Part Database aan de beurt.

Aan iedereen die heeft meegeholpen en heeft meegedacht: heel erg bedankt!

[TheNephilim]

Soultaker schreef op woensdag 02 februari 2011 @ 17:19:
Even een meta-vraagje: wat is nu precies de relatie tussen Kid Jansen, SmiGuel en Darkstone? Zijn jullie collega's of iets dergelijks? Ik vraag me dit af omdat ik Kid Jansen eigenlijk niets anders zie doen dan vragen om features die SmiGuel vervolgens moet implementeren, maar voor scriptrequests is dit forum nadrukkelijk niet bedoeld. (Darkstone zie ik daarintegen wel zelf aan de slag gaan.)

Als jullie met z'n drieën aan een project werken is het misschien handiger de discussie gewoon per DM/e-mail voort te zetten en een nieuw topic te openen als je weer een specifieke vraag hebt waar de hele community input op kan geven (en waarbij de vraag dus expliciet niet is "wie implementeert dit even voor mij?").

Best intressant om te lezen anders! Als iemand een vraag stelt en vervolgens zelf geen input geeft is het (vind ik) een script-request. Als de TS gewoon hulp nodig heeft om het 1 en ander aan te vullen lijkt me dat geen probleem. Het is immers een forum voor tweakers en elkaar helpen moet geen probleem zijn.

[NMe]

Bernardo schreef op dinsdag 22 februari 2011 @ 10:02:
[...]

Best intressant om te lezen anders! Als iemand een vraag stelt en vervolgens zelf geen input geeft is het (vind ik) een script-request. Als de TS gewoon hulp nodig heeft om het 1 en ander aan te vullen lijkt me dat geen probleem. Het is immers een forum voor tweakers en elkaar helpen moet geen probleem zijn.

Helpen is prima, maar zoals Soultaker terecht opmerkt is het niet bepaald de bedoeling van dit forum dat anderen jouw werk voor je doen. Die illusie wordt hier wel enigszins gewekt natuurlijk omdat wij de onderlinge relatie tussen de drie posters niet kennen.