Inlägg

/*
 * CEA-861-F:
 * "When transmitting any RGB colorimetry, the Source should set the
 *  YQ-field to match the RGB Quantization Range being transmitted
 *  (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
 *  set YQ=1) and the Sink shall ignore the YQ-field."
 */

Jag såg den patchen innan. Det går inte att veta varför utan att läsa specen och dessutom antagligen ha tillgång till protokoll eller liknande från standardiseringsmötena (så att man ser bakgrunden till varför). En ren gissning från min sida är att det kan vara nån form av skadekontroll av något vanligt fel dom sett, typ att en massa TV apparater kollar på YQ biten istället för Q biten för RGB (vore inte första gången nåt sånt har hänt). Men det är som sagt ren spekulation.

Arghh, det suger att inte ha tillgång till nyare specar Snordyra är dom också! Hade dom kostat några hundra hade jag köpt senaste versionerna, men jag tänker inte lägga $350 på att köpa CEA specen och sen hosta upp ytterligare $5000 för få tillgång till HDMI specen bara för att stilla min nyfikenhet.

Dock har jag hittat en par dokument som jag faktiskt kan länka till: Compliance Testing, Functional Testing and Debugging of HDMI Interfaces Application Note (PDF)

Jag antar att det är ok att länka till dokumentet här på forumet eftersom länken går till Rohde & Schwarz websida. Detta är egentligen ett dokument som beskriver en Rohde & Schwarz produkt, men det finns några insikter om HDMI/CEA standarden att hämta i det.

Ett annat dokument är en presentation från ett föredrag som hölls av en kille på Cisco: Colorspaces and HDMI (PDF)

Jag antar även här att dokumentet är ok att länka till eftersom dokumentet finns att tillgå via anordnarens hemsida. Finns en del matnyttigt att plocka i detta dokument också.

Sen har jag faktiskt hittat att HDMI 1.3 specen numera är gratis. Man kan signa upp sig på http://www.hdmi.org/manufacturer/specification.aspx och sen kan man ladda hem den. Eller så går man till Wikipedia och tar den därifrån. Notera dock att man utöver HDMI specen behöver ha fatt i CEA-861-D.

Jag tror faktiskt inte Q biten ska ignoreras, iaf inte alltid. Kolla i app note:n från Rohde & Schwarz så ser du att det finns testfall för HDMI 1.4. Förvisso bara två testfall, men ändå Jag är lite osäker på om man kan lita på att det som som står i CEA specen gäller för HDMI. HDMI (iaf 1.3) hänvisar till CEA-861, men sen åsidosätter HDMI specen vissa delar (iaf tolkar jag det så).

Det finns säkert fall där source/sink inte kan läsa EDID respektive skicka infoframe, men då är det nog generalknas. En HDMI source ska enligt spec alltid läsa EDID. Vad jag förstår ska en HDMI sink tillhandahålla en EDID (annars tror jag att den blir behandlad som en DVI sink). Det är tom rekommenderat att EDID ska kunna läsas när sinken är avstängd. En source som inte skickar någon infoframe blir nog behandlad som en DVI source.

I teorin borde det se rätt ut utan att fippla med något, såtillvida att bilden borde ha rätt gråskala och vara utan färgstick. Däremot kan det ju bli lite mindre detaljrikt. Jag menar, ta exemplet att sinken inte stöder full-range för CE format. Det vet isf PC:n (drivare/grafikkort) och då ska den konvertera sin representation till den som kommer att användas.

Å andra sidan så har vi ju @Laxpudding's erfarenheter (och presentationen jag länkade till ovan) som helt klart visar på att det inte funkar i praktiken.

Standarden känns rätt rörig så det förvånar mig inte om det finns en massa hel- eller halvkassa implementationer. Sen är det i min erfarenhet så att standarder och obligatoriska finesser/beteenden i dem inte alltid fullt så obligatoriska som man kan tro. Tillverkare tenderar att behandla saker som testas i ev. typprov som obligatoriska, saker om inte testas i typprov får oftast, artigt uttryckt, "mindre kärlek".

Vill man få koll på vad som egentligen funkar i en spec så brukar det vara bra att börja med att kolla på testfallen i typprovsspecen. Finns det inget testfall för en finess eller ett beteende i typprovsspecen så kan man nog utgå från att det blir strul om man vill nyttja den finessen eller förlita sig på det beteendet.

Jag läste häromkvällen nåt om någon som hade moddat/flashat om EDID rommet i sin TV efter att ha upptäckt att hans HDTV identifierade sig som en gammal 15" CRT tjock-TV

Man måste ju inte ändra något, Limited range fungerar, men i vissa fall med en aning reducerad kvalitet. Om man prompt vill köra Full-range så kan man behöva ändra manuellt ja.

Ock jag håller med dig. Ställer man om datorn eller TV:n manuellt så att dom inte följer HDMI standarden så sitter felet troligtvis bakom tangentbordet och det ska man inte skylla på OS:et.

Visst EDID kommer inte att ändras, men om TV:n stöder Full-range i de videoformat som CEA-861 definierar så borde den också signalera det i EDID informationen (*). I de fallen torde man ju inte heller behöva manuellt ändra nåt på TV:n.

*) Det jag specifikt menar är QS biten i VCDB (CEA-861-D kap 7.5.6)

En bra poäng. Detta har jag faktiskt inte funderat på förut. Är du säker på att monitorer verkligen alltid använder RGB med omfånget 0..255? Jag menar, det är inte säkert att man faktiskt ser någon större skillnad mellan Limited range och Full range, så det kan ju tänkas att Limited range används när man använder CEA/EIA format utan att man märker av det.

Jag kollade lite i HDMI 1.3 specen och jag funderar på om monitorer kanske identifierar sig som DVI enheter (kap 8.3.3). Annars kan jag tänka mig att dom faktiskt nyttjar QS biten.

Du klagade på att jag hittade på egna termer och jag har försökt förklara för dig varför jag uttryckte mig som jag gjorde. Jag förstår din ståndpunkt och du har troligtvis förstått min, så tänker jag tänker inte lägga ner mer tid på att debattera detta.

Däremot fortsätter jag gärna en diskussionen om det tekniska

Jag hade inga problem med att tolka vad du skrev. Jag försökte vara tydlig och försökte uttrycka mig på ett sätt som jag trodde du och andra skulle förstå och samtidigt vara öppen för att jag kunde ha misstolkat vad du skrev. Detta eftersom jag anser att termen videonivåer är tvetydig. Det var inte min mening att väcka anstöt.

Det jag pratar om är Video Quantization Ranges och följer man t.ex. HDMI 1.3 specen så ska alltid Limited range användas för RGB när videoformatet är matchar något av de format som definieras av CEA-861-D (förutom för 640x480p). Hur detta har ändrats i senare versioner av HDMI vet jag inte då jag inte har tillgång till nyare specar.

CEA-861-D specificerar bl.a. en rad vanligt förekommande format som används i film och TV sammanhang. Terminologin där är för övrigt CE video format och IT video format, där det senare används för att benämna alla format som inte definieras i CEA-861-D.

Nu är jag på intet sätt någon expert, men i detta sammanhang uppfattar jag Limited range och Full range som olika videonivåer och mao uppfattar jag termen videonivåer i detta sammanhang som en synonym för Video Quantization Ranges.

Som jag förstått det är det inte TV:n som begär nåt från datorn, utan TV:n (som är en HDMI sink) kommunicerar vad den kan till datorn (som är en HDMI source) och sen är det datorn som väljer vad den vill använda (inom ramen för vad standarden tillåter). Vilken Video Quantization Range som används bestäms då antingen implicit av vilket video format som används, eller genom att datorn explicit signalerar detta (i den mån det är möjligt).

Om TVn har någon form av användarinställning som gör att man "tvingar" den att tolka RGB enligt Full range så blir det troligtvis fel om man använder den och det kan man ju, precis som du säger, inte skylla på operativsystemet.

Däremot bör ju operativsystemet/drivrutinen välja bästa möjliga video format och Video Quantization Range utifrån vad TV:n kan och då ska det, givet att TV:n inte är tvingad till Full range, se rätt ut både för video och skrivbord.

Ser det inte rätt ut så är nånting definitivt fel. Felet behöver inte ligga i datorn, men om det ser rätt ut för videoklipp som spelas upp i ett fönster på skrivbordet men fel ut för skrivbordet i övrigt så tycker jag nog att det lutar åt att felet ligger på datorsidan. Spelar man upp video i fullskärm där ett annat video format används än det som används när skrivbordet visas kan ju felet lika gärna vara på TV-sidan.

@Petterk: Det är helt enkelt svårt att veta exakt vad du menar eftersom som videonivåer är ett begrepp som används av olika personer i olika sammanhang och dessutom med helt olika kunskap och referensram. Detta gör att det är lätt att prata om varandra och jag försökte helt enkelt vara tydlig med hur jag tolkade dig och vad jag menade.

Nu har jag ju ingen Moto G4, så jag kan ju inte säga hur bra fingeravtrycksläsaren funkar på den, men min Xperia X Compact har fingeravtrycksläsare och det funkar hur bra som helst! Träna in den på de fingrar du normalt använder och sen är det bara att trycka på power-knappen så kommer man direkt till home-screen (eller där man nu var när skärmen släktes).

Jag håller tummarna för att du har rätt, jag hoppas verkligen att det ska bli medvind för AMD ett tag nu. Det ska hursomhaver bli intressant att se hur det hela utspelar sig.

Ska jag vara helt ärlig så låter det där faktisk som ett fel, oavsett om det sker under Linux, Windows eller bådadera. Jag menar, applikationer gör någon form av grafisk presentation och där är det troligen RGB som gäller, sen finns det en framebuffer där bilden är representerad på ett sätt. Denna representation ska sen översättas till en annan representation och skickas över HDMI av grafikkortet och dess drivare. Om signaleringen mellan TV och grafikkort fungerat så vet alla inblandade komponenter vad som gäller och det ska inte behövas något manuellt pillande överhuvudtaget för att detta ska fungera. Om det behövs är det fan fel nånstans.

Om det är problematiskt i både Windows och Linux så är bådadera lika "trasiga" i mina ögon. Att man sen kan kompensera för felet genom en inställning är livet lite enklare och jag kan inte se att det ska göra nån skillnad om man gör det i ett UI eller från kommandorad. Fast ännu bättre vore det om man lagade felet istället

En sak jag inte blir riktigt klok på dock, lite förenklat beskrivet såhär; om grafikkortet/drivisen och TVn förhandlat om limited range, som jag tror är det du menar när du skriver videonivåer (jag är lite osäker om det, för mig är både limited och full range videonivåer) och sen skrivbordet är full-range så borde det resultera i överdriven kontrast och inte grådassig bild. Om man får en grådassig bild i det fall som TS beskriver så verkar det intuitivt som det omvända, dvs att skrivbordet är i limited range och videolänken är satt till full-range.

Jadå, där är vi i eniga Dock kan äldre saker vara kluriga att få igång på senaste Windows och i vissa fall är det lättare att hålla igång äldre hårdvara på Linux, men för gemene man så är det helt klart mycket lättare att köpa prylar och få dom att funka med Windows. Ska man köra Linux så måste man göra en hel del efterforskningar och se till att man köper hårdvara som man vet stöds, på Windows kan man köpa nästan vad som helst och det funkar.

Apple har jag, som kanske framgått ringa, erfarenhet av, men på PC sidan så är väl i princip nästan alla laptoptillverkare lika illa. Man får en uppsättning drivrutiner och har man tur så får man en uppsättning till nästa version av Windows. Uppdateringar på drivrutiner är sällsynta. Tillverkarna vill nog helt enkelt hellre att man köper en ny laptop.

Det tror jag säkert och jag kommer få möjlighet att testa tämligen snart tror jag eftersom det är dags för en ny laptop. Om jag sen väljer att köra det eller Linux då återstår att se.

Det är nog lite off-topic i denna tråden, men eftersom du frågar så försöker jag svara lite kort.

Windows 10 upplever jag som att det strular väldigt mycket och har ett UI:t som känns halvfärdigt. En del av strulet tror jag beror på Microsofts taktik att nästa tvinga på Windows 10 till folk med äldre maskiner (typ 3+ år gamla) där tillverkarna inte har drivrutiner till Windows 10. En annan bidragande orsak till strul tror jag är Windows påtvingade uppgraderingar som är långt ifrån felfria.

För mig innebär det ett konstant pyssel av familjemedlemmars datorer som till synes hittar på saker och slutar funka som dom ska och jag har flera problem med min egen laptop som jag helt enkelt inte får rätt på (som f.ö. är den enda av familjens datorer som är uppgraderad och inte rent installerad). Visst jag kan säkert ta tiden och installera om den, men om jag ändå ska göra allt det jobbet så överväger jag skarpt att köra Linux istället (det enda som jag saknar där är BankId). Om sen Photoshop gick att få igång under Linux hade jag kunna konvertera både sambons och min mors maskiner också.

Sen lär väl Intel vara vid rätt stadd kassa vid det här laget och krigskassan torde vara välfylld så dom har nog råd med ett priskrig, vilket jag misstänker att AMD inte har. Det ska bli spännande att se Intels motdrag!

I övrigt så hoppas jag på framgångar för AMD nu så att vi vanliga dödliga får ett bra urval av processorer till vettiga priser.

Anledningen till att jag skapade tråden var för att höra om någon hade erfarenhet av eller tips på sensorer. Det verkar som att det åtminstone är någon fler än jag som är intresserad av detta så jag tänkte att jag kan dela med mig av det jag läst.

So here goes nothing (med brasklapp om att nedanstående är min bristfälla kunskap om ämnet):

Det finns olika sätt att mäta fuktighet i jord. Dom enkla sensorerna, som den jag länkade till, mäter jordens resistivitet. Resistiviteten varierar bl.a. beroende på mängden fukt i jorden. Mao är det i princip bara en spänning mellan två metallbitar i jorden. Nackdelen med denna metod är att den enbart fungerar pga "föroreningar" i jorden (rent vatten leder som bekant inte ström).

En annan nackdel med metoden är att det blir galvanisk korrosion och metallen vandrar i jorden mellan pinnarna, vilket leder till att sensorerna "slits ut" och "förorenar" jorden, vilket i sin tur påverkar mätvärdena. Det finns en förbättring på detta där man alternerar polerna för att minska problemet.

En annan metod jag läst om är att man mäter jordens kapacitans. Man sticker då typiskt ner ett kretskort i jorden som är så finurligt utformat att den kringliggande jorden används som dielektrikum och då bildar en kondensator. Metallen i sensorn kan då isoleras från fysisk kontakt med jorden. Fukthalten påverkar sen kondensatorns kapacitans. Se PCB as a Capacitive Soil Moisture Sensor.

Vid kapacitiv mätning så verkar det finnas olika sätt att nyttja "kondensatorn". Det enklaste sättet är ju att mäta tiden det tar att ladda upp eller ur den med en känd ström eller last. Nackdelen är att jorden sammansättning också påverkar kapacitansen.

Ett annat sätt är att låta kapacitansen vara en del i en oscillatorkrets som man sen kan mäta frekvensen på för att få ut ett mått på jordens fuktighet. Se Capacitive Liquid Level Sensor.

Ett tredje sätt är att använda kapacitansen som ett filter och sen köra en RF signal genom filtret och mäta hur signalen dämpas (det är iaf så jag uppfatta att det funkar). Väljer man rätt frekvens (ca 100 MHz) så blir tydligen jordens fukthalt en mer prominent del av kapacitansen och får då ett mätvärde som mer beror på fukthalten än jordens sammansättning. Se RF Probe (PDF).

Ja det funkar ju, eller så trycker man ner två stänger av någon annan metall med lagom mellanrum , typ två spikar eller nåt, och mäter mellan dom.

Tack för länken!

Den länkade vidare till Dickson-sajten och där fanns en stor brasklapp som jag faktiskt inte funderat över; billiga prober som den nedan kan innehålla bly och är därmed inte lämpliga om man odlar mat!

http://dicksonchow.com/projects/plant-friends-mkii/soilprobe.jpg