Geacht Forum,
Ik kom nog maar even terug op een eerdere discussie van ca. een half jaar geleden.

Ik heb gekozen voor Aldfaer met p.p. veel afbeeldingen (foto's aktes). Het probleem is dat een parenteel niet meer kan worden ingelezen. De "plaatjes"komen niet in beeld (html bestand is te groot). De opties: afbeeldingen verkleinen, inlezen in bijv. "Opera" etc werkt ook niet. Ik krijg bij "Opera"wel een volledig bestand maar kan het dan niet inlezen in Word of PDF.

U gaf in het verleden aan, dit probleem (dat vlgs uw mededeling niet zo ingewikkeld is) op te lossen, door bij het aanmaken van de rapportage bijv. de max limiet html te begrensen en dan de rest in een ander html bestand in te lezen (of iets dergelijks).
Is het nu zo ver dat ik deze vraag weer aan u kan voorleggen?
Ton Beltzer

Dag Ton,

Ik kan mij de eerdere discussie niet herinneren, maar ik vermoed dat het probleem eerder een kwestie van capaciteit van het virtueel geheugen is

De eenvoudigste oplossing lijkt mij in je rapportages het aantal generaties te beperken.

Ook kan je overwegen om de gebruikte afbeeldingen eerst om te zetten naar een afmeting die met je instellingen overeenkomt (postezegel afmeting?) want ook hiet lijkt volgens mij het probleem van het oproepen van het opgenomen materiaal in het opslagformaat en eerst daarna op de computer te verkleinen naar de instelafmeting te spelen.

Beste Ruud
Ik heb wat geexperimenteerd. Het beperken van de generaties zou het ei van Columbus kunnen zijn. Ik geef dan net zoveel generaties op dat Aldfaer (maar eigenlijk de max. maat van html)het aankan.
Mijn vraag is dan: is er ook een manier om dan het vervolg (stel dat ik gen. 1 to t 7 in de parenteel stop), dus generatie 8 tot bijv. 15 op te roepen.
Het probleem is natuurlijk dat bij het beginpunt (gen. 1) we het over 1 persoon hebben en het beginpunt bij bijv. gen. 10 een behoorlijk aantal personen zal zijn?

Bedankt vast voor de moeite.
Ton

ter info
Ik heb dit o.a. 24 nov. 2010 aangekaart
en daarvoor in september.
Ik ben de naam even kwijt, maar een van de personen, die regelmatig de vragen in de helpdesk beantwoordt, deelde toen mede, dat het probleem redelijk eenvoudig was op te lossen (its met een "knip"in de rapportage - html). Hij deelde toen ook mede door niet nader aan te geven (persoonlijke) omstandigheden, dit niet direct op te kunnen pakken!
Ton Beltzer

Dag Ton,
Ik stel voor dat je eens volgende testen uitvoert.
a) zonder generatie beperking, maar zonder materiaal
als dat werkt,
b) idem maar met max 1 stuk materiaal
als dat werkt, dan is het voor mij een indicatie dat het een geheugenkwestie is en niet een html beperking

Dan gaan we verder zoeken voor een oplossing

Beste Ruud
Hier het resultaat van de tests:
Alg. info:
Windows 7 Home Premius 64 Bit
Aldfaer laatste versie, aut. update incl. invoegtoep.
Afb. worden geresized tot (mid) 1366x768 screen (de small 854x480 geeft geen goede weergave meer).
Office Word 2010, comprimeer dan nog tot Scherm 150ppi

Nu de tests
1/Alle afb. (geen privacyfilter/geen bep. generaties), = 1835 afb. totaal 193 MB. Na opvragen Parenteel in Aldfaer niet alle afb. zichtbaar (vierkantje, leeg vlaktje, rs boven klein rood kruisje dan naam afb. en onderaan tekst foto).

2/test met 1 af. idem, dit zijn 1077 afb. 113 MB. In Aldfaer rapp. alles zichtbaar. Als in het apart opsla op mijn schijf en open, verschijnt wel de tekst maar niet de afb. (althans in MS Exlporer) met Google Chrome als ingestelde browser lukt het wel). Als ik dan in Word inlees gaat het goed maar de plaats worden in Word niet ingesloten (de Word file is maar 2,36 MB).

3/test zonder materiaal. alles gaat goed (is maar 5MB, 4900 personen).

Het is vlgs mij duidelijk een html cap. probleem.
Zie ook mijn opm. bij Forum Sjablonen van 17 maart waar Meije van Salgeren op heeft regeageerd.

Ik wacht met spanning af en uiteraard vast bedankt voor de moeite.
Ton Beltzer

Dag Ton,

Je zegt: Afb. worden geresized tot (mid) 1366x768. Dat betekent dat de originelen nog groter zijn. 1366x786 pixels betekent:
1) In z/w 1.07 Mb
2) In grijstinten en kleur ongeveer 16 Mb (een eventuele compressie telt hier niet !!)
1835 afbeeldingen maakt circa 30 Gb. Echter de originelen zijn volgens je zeggen nog groter, stel gemiddeld 30-40% maakt 40 Gb.

Dit betekent dat het programma waarmee je dit wilt weergeven naast zijn eigen werkgeheugen nog 40 Gb aan geheugenruimte nodig heeft. In tegenstelling tot programma’s als Adobe Photoshop, Quark Xpress e.d., waar je met een instelling een gedeelte van de harde schijf als werkgeheugen (virtueel geheugen) kan toekennen, wordt dit voor alle andere programma’s (voor zover mij bekend) door Windows geregeld. De aan een programma toegekende hoeveelheid geheugen zal mede afhankelijk zijn van de hoeveelheid en omvang van andere programma’s die geopend zijn. Dit kan derhalve tot conflicten leiden. Het is daarom dat ik vermoed dat hier geen sprake is van html beperkingen maar gewoon van “overbelasting” van de computer.

Hoe dit te bewijzen?

Begin met je test te herhalen maar iedere keer met een minimum van andere functies in gebruik. Dus ook geen Windows verkenner open en b.v. Aldfaer gesloten als je in IE het resultaat opent.

Als dat geen resultaat heeft hoop ik dat je middels een programma als Irfanview in staat bent om de originelen te verkleinen. In dat geval doe het volgende:
a) Kopieer eerst de inhoud van de map Materiaal naar een map MateriaalKopie
b) Met Irfanview de bestanden in de map Materiaal verkleinen naar b.v. max hoogte 120 pixels
c) In instellingen kies je nu voor de afbeeldingen een maat van b.v. 5x5em
d) Herhaal nu de test alle afbeeldingen zonder beperkingen en kijk wat de resultaten zijn.

Als ik gelijk heb worden nu alle afbeeldingen (weliswaar klein) weergegeven en wijst dat erop dat er geen sprake is van een html beperking doch van een overbelasting van de computer

Beste Ruud,
Bedankt voor je reactie. Ik ga uiteraard doen wat je voorstelt maar ik vraag met ook het volgende af.

In mijn map Materiaal (van Aldfaer) zitten 5176 afb., de map is totaal 458 MB, dat is vlgs mij gemiddeld 89Kb per foto. Dat is toch niet zo groot? Als ik de map bekijk komt ook zeker 98% van de afb. niet boven de 100Kb uit, en de rest zit tussen de 100 en 250Kb.

Het feit blijft wel natuurlijk dat als ik er dan voor de Parenteelhelsloot (daar hebben we het over) ca.1850 afb. van nodig heb, dat dat dan ca. (1800 is ca. 1/3 van 5000) 458/3 geeft 150 MB vergt.

Maar ik dus ook jouw tests doen en kom er dan wederom op terug.
Ton Beltzer

Beste Ruud,
De tests gedaan.
Internet explorer 9 ook maar gelijk geinstalleerd.

Na wijziging in Infranview (via File/Batch - output Jpeg, advanced options - Resize hoogt 120 ) bleeft er van de oorspronkelijk map Materiaal van 458 MB nog ca. 50 MB over, de afb. waren nu allemaal in de order van grootte van 5-6-7 kb.

Inlezen in Aldfaer (rapport parentelen)geen probleem, alle ruim 1800 afb. zichtbaar. Opgeslagen op schijf en daarna opgestart met IE browser, ook geen probleem, alles zichtbaar.
Uiteraard gave deze "postzegels"na klikken (uitvergroten) op de afb. bij de aktes geen leesbare tekst te zien.

Ik hoor graag
Met vr. gr.
Ton Beltzer

Er is maar een (1) oplossing, de parenteel in diverse stukken knippen, zodat hapklare brokken ontstaan, die wanneer ze nodig zijn, door de browser worden ingelezen. Hoe kleiner de brokken hoe sneller het gaat, uiteraard.

Hoe dat knippen moet, is de volgende vraag.
Achteraf, nadat de de html-code is gegenereed, is een lastige klus, dus niet aan te bevelen.
De sjabloonbouwer zal aan de slag moeten en een optie inbouwen waarin het aantal 'brokken' kan worden ingesteld. DS

Beste Dirk

Vandaar mijn verzoek aan Ruud en Meije van Slageren (zie bij Forum Sjabloon 17 maart Aanvulling Sjabloon rapporteren in boekvorm), waarbij ik een voorstel poneer en de reactie van Meije.

Ik hoop op een oplossing en ben ik blijde afwachting en last but not dank alle betrokkenen voor hun inspanning.

Ton Beltzer

Dag Ton

Denkfoutje: de grootte van een opgeslagen bestand is dat van NA compressie. Voor de weergave in een programma moet dit eerst "uitgepakt" (décompressie) worden. Mijn berekening gaat van die uitgepakte toestand uit.

Het feit dat je nu wel een volledige weergave krijgt geeft aan dat het pertinent geen html probleem is want ongeacht de grootte van de afbeeldingen, de html blijft hetzelfde.

De voor jou beste oplossing is het gebruik van een sjabloon die van de "postzegels" een klikbare afbeelding maken met een hyperlink om individueel de grote afbeelding te kunnen openen in IE (of andere browser) in een ander venster.
Bijkomend voordeel is dat de download van een dergelijk rapport vele, vele malen sneller gaat.

Volgens mij staat dit op de wensenlijst, maar ik weet niet of een andere gebruiker inmiddels een dergelijk sjabloon heeft gemaakt.

Ik heb mij onvoldoende in sjablonen verdiept om zelf een bruikbare oplossing aan te dragen, dus helaas kan ik je niet verder helpen.

Neemt niet weg dat ik zelf ook gaarne een dergelijk sjabloon kan gebruiken

N.B: Op http://home.tiscali.nl/kallenbe/paul/aldfaer/rapportuitvoer/overzicht.html kan ik een dergelijk sjabloon niet vinden

Beste Ruud,
OK, dat weten we dus. Na deze analyses concludeer ik, dat het probleem op twee manieren is op te lossen:

1/Het sjabloon waar jij over spreekt en wat kennelijk al in de wensenlijst voorkomt, dat van (te) kleine (te weinig ppi)afbeeldingen een grotere (leesbare) kan produceren.
Ik neem aan, dat dit ook werkt als je een dergelijk html bestand op je eigen Website hebt staan en een bezoeker wil dat bestand bekijken.

2/Het toevoegen (bijv. in het sjabloon "Maak boek"van de bonusrapporten) van een optie waar een beginwaarde (van generatie - tot generatie) en een eindwaarde kan worden ingegeven,waardoor je de te produceren html file op voorhand kunt "verknippen"in handelbare brokken.

Ik hoop eigenlijk dat beide mogelijkheden zullen worden gerealiseerd, zou een enorme verbetering zijn.
Uiteraard hartelijk bedankt voor de inspanningen.
Ton Beltzer

Dag Ton,

1) gegarandeert, dat werkt. Ik heb dat ooit eens handmatig gedaan, maar dat was niet te "onderhouden"

Als je over een zip bestand spreekt heb je gelijk, maar een plaatje met de extensie jpg kan in IrfanView behoorlijk fysiek worden verkleind, en behoeft niet meer uitgepakt te worden bij het tonen. DS

Dirk,

Natuurlijk kan Irfanview een jpg verkleinen. Dat heb ik toch aangegeven. Blijft dat een jpg (net als een zip) een gecomprimeerd bestand is en voor de weergave eerst gedécomprimeerd moet worden.
Je gelooft me niet? Open een jpg in Photoshop en kijk links onder hoe groot de afbeelding is. Ik heb het even voor je gedaan. 1,77 Mb jpg wordt 28.7 Mb in Photoshop RGB. Dat betekent dat deze afbeelding effectief en niet gecomprimeerd ongeveer 1/3e van 28.7 Mb is, dus 9.2 Mb

Overigens 1) waar zou dan de compressiefactor in de jpg conversie voor dienen? Enne, éénmaal gecomprimeerd met b.v factor 5, kan je niet meer effectief terug naar b.v factor 8 of 10

Overigens 2) een jpg in een zip wordt niet of nauwelijks kleiner. Ook dat heb ik voor je gedaan. Die 1.77 Mb wordt 1.74 Mb

Je hebt helemaal gelijk.
Met IrfanView is het duidelijker aan te tonen. DS