roze plaatjes ?

[vso]

waarom zie ik roze plaatjes met als redirection url "ic.tweakimg.net/camo" met ID ???

Met url over zie ik wel een link naar het orginele plaatje .. maar niet klikbaar//

ik gebruik chrome

iets over het hoofd gezien oid ?? niet alle plaatjes geven dit effect.

[Room42]

Adblock. Ik heb dat ook met Twitter-plaatjes (pbs.twimg.com). Wat je kunt doen is de post quoten en dan uit de quote de URL slepen naar een nieuwe tab.

[ Voor 121% gewijzigd door Room42 op 01-12-2016 00:40 ]

[DennusB]

Waar zie je dat dan?

[Hero of Time]

Roze wil zeggen dat de lazy image loader ze niet kan laden voor je. Er is ruimte gereserveerd in posts en normaal gesproken is de achtergrond wit als je naar zo'n post scrollt, maar is het plaatje stuk (onbereikbaar), dan wordt 'ie roze. Dit is overigens volledig client side. Zie je iets van een camo ID, dan wil dat zeggen dat het plaatje via de Camo proxy wordt geladen omdat de host geen https aanbied en op deze manier worden meldingen over mixed content voorkomen.

Kan je op z'n minst een voorbeeld geven van een post of topic waar je hier last van hebt?

[Hippocampus]

Hier met firefox en adblock op disabled krijg ik ook regelmatig rose vlakken in beeld. na een f5 komen sommige plaatjes wel goed en sommigen niet (rose vlak)

[vso]

Hero of Time schreef op donderdag 1 december 2016 @ 00:41:
Kan je op z'n minst een voorbeeld geven van een post of topic waar je hier last van hebt?

spaceboy in "Slimme meter uitlezen via P1-poort"

Deze om erg specifiek te zijn., beide plaatsjes zijn roze.


zoals iedereen altijd zegt ik heb recent niks gewijzigd (niet dat ik weet) en ik block wel ads maar niet voor Got

overgens merk ik dit alleen bij GOT op en niet bij andere websites ..

[ Voor 26% gewijzigd door vso op 02-12-2016 20:11 ]

[crisp]

vso schreef op vrijdag 2 december 2016 @ 20:08:
[...]


spaceboy in "Slimme meter uitlezen via P1-poort"

Deze om erg specifiek te zijn., beide plaatsjes zijn roze.


zoals iedereen altijd zegt ik heb recent niks gewijzigd (niet dat ik weet) en ik block wel ads maar niet voor Got

overgens merk ik dit alleen bij GOT op en niet bij andere websites ..

Als een plaatje niet meer bestaat dan maakt de lazyloader er een rozerode placeholder van zodat in ieder geval de layout niet verspringt. Zonder lazyloading had je het browser-eigen 'broken image' icoontje gezien. Wellicht moeten we de placeholder nog wat aanpassen zodat duidelijker is dat het om een kapot plaatje gaat.

[vso]

crisp schreef op vrijdag 2 december 2016 @ 20:29:
[...]

Als een plaatje niet meer bestaat dan maakt de lazyloader er een rozerode placeholder van zodat in ieder geval de layout niet verspringt. Zonder lazyloading had je het browser-eigen 'broken image' icoontje gezien. Wellicht moeten we de placeholder nog wat aanpassen zodat duidelijker is dat het om een kapot plaatje gaat.

dat zou wel prettig zijn ja maar als dat het antwoord is dan ben ik weer blij

[Raven]

crisp schreef op vrijdag 2 december 2016 @ 20:29:
Wellicht moeten we de placeholder nog wat aanpassen zodat duidelijker is dat het om een kapot plaatje gaat.

Plaats er een plaatje van Henk voor in de plaats met gebroken glas effect achtig iets erin verwerkt?

[grote_oever]

Room42 schreef op donderdag 1 december 2016 @ 00:38:
Adblock. Ik heb dat ook met Twitter-plaatjes (pbs.twimg.com). Wat je kunt doen is de post quoten en dan uit de quote de URL slepen naar een nieuwe tab.

Heeft niet zo zeer met adblocker te maken. Wel het blokken van iets. Op mijn werk blokken ze imgur en overal waar de plaatsjes terug moeten komen staat bij mij een roze vlak ter grote van de orginele afbeelding. Valt me pas sinds de laatste paar dagen op. Paar weken geleden had ik dit nog niet.

[Hippocampus]

Zojuist kom ik dit tegen:



Een rose blok waar een plaatje moet staan.

Als ik dan vervolgens klik op view image dan gebeurt er dit:



Een groot leeg vlak.

Als ik dan terug ga (of f5) dan komt er nog steeds geen plaatje, maar wel de url:



En normaal gesproken kan ik die dan altijd wel zien als ik op view image klik, maar in dit geval gebeurt er dit:



Hopelijk heeft iemand hier iets aan

[crisp]

Hippocampus schreef op zaterdag 3 december 2016 @ 01:26:
Zojuist kom ik dit tegen:

[afbeelding]

Een rose blok waar een plaatje moet staan.

Als ik dan vervolgens klik op view image dan gebeurt er dit:

[afbeelding]

Een groot leeg vlak.

Als ik dan terug ga (of f5) dan komt er nog steeds geen plaatje, maar wel de url:

[afbeelding]

En normaal gesproken kan ik die dan altijd wel zien als ik op view image klik, maar in dit geval gebeurt er dit:

[afbeelding]

Hopelijk heeft iemand hier iets aan

Het lijkt me iig duidelijk dat dat plaatje niet werkt

[Hippocampus]

crisp schreef op zaterdag 3 december 2016 @ 09:34:
[...]

Het lijkt me iig duidelijk dat dat plaatje niet werkt

Dat is inderdaad duidelijk. Maar dat is in dit geval toeval en dat gaf ik ook aan.
Normaal gesproken kan ik na f5 de plaatjes vaak (niet altijd) alsnog bekijken door op de verschenen URL te klikken.

Voorbeeld:

[F1 2016] Race 21 - GP van Abu Dhabi het plaatje van zondag 27 november 2016 16:03 of een stukje verder het plaatje van zondag 27 november 2016 16:07

[crisp]

Hippocampus schreef op zaterdag 3 december 2016 @ 13:21:
[...]


Dat is inderdaad duidelijk. Maar dat is in dit geval toeval en dat gaf ik ook aan.
Normaal gesproken kan ik na f5 de plaatjes vaak (niet altijd) alsnog bekijken door op de verschenen URL te klikken.

Voorbeeld:

[F1 2016] Race 21 - GP van Abu Dhabi het plaatje van zondag 27 november 2016 16:03 of een stukje verder het plaatje van zondag 27 november 2016 16:07

Voor die gevallen moeten we inderdaad een oplossing verzinnen waarbij de url los op te vragen is. Ik had me niet gerealiseerd hoe vaak die situatie voorkomt. Ik gok dat het veelvuldig gebruik van minder stabiele netwerken (wifi, mobiel) hierin meespeelt.

[Hero of Time]

crisp schreef op zaterdag 3 december 2016 @ 14:44:
[...]

Voor die gevallen moeten we inderdaad een oplossing verzinnen waarbij de url los op te vragen is. Ik had me niet gerealiseerd hoe vaak die situatie voorkomt. Ik gok dat het veelvuldig gebruik van minder stabiele netwerken (wifi, mobiel) hierin meespeelt.

Ook de server heeft hier wat mee te maken. Had net in een post in 40d40n dat een aantal plaatjes rood/roze waren, terwijl de rest van diezelfde server wel gewoon geladen werden. Een refresh fixte dat dan weer.

Overigens wilde ik zo'n roze afbeelding in een nieuwe tab laten openen of de URL kopiëren en kreeg ik dit terug:

code:

data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20width='173'%20height='249'/%3E

Geen idee waar dat vandaan komt, maar het lijkt mij dat ik de SVG die gebruikt wordt kreeg, ipv de URL van het uiteindelijke plaatje zelf. Kan overigens heel goed komen door m'n browser zelf, Otter wordt namelijk niet veel gebruikt en bevat hier en daar nog een bug of wat.

[Hippocampus]

Hero of Time schreef op zondag 4 december 2016 @ 13:17:
[...]

Overigens wilde ik zo'n roze afbeelding in een nieuwe tab laten openen of de URL kopiëren en kreeg ik dit terug:

code:

data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20width='173'%20height='249'/%3E

Geen idee waar dat vandaan komt, maar het lijkt mij dat ik de SVG die gebruikt wordt kreeg, ipv de URL van het uiteindelijke plaatje zelf. Kan overigens heel goed komen door m'n browser zelf, Otter wordt namelijk niet veel gebruikt en bevat hier en daar nog een bug of wat.

In het tweede plaatje in mijn eerdere post hierboven staat er ook zoiets in de adresbalk, dus het is niet browser gerelateerd lijkt me.

[Verwijderd]

De laatste tijd heb ik inderdaad ook regelmatig roze plaatjes gezien Zo ook bij het eerder genoemde voorbeeld.

[crisp]

Die svg is de placeholder die we gebruiken om te zorgen dat de layout niet verspringt als een plaatje niet geladen kan worden. We zullen daar dus waarschijnlijk een meer uitgebreide oplossing voor moeten verzinnen waar bij we de img-url ook beschikbaar maken.

[crisp]

Verwijderd schreef op zondag 4 december 2016 @ 13:38:
De laatste tijd heb ik inderdaad ook regelmatig roze plaatjes gezien Zo ook bij het eerder genoemde voorbeeld.

Je zal ze vooral in oudere topics wel veel vaker tegenkomen. Het maakt in ieder geval pijnlijk duidelijk hoe vergankelijk het internet eigenlijk is...

[Hero of Time]

crisp schreef op zondag 4 december 2016 @ 14:28:
Die svg is de placeholder die we gebruiken om te zorgen dat de layout niet verspringt als een plaatje niet geladen kan worden. We zullen daar dus waarschijnlijk een meer uitgebreide oplossing voor moeten verzinnen waar bij we de img-url ook beschikbaar maken.

Verklaart ook gelijk waarom rmb > reload image niet werkt. Zou wel fijn zijn als dat ook mogelijk zou worden, zodat je niet de hele pagina hoeft te herladen in geval de server even niet reageert voor een plaatje.

[vso]

liever een custom "deadpic" plaatje dan 1 vage kleur... waarbij ik liever een onderscheid tussen "doet het tijdelijk niet" of bron heeft het verwijderd ..(of domain is dood)

ik irriteer me aan die roze plaatjes meer dan aan de de voorheen het gebroken linkje icoon.. maar goed dat is mijn irritatie

[crisp]

vso schreef op dinsdag 6 december 2016 @ 16:36:
liever een custom "deadpic" plaatje dan 1 vage kleur... waarbij ik liever een onderscheid tussen "doet het tijdelijk niet" of bron heeft het verwijderd ..(of domain is dood)

ik irriteer me aan die roze plaatjes meer dan aan de de voorheen het gebroken linkje icoon.. maar goed dat is mijn irritatie

De 'broken image' link is inmiddels hersteld, maar wel in combinatie met de roze/rode placeholder. De functie van die placeholder is namelijk om hinderlijk verspringen van de layout te voorkomen.

Helaas is het technisch niet mogelijk om onderscheid te maken op basis van de oorzaak van het kapotte plaatje.

[Hero of Time]

Een 'Reload image' zal het dus alsnog niet doen, waardoor je de hele pagina moet vernieuwen met kans dat andere plaatjes op rood gaan in geval van een langzame host?

[crisp]

Hero of Time schreef op dinsdag 6 december 2016 @ 22:20:
Een 'Reload image' zal het dus alsnog niet doen, waardoor je de hele pagina moet vernieuwen met kans dat andere plaatjes op rood gaan in geval van een langzame host?

Jawel, rechtermuisknop -> reload zou wel moeten werken. Kans op andere rode plaatjes lijkt me klein, tenzij zo'n langzame host ook nog eens no-cache headers meegeeft

[Hero of Time]

crisp schreef op dinsdag 6 december 2016 @ 23:28:
[...]

Jawel, rechtermuisknop -> reload zou wel moeten werken. Kans op andere rode plaatjes lijkt me klein, tenzij zo'n langzame host ook nog eens no-cache headers meegeeft

Hoewel m'n eerdere voorbeeld nu niet op rood gaat, krijg ik bij een voorbeeld hier iig wel de mogelijkheid voor open in nieuw tab en heb dan geen w3.org ding in m'n adresbalk. Lijkt er dan idd op dat dat gedeelte is afgedekt hiermee.

[Bastien]

Het valt mij op dat de laatste dagen (?) plaatjes van tinypic telkens een roze vlak zijn. Reload image helpt niet in FF 53.nogwat, blijft gewoon roze.

Bijvoorbeeld: pitchdown in "Dode vissen in vijver"

Zie ook wat van 1drv (onedrive neem ik aan?) fout gaan in Ramon in "Wat is er met de layout van de artikelen"

[ Voor 38% gewijzigd door Bastien op 22-06-2017 21:08 ]

[Raven]

Bastien schreef op donderdag 22 juni 2017 @ 20:03:
Het valt mij op dat de laatste dagen (?) plaatjes van tinypic telkens een roze vlak zijn. Reload image helpt niet in FF 53.nogwat, blijft gewoon roze.

Bijvoorbeeld: pitchdown in "Dode vissen in vijver"

Same here, FF53.0.3 x64

Als ik de afbeelding probeer te openen d.m.v. https://ic.tweakimg.net/c...tinypic.com%2F1zdsos1.jpg invoeren in de url-balk , dan krijg ik een popup om een webp bestand op te slaan. De directe link naar tinypic werkt normaal.
@crisp Is camo weer rare dingen aan het doen?

[ Voor 5% gewijzigd door Raven op 22-06-2017 20:19 ]

[Hero of Time]

Plaatje in het vijver topic doet het bij mij prima. Die andere zijn bij mij ook rood, maar dat komt hierdoor:

Server not found
You tried to access the address https://dqaora-sn3302.fil...Q/wp_ss_20170621_0001.png, which is currently unavailable. Please make sure that the web address (URL) is correctly spelled and punctuated, then try reloading the page.

Tja, als de server foetsie is, hoe moet Camo er dan bij kunnen? Sterker nog, Camo komt hier helemaal niet om de hoek kijken want het is al https.

Dus, Camo doet niets fout, FF zit ergens te kloten. Iig voor het eerste voorbeeld.

[Bastien]

Hero of Time schreef op donderdag 22 juni 2017 @ 22:03:
Plaatje in het vijver topic doet het bij mij prima. Die andere zijn bij mij ook rood, maar dat komt hierdoor:

[...]

Tja, als de server foetsie is, hoe moet Camo er dan bij kunnen? Sterker nog, Camo komt hier helemaal niet om de hoek kijken want het is al https.

Dus, Camo doet niets fout, FF zit ergens te kloten. Iig voor het eerste voorbeeld.

Hmm, zover had ik niet gekeken. Dan zou ik ook geen roze vlak verwachten maar dat ben ik.

Wat betreft de dooie vissen: in Chrome krijg ik wel het plaatje te zien, in IE11 heb ik hetzelfde als in FF. Maar als dat zo hoort, het zal wel.

[crisp]

Chrome ondersteund ook wepb. Blijkbaar identificeert onze proxy zich als een webp-capable browser.

[Hero of Time]

Grappig. Ik had van Otter namelijk niet verwacht dat het met wat meer aparte formaten om kon gaan. Webkit based in Qt geschreven. Het kan zelfs geen Magnet links aan.

[Raven]

crisp schreef op donderdag 22 juni 2017 @ 22:33:
Chrome ondersteund ook wepb. Blijkbaar identificeert onze proxy zich als een webp-capable browser.

Is dat iets dat makkelijk te fixen is? En waarom lijkt dat alleen met tinypic te gebeuren?

[ Voor 10% gewijzigd door Raven op 23-06-2017 09:38 ]

[Hero of Time]

@Raven, wellicht omdat Tinypic webp serveert indien dat mogelijk is en andere imagehosters niet? Eventueel doen die wat meer intelligente dingen om zaken zoals een Camo proxy te herkennen en geen webp geven? Noem maar wat.

[Raven]

Hero of Time schreef op vrijdag 23 juni 2017 @ 10:29:
@Raven, wellicht omdat Tinypic webp serveert indien dat mogelijk is en andere imagehosters niet? Eventueel doen die wat meer intelligente dingen om zaken zoals een Camo proxy te herkennen en geen webp geven? Noem maar wat.

Maar dan blijft de vraag: waarom zo ineens die verandering? Tinypic werkte voorheen normaal.

[crisp]

Raven schreef op zaterdag 24 juni 2017 @ 10:00:
[...]

Maar dan blijft de vraag: waarom zo ineens die verandering? Tinypic werkte voorheen normaal.

Misschien zijn ze pas sinds kort webp gaan gebruiken?

[Raven]

crisp schreef op zaterdag 24 juni 2017 @ 10:26:
[...]

Misschien zijn ze pas sinds kort webp gaan gebruiken?

Dat zou nog kunnen, maar dat is iets dat volgens mij wel te vinden moet zijn, helaas zie ik niet zo gauw wat over de (eventuele) overstap daarnaartoe.

[crisp]

Raven schreef op donderdag 22 juni 2017 @ 20:17:
[...]

Same here, FF53.0.3 x64

Als ik de afbeelding probeer te openen d.m.v. https://ic.tweakimg.net/c...tinypic.com%2F1zdsos1.jpg invoeren in de url-balk , dan krijg ik een popup om een webp bestand op te slaan. De directe link naar tinypic werkt normaal.
@crisp Is camo weer rare dingen aan het doen?

Ik was hier nog even naar aan het kijken, maar dat plaatje doet het bij mij (nu) prima in Firefox. De directe link ( http://i64.tinypic.com/1zdsos1.jpg ) gaat hier wel naar een pagina en de link naar het plaatje is dan http://oi64.tinypic.com/1zdsos1.jpg - ik krijg echter in geen enkele browser een webp variant daarop. Wellicht hebben ze gewoon zitten klooien..

[ Voor 13% gewijzigd door crisp op 27-06-2017 09:57 ]

[Raven]

crisp schreef op dinsdag 27 juni 2017 @ 09:51:
[...]

Ik was hier nog even naar aan het kijken, maar dat plaatje doet het bij mij (nu) prima in Firefox. De directe link ( http://i64.tinypic.com/1zdsos1.jpg ) gaat hier wel naar een pagina

Check, hier doet ie nu ook ineens

[crisp]

Raven schreef op dinsdag 27 juni 2017 @ 09:57:
[...]

Check, hier doet ie nu ook ineens

Ze doen wel dingen op basis van user-agent en accept headers. Ik gok dat we tegen een test of faalactie van hun kant zijn aangelopen