Afbeeldingen (jpg) worden niet weergegeven

Status
Niet open voor verdere reacties.
W

whoppy1975

Gebruiker
Lid geworden
27 okt 2010
Berichten
33
Voor onze website krijgen wij van diverse partijen foto's aangeleverd, in diverse formaten.
Nu gebeurt mij met .jpg vaak het volgende:
Op het moment dat ik een .jpg afbeelding inlees in mijn website (via Dreamweaver dus) krijg ik ipv. de afbeelding een grijs vierkantje in mijn pagina, sommige mensen noemen het ook wel een "gebroken GIF-plaatje".
Als ik vervolgens met F12 naar het voorbeeld kijk krijg ik het befaamde rode kruis op de plek van de afbeelding.
Dit gebeurt echter niet met alle afbeeldingen, ik ben nu bijvoorbeeld bezig met een map met 32 afbeeldingen en bij 6 heb ik dit probleem.
Knip ik de afbeelding in Photoshop uit en plak ik het in een nieuw afbeeldingsbestand en sla het als een ander bestand op (eerst psd, dan converteren naar jpg) dan blijft het probleem bestaan.
Open ik het bestand in Paint en breng ik een wijziging aan van niets, dan krijg ik als ik het weer op wil slaan de melding: "Paint kan dit bestand niet opslaan. Opslaan is afgebroken. Het bestand is niet opgeslagen."
De enige oplossing is de desbetreffende afbeelding openen, een screenshot maken, deze plakken in Paint en dan weer opslaan..............hoezo kwaliteitsverlies???????

Heeft iemand een idee wat er met deze afbeeldingen aan de hand is of kan zijn?
 
Hoi whoppy1975,
Nop, nog geen idee.
Maar kan je ergens een ongewijzigde ontvangen jpg uploaden, waar het mee mis gaat, en hier een link zetten?
Dan kunnen we eens een blik werpen op het inwendige.

Met vriendelijke groet,
CSShunter
 
Ik heb hem als orgineel ongewijzigd bestand op een oude site van me gezet:
http://www.mtceelde.nl/crunzzkip.jpg
Je ziet alleen echter een rood kruis.
Voeg ik hem echter bij dit bericht en download ik hem dan weer, dan kan ik hem weer gebruiken...........crunzzkip.jpg
 
Laatst bewerkt:
Hoi whoppy1975,
Hier mijn bevindingen (ik noem de eerste crunzzkip: crunzzkip-ori.jpg; en de andere: crunzzkip-nw.jpg).
  • De crunzzkip-ori.jpg wordt niet in IE7 weergegeven (het rode kruisje), maar wel in Firefox, Chrome, Safari en Opera!
  • De crunzzkip-nw.jpg doet het in alle browsers.
  • Er is een enorm verschil in bestandsgrootte! De ori is 1.039kB (1MB), de nieuwe is maar 93kB. De originele is dus maar liefst 11 keer zo groot.
Ik heb ze alle twee gedownload.
  • Ze zijn alle twee te openen met Paint Shop Pro en met IrfanView (download hier !).
  • Er is ook een fiks verschil in afmetingen: de ori is 2362*1181px, de nieuwe maar 1556*778px.
Dit zijn de img-properties volgens IrfanView:

crunzzkips_img-props.gif

  • Het origineel blijkt "EXIF" gegevens te bevatten ("camera-informatie"), als enige "IPTC-info" het woord "Print", en geen "Kommentaar".
  • De nieuwe versie heeft géén EXIF-data, géén IPTC-info, maar wel Kommentaar.
De EXIF-data van het origineel zien er zo uit:

crunzzkip-ori_EXIF-info.gif

Daaruit valt op te maken dat de "camera" is geweest: Adobe Photoshop CS3. Daar is de afbeelding kennelijk in gemaakt voordat deze bij jou binnenkwam (het ziet ernaar uit dat het dus geen rechtstreekse camera-jpg is, maar geïmporteerd en opgeslagen in Photoshop).

De Kommentaar-info bij de nieuwe versie is:

crunzzkip-nw_jpg-comment.gif

Hieruit blijkt dat de maker van deze jpg is: GD-JPG 1.0. Dat ziet er uit alsof het een php-bewerking op de server van helpmij is geweest, voordat deze als attachment geplaatst werd. "GD" = "GD Grafics Library", voor serverside img-bewerking met o.a. php.
Die heeft het in elk geval goed gedaan (en ook de EXIF-data gewist)! :)

Lokale bewerking
PSP6
  • Origineel geopend met PaintShopPro6, en zonder iets te doen weer opgeslagen als jpg, met max. kwaliteit (=minimale compressie), in progressieve codering.
  • Resultaat: crunzzkip-ori_duplo-psp6.jpg
  • Originele formaat gehandhaafd: 2362*1181px.
  • Bestandsgrootte: 511kB.
  • Deze is ook te bezichtigen met IE7!
IrfanView
  • Origineel geopend met IrfanView, en zonder iets te doen weer opgeslagen als jpg, met max. kwaliteit (=minimale compressie), in progressieve codering.
  • Resultaat: crunzzkip-ori_duplo-irfanview.jpg
  • Originele formaat gehandhaafd: 2362*1181px.
  • Bestandsgrootte: 210kB.
  • Met en zonder EXIF-data: geen verschil, exact even groot bestand.
  • Deze is ook al weer te bezichtigen met IE7!

Bijsnijden / verkleinen
Als je de afbeelding gaat bijsnijden om het overtollige wit rondom te verwijderen, blijft er nog altijd een img van zo'n 1800px breed over.
  • Dat is veel te breed voor een beeldscherm van 1024*768px, waar je bij een website rekening mee moet houden.
  • Omdat browsers niet zo goed kunnen schalen, kan je het beste de afbeeldingen in een tekenprogramma verkleinen tot het werkelijke te tonen formaat op scherm.
  • Dat maakt ook de te downloaden hoeveelheid kB's prettig kleiner, en de pagina sneller.
  • Resultaat bij bijsnijden en verkleinen met IrfanView: 980*372px, bij max. kwaliteit is dat een jpg-bestand van 85kB: crunzzkip-ori_bijgesneden-verkleind_irfanview.jpg.
  • En waarschijnlijk is die nog veel te groot om als als illustratie te dienen: dan kan ie nog kleiner en nog sneller.

Conclusies
Er schijnt iets vreemds aan de hand te zijn met de binnengekomen jpg's of met de bewerking in Photoshop. Geen idee wat dat kan zijn.
Maar als je de originelen bewerkt met IrfanView is er gelukkig geen probleem.

Heb je hier iets aan?
Het scheelt in elk geval screenshots en MSPaint! ;)

Met vriendelijke groet,
CSShunter
 
Laatst bewerkt:
Sorry voor mijn late reactie en bedankt, ik ben geholpen, al was het wel een moeilijk verhaal voor mij omdat ik helemaal niet in dit soort techniek thuis ben :D

Nog even een korte vraag en misschien te makkelijk gedacht: tijdens het zoeken naar dit probleem kwam ik ook onderwerpen tegen over het verschil van CMYK en RGB afbeeldingen en in jouw screenshots zie ik dat het orgineel CMYK is en dit zie ik niet terug bij de werkende kopie, is dit een deel ven het probleem (of het hele probleem?).

Met Infranview werkt het i.i.g. perfect!!!!
 
Hoi Whoppy,
Nou, dat was me nog niet eens opgevallen, en dat zou zeker wel eens met het probleem te maken kunnen hebben. Het fijne weet ik er niet van, maar er is inderdaad een verschil tussen de CMYK kleuren (drukwerk met opvallend licht; hoe meer CMYK kleuren, des te zwarter) en de html RGB kleuren (voor lichtbronnen: menging van licht; hoe meer RGB-kleuren, hoe witter). De ene stelt de kleuren samen met de van-elkaar-aftrek-methode (subtractief), de andere met de optel-methode (additief).

rgb-cmyk.png

Vanwege de beperkingen van elk van de systemen van kleurdefinitie/kleurmenging is er wel een overlap in welke kleuren gemaakt kunnen worden, maar er zijn ook verschillen in wat van de kleurruimte ("colorspace", kleurenspectrum) gebruikt kan worden. En het menselijk oog kan weer meer waarnemen dan beide soorten:

color-spaces.png

Nu haal ik uit de gegevens hierboven dat de originele afbeelding als CMYK-jpg was opgeslagen (en er stond ook "print" bij de opmerkingen!), terwijl html de RGB-kleuren gebruikt.
Het zou dus kunnen zijn, dat je bij Photoshop kunt kiezen in de manier van opslaan: met een CMYK dan wel een RGB-colorspace. Zit zo'n optie er op?

Er blijft de vraag: waarom kan Internet Explorer niet overweg met z'n CMYK-gecodeerde jpg, en andere browsers wel? Ik gok dat de andere browsers een ingebouwde converter CMYK > RGB hebben, en IE niet.

Tenslotte kwam ik al Google'end nog interessant leesvoer tegen over kleuren en Photoshop, uit "Adobe Photoshop: The Complete Guide: Part 2":
Met vriendelijke groet,
CSShunter
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan