Compressie afbeeldingen met FPDF

[Joël Plas]

Hoi Bert-Jan,

Ik was voor Paul even aan het experimenteren in Acumulus met zijn logo, maar ik merkte dat het logo in FPDF er heel erg slecht uitkomt vergeleken met de RTF. Het lijkt alsof FPDF er een heftige compressieslag overheen gooit, waardoor logo\'s en vooral tekst heel erg korrelig worden.

Nu heb ik snel even gezocht en ben het volgende tegengekomen als mogelijke oplossing:

http://www.kirupa.com/forum/showthread.php?t=297066

Misschien heb je binnenkort tijd om er even naar te kijken..

Groetjes Joël

[Bert-Jan]

Dank je Joël. Ik ben er mee aan de slag.

[Bert-Jan]

De conversie van maateenheden was niet helemaal correct. Ik heb daar e.e.a. in aangepast en het lijkt erop dat de afbeeldingen nu zuiverder worden weergegeven.

Edit:
Ik had als omrekenfactor 3.7 (gevonden met eindeloos proberen) en kwam in jouw stukje de suggestie tegen om 72dpi/25.4mm te gebruiken. Dat leverde niets op maar 96/25.4 wel. Dit geeft het getal 3.779527559 en dat blijkt exact de juiste schalingsfactor te zijn.

Dank voor jouw tip.

[Joël Plas]

De conversie van maateenheden was niet helemaal correct. Ik heb daar e.e.a. in aangepast en het lijkt erop dat de afbeeldingen nu zuiverder worden weergegeven.

Ziet er al een stuk beter uit! Dank!

[Paul Houkes]

Yes, hier ben ik blij mee.
Paul.

[Bert-Jan]

3.779527559

de gulden snede van FPDF

[R. Pieters]

Kunnen jullie in Jip en Janneke taal uitleggen, hoe iemand die niet veel verstand heeft van dit soort zaken ook een helder en duidelijk logo krijgt bovenaan de facturen van de verschillende bedrijven.

Remmy

[Bert-Jan]

Heb je reeds een logo?

[Paul Houkes]

Als Jip en Janneke: voor verschillende bedrijven (binnen een Acumulus-account) kan nu nog niet automatisch. Ik los dat nu voorlopig op door het juiste briefhoofdlogo even te uploaden zodra ik facturen aanmaak.

Als logo kun je een jpg- of gifbestand gebruiken van maximaal 500 pixels breed. In Beheer en vervolgens Factuur-instellingen kun je je logo uploaden.

Paul.

[Olaf Lederer]

Paul, je moet je niet storen aan de praat over fpdf en zo

@Bert-Jan, hoezo laat je FPDF de hoogte of breedte niet zelf uitrekenen?
Het klopt een verschaalt logo in een pdf ziet er soms niet zo goed uit, maar als een factuur geprint wordt is het wel goed.
Ik maak er complete foto sheets met fpdf gaat prima

[Bert-Jan]

Bert-Jan, hoezo laat je FPDF de hoogte of breedte niet zelf uitrekenen?

Ik moest e.e.a. aanpassen om het goed te krijgen. Misschien zag ik iets over het hoofd maar nu is de schaling goed.

Het klopt een verschaalt logo in een pdf ziet er soms niet zo goed uit, maar als een factuur geprint wordt is het wel goed.

Dat is waar. Het probleem zat in de schaling naar schermpixels. Veel PDF\'s worden helemaal niet uitgeprint maar gewoon digitaal bewaard.

[rogier]

Beste allen: hetgeen hier vermeld wordt is niet geheel waar.
@Bert-Jan: ik meen dat ik je dit ooit toegemaild heb mbt het plaatsjes verhaal en de imlpementaties ervan.
Zie eventueel ontvangen emails door mij.

Om e.e.a even in een keer duidelijk te stellen:

- FPDF werkt, net als alle (?) PDF implementaties met een DPI van 72. In menselijke termen: voor elke Inch (2.54 cm) zijn er 72 beeldpunten.
- Plaatjes worden vaak tot zeer vaak met GD (veelal mbv PHP) gegenereerd. GD gebruikt vandaag de dag intern een DPI waarde van 96: 96 beeldpunten per inch.

In deze specifieke gevallen, klopt exact wat hier vermeld wordt.
Helaas slaan de meeste image converters de DPI informatie NIET op.
Images zijn echter in het geheel NIET beperkt op een bepaalde DPI. Een plaatje dat direct
uit een scanner komt, is vaak gescand op 300 DPI! Goede imageconverters zullen dit zonder meer
gewoon converteren en daadwerkelijk 300 DPI gebruiken. In de praktijk echter is 96 DPI een
zeer veel toegepaste waarde.

De omrekeningsfactor komt dus nu goed uit, maar dit is niet altijd het geval.
Hiervoor zal van het bronbestand altijd de DPI waarde bekend moeten zijn. In JPEG bestanden
wordt dat al vaker opgeslagen, omdat het formaat van JPEG daar definities voor heeft.

Als nu de standaard omrekenfactor 72/25.4 is, en je een bestand van 300 DPI wilt kunnen gebruiken,
is de omrekenfactor bijv al (300/72) * 72/25.4 = 300/25.4.

Kortom: de omrekenfactor is rechtevenredig met de DPI van het BRONBESTAND!

Ik hoop dat ik hiermee ook meteen de vraag van finalwebsites heb beantwoord:
omdat je in de meeste gevallen de DPI niet terug kunt halen uit het bronbestand,
is eenduidig uitrekenen van de hoogte/breedte door FPDF niet altijd een oplossing en
zal ook niet altijd leiden tot correcte resultaten!

Wat betreft Bert-Jan\'s
\"3.779527559

de gulden snede van FPDF\"
JA.... maar alleen als de DPI van de bron ook daadwerkelijk 96 is!

[Bert-Jan]

Dankje Rogier,

Ik moet toegeven dat ik het complexe materie vind en vooral pragmatisch te werk ga. PDF\'s worden meer op het scherm getoond dan uitgeprint. Op het scherm ziet het er in de regel nu beter uit.

Even een domme vraag: is die eigen DPI van bestanden met php te lezen?

[lexicam]

Hoi Bert-Jan,

Mijn logo ziet er nog steeds niet mooi uit

[rogier]

Nee hoor Bert-Jan... dat is zeer zeker geen domme vraag.
Er zijn voor een aantal bestandsformaten inderdaad methoden om deze informatie terug te halen.
Voor JPEG word die informatie ergens in een bitmasker weggeschreven (lees: binair)
Er zijn een aantal open source libraries beschikbaar om die info te krijgen, maar het komt vaak neer op hetzelfde patroon.
Een bekende library is de \"PHP JPEG Metadata Toolkit\", maar ik meen dat deze beperkt is tot JPEG informatie.

EXIF (http://php.net/exif) is een andere manier, maar is aan wat voorwaarden verbonden en ik weet niet uit mijn
hoofd of die ook de dpi ondersteunt.

Andere images slaan deze informatie vaak helemaal niet op en worden dan met een ingestelde standaardwaarde
gebruikt (bijv bij printen), waardoor deze er soms helemaal niet uitziet zoals de bedoeling was.

Maar dan nog loop je eigenlijk veel vaker tegen een ander probleem aan: heel veel image converters,
waaronder GD voor PHP, slaan deze informatie gewoonweg helemaal niet op. Waardoor je veelal een gok moet doen
voor de DPI. Gelukkig is 96 DPI wel vaak een defaultsetting in vele overige pakketten.

Een veelgehanteerde methode is deze:
lees de JPEG direct, met name bytes (karakters) 14-18.
- byte 14: 01, X and Y density unit specifier (00: none, pixel ratios, 01: DPI,02: DPC)
- bytes 15-16: horizontal pixel density, ofwel de horizontale densiteit
- byte 16-18: vertical pixel density, ofwel vertical densiteit

in principe is het dan dus zo dat indien byte 14 de waarde 01 heeft, het volgende paar van 2 bytes (4 in totaal dus)
de DPI aangeven. (Even uit mijn hoofd: ik weet niet of dat in Big-endian of Little-endian order is... deze orders houden in of je de binaire tekenreeks (8 bits per byte) van links naar rechts moet lezen of juist andersom)

Ik meen me verder ergens nog te herinneren dat voor JPEG tegenwoordig eigenlijk niet meer 1 standaard is en dat sommige digitale camera\'s
een ander info formaat hanteren. Zodoende geeft de JPEG niet meer in alle gevallen de correcte informatie terug.

Ik hoop dat je hier iets mee kan?
Anders verneem ik dat vast wel van je

[Bert-Jan]

Hoi Bert-Jan,

Mijn logo ziet er nog steeds niet mooi uit

Hallo Lexicam,

Dat zit denk ik de verkleining van het plaatje om het passend te maken. Heb je ook een kleiner logo dat reeds minder dan 300 px hoog is?

[Bert-Jan]

Dankje Rogier,

Ik ga op onderzoek uit.

[rogier]

- sorry voor een kleine fout in mijn laatste post:

byte 16-18: vertical pixel density, ofwel vertical densiteit

zal natuurlijk
byte 17-18: vertical pixel density, ofwel vertical densiteit
moeten zijn

[Bert-Jan]

Zo diep was er ik er nog niet ingedoken...

[rogier]

Ik realiseer me ineens dat ImageMagick ook wel degelijk dat soort informatie levert, indien aanwezig.
Zie hier: (even snel ge googled)
http://www.sitepoint.com/forums/showthread.php?t=527038

Ik denk dat daar wel wat relevante informatie bijstaat, althans... voor het begrip van...
Even lezende, wordt me al snel duidelijk dat ImageMagick of de eerder genoemde jpeg metadata toolkit
de beste opties zal leveren om de informatie te achterhalen uit images van met name digitale
camera\'s... Maar of je daar binnen de scope van Acumuls wat aan hebt is ten tweede.

[Enver]

Kwaliteit van mijn logo is nog steeds matig.
beeld is een beetje wazig.
Logo is 171 X 107
Wat moet ik er voor doen om de logo scherper te krijgen?

[Bert-Jan]

Kun je het logo naar ons sturen: klantenservice@acumulus.nl?

Het liefst in de meest optimale vorm.

[Enver]

Done.

[lexicam]

Logo gestuurd