[pw] Bug, beeldverhouding mist soms

[Wolfboy]

pricewatch: Apple Pro Display XDR (Standaardglas) Zilver

Volgens mij is het makkelijk genoeg om dit structureel op te lossen. Iets als dit moet het wel doen:

code:

width = 6016
height = 3384
divider = gcd(width, height)  # 376
ratio_width = width / divider  # 6016 / 376 = 16
ratio_height = height / divider # 3384 / 376 = 9

[ACM]

Dergelijke data kunnen de collega's van de Pricewatch invullen en komt veelal ook van een externe partner automatisch erbij.

We hebben wel mogelijkheden om e.e.a. te automatiseren, maar daar zitten wel wat haken en ogen aan.

gcd is neem ik aan 'greatest common denominator'? Dat is zo natuurlijk wel makkelijk pseudo-coden, de moeilijkste functie wegstoppen in de hoop dat de library dat al biedt Maar zo normaal is het niet dat die functie in een standaardbibliotheek zit, niet dat 'm niet zouden kunnen implementeren. Dus in dit geval kan het niet gelijk opgezet worden zonder tussenkomst van onze ontwikkelaars

Maar dat gezegd hebbende, het zit er dik in dat er hier en daar schermen zijn waarbij de verhouding niet perfect uit te rekenen valt met de opgegeven specificaties omdat dat bijvoorbeeld net een pixelrij te weinig is. Dat zou dan een GCD van 1 kunnen opleveren... terwijl het bijvoorbeeld wel bijna 16:9 is en dan ook als zodanig wordt opgegeven door de fabrikant.

Kortom, het zou geautomatiseerd kunnen worden, maar dat is het nu niet en daar moeten de Pricewatch-collega's zich over beraden.

Verplaatst van Stoute Bugs naar Pricewatch

[ Voor 3% gewijzigd door ACM op 19-12-2019 16:39 ]

[Wolfboy]

ACM schreef op donderdag 19 december 2019 @ 16:39:
Dergelijke data kunnen de collega's van de Pricewatch invullen en komt veelal ook van een externe partner automatisch erbij.

Hij viel niet bij de specificaties aan te passen waardoor ik dacht dat het sowieso automatisch berekend werd.

gcd is neem ik aan 'greatest common denominator'? Dat is zo natuurlijk wel makkelijk pseudo-coden, de moeilijkste functie wegstoppen in de hoop dat de library dat al biedt Maar zo normaal is het niet dat die functie in een standaardbibliotheek zit, niet dat 'm niet zouden kunnen implementeren. Dus in dit geval kan het niet gelijk opgezet worden zonder tussenkomst van onze ontwikkelaars

Bijna perfect! Het is greatest common divisor aangezien het zowel de denominator als de nominator kan zijn eigenlijk

Die functie is in veel programmeertalen overigens gewoon ingebouwd:
- Python: https://docs.python.org/3/library/math.html#math.gcd
- C#: https://docs.microsoft.co...ger.greatestcommondivisor
- PHP: https://www.php.net/manual/en/function.gmp-gcd.php (met de GMP module)
- Java: https://docs.oracle.com/j...gcd(java.math.BigInteger)

Al is het anders ook met een paar regels zelf te implementeren:

code:

function gcd(a, b)
    while b ≠ 0
       t := b; 
       b := a mod b; 
       a := t; 
    return a;

Bron: Wikipedia: Euclidean algorithm

Maar dat gezegd hebbende, het zit er dik in dat er hier en daar schermen zijn waarbij de verhouding niet perfect uit te rekenen valt met de opgegeven specificaties omdat dat bijvoorbeeld net een pixelrij te weinig is. Dat zou dan een GCD van 1 kunnen opleveren... terwijl het bijvoorbeeld wel bijna 16:9 is en dan ook als zodanig wordt opgegeven door de fabrikant.

Goed, niet perfect. Maar het is een betere fallback dan "overig" naar mijn mening
En je kan voor de zekerheid natuurlijk gewoon een controle doen of de GCD groter is dan 10 ofzo

Kortom, het zou geautomatiseerd kunnen worden, maar dat is het nu niet en daar moeten de Pricewatch-collega's zich over beraden.

We zijn IT'ers toch, alles hoort automatisch te gaan bij ons

[ Voor 3% gewijzigd door Wolfboy op 19-12-2019 17:42 ]

[ACM]

Wolfboy schreef op donderdag 19 december 2019 @ 17:41:
Hij viel niet bij de specificaties aan te passen waardoor ik dacht dat het sowieso automatisch berekend werd.

Ah, hij wordt inderdaad afgeleid. Maar op een wat minder elegante manier; simpelweg een selectielijstje op basis van de id's van de resolutie-spec Als er een nieuwe specificatie bij komt zal die inderdaad gelijk missen.

Maar die toevoegen is ook iets dat de Pricewatch-collega's moeten doen. En als ze toch a.d.h.v. jouw reactie e.e.a. 'eleganter' op willen zetten, dan zal ik of een collega nog wat extra's voor ze mogelijk moeten maken

- PHP: https://www.php.net/manual/en/function.gmp-gcd.php (met de GMP module)

Hmm, blijkbaar niet goed genoeg gezocht
Maar zoals al beaamd, het is uiteraard wel toe te voegen aan onze eigen bibliotheek als de Pricewatch-collega's het willen gaan gebruiken.

Goed, niet perfect. Maar het is een betere fallback dan "overig" naar mijn mening
En je kan voor de zekerheid natuurlijk gewoon een controle doen of de GCD groter is dan 10 ofzo

Het zou inderdaad na het selectielijstje gedaan kunnen als "fallback". En daarna kan natuurlijk dat selectielijstje flink worden ingekort tot enkel de uitzonderingen die anders mis zouden gaan.

Er zijn ook nog voorbeelden die op zich 'mooi' uitkomen, zoals de 8:5 (=16:10) ratio, maar die dan toch fout zijn. Welkom in de wereld van gemixte standaarden en marketingkeuzes

[ Voor 6% gewijzigd door ACM op 20-12-2019 08:34 ]

[Glaanie]

@Wolfboy, zoals @ACM hierboven ook aangeeft, is het in de backend simpelweg een lijstje die zegt welke resolutie bij welke beeldverhouding hoort. In dit geval ontbreekt ook de resolutie van de XDR display, ik zal deze straks nog toevoegen, en ook anderen uit het lijstje 'overig' nog nalopen.

De reden waarom daarvoor gekozen is, is ook min of meer al uitgelegd door mijn collega, namelijk dat we simpelweg niet de juiste functie hebben om op deze manier te rekenen. Zelfs al zouden we dat hebben, zou ik dat denk ik nog niet gebruiken om alle uitzonderingen die er bestaan af te vangen. Ik ben bijvoorbeeld tegengekomen van iets wat een 43:18 verhouding had, het meest lijkt dat dan op 21:9, maar is het ook net niet (21,5:9 dus eigenlijk). Dan is een simpel lijstje in de backend beter te onderhouden, we zullen er dan beter op moeten letten om bij het toevoegen van een nieuwe resolutie ook de beeldverhouding toe te voegen. Zo vaak gebeurt het niet dat een nieuwe resolutie 'verzonnen' wordt, zeker niet bij monitoren.

[Wolfboy]

ACM schreef op vrijdag 20 december 2019 @ 08:29:
Er zijn ook nog voorbeelden die op zich 'mooi' uitkomen, zoals de 8:5 (=16:10) ratio, maar die dan toch fout zijn. Welkom in de wereld van gemixte standaarden en marketingkeuzes

Ja... standaarden enzo, schiet niet op Maar als fallback een leuke optie

Glaanie schreef op vrijdag 20 december 2019 @ 10:04:
De reden waarom daarvoor gekozen is, is ook min of meer al uitgelegd door mijn collega, namelijk dat we simpelweg niet de juiste functie hebben om op deze manier te rekenen. Zelfs al zouden we dat hebben, zou ik dat denk ik nog niet gebruiken om alle uitzonderingen die er bestaan af te vangen. Ik ben bijvoorbeeld tegengekomen van iets wat een 43:18 verhouding had, het meest lijkt dat dan op 21:9, maar is het ook net niet (21,5:9 dus eigenlijk). Dan is een simpel lijstje in de backend beter te onderhouden, we zullen er dan beter op moeten letten om bij het toevoegen van een nieuwe resolutie ook de beeldverhouding toe te voegen. Zo vaak gebeurt het niet dat een nieuwe resolutie 'verzonnen' wordt, zeker niet bij monitoren.

Helemaal begrijpelijk
Vooral bij monitoren zullen nieuwe resoluties ook niet heel vaak langskomen. Bij telefoons of tablets zou het heel wat vaker gebeuren, maar die hebben zo te zien gelukkig geen beeldverhouding