Doka belichtingmeter.

[PieterB]

Misschien kan je je dan beter naar de ontwikkelaar van vuescan richten???
Mooi idee, maar ik denk niet dat een negatiefscanner zo nauwkeurig is (toch niet allemaal) of beter: het is niet het doel waarvoor een negatiefscanner wordt gemaakt Bovendien zijn er zoveel verschillende soorten negatiefscanners...

Wat mss wel haalbaar is, is een klein scanprogramma dat met behulp van het histogram + een aantal punten op het negatief (lichtste en donkerste dus), een ruwe schatting geeft van wat je hierboven vermeld (belichtingstijd en gradatie)

Maar ik vrees dat je dan belange niet in de buurt komt van een splitgrade, maar ja ik ken er niets van hoor...
Kwil wel altijd helpen programmeren ;-)

[jev]

Wat waren je bevindingen, den k je dat 't iets bruikbaars zou kunnen worden ?

Ik was zo ver dat ik een eenvoudige lichtmeting kon doen met daaraan gekoppeld een belichtingstijd voor mijn typische situatie. Dat correleerde dan direct naar een enkelvoudige belichtingstijd waarmee ik m'n vergroter kon aansturen. De volgende stap was om de contrastomvang vast te stellen om op basis daarvan dan een uitspraak over het gewenste gradatiefilter te kunnen doen. Ook is het ding nog bruikbaar als timer voor de afzonderlijke baden. Er gaat een buzzer af als het tijd is om naar het volgende bad over te stappen. Die tijd is ook zichtbaar te maken op het 7-segment display, maar dat heb ik in de praktijk nog niet gebruikt (zou dat geen lichtsluier opleveren?).

In de praktijk bleek de positie van de sensor het grootste probleem. De donkerste delen en de lichtste delen uit het negatief zijn toch moeilijk te bepalen met zo'n klein sensortje. Daarbij zit het ding op een wat ongunstige plaats vlak naast een potmeter en half afgeschermd door een topboardje (nou ja, zeg maar een tobboardje ). Daar moet denk ik toch een wat geavanceerdere, off-PCB oplossing voor komen met een soort diffusortje erboven.

Anyway, gisteren nog even rondgesnuffeld op een oude harde schijf. Helaas zijn de repositories van het versiebeheerssysteem die daar op staan beschadigd en wat ik nog op mijn "nieuwe" systeem terug kan vinden is eigenlijk niet meer dan een handvol drivers. De applicatie was gelukkig niet zo bijster ingewikkeld.

Wat voor ervaring heb je? Ik kan maandag de schema's wel even beschikbaar maken denk ik en wellicht de software ook wel - maar heb je een M16C ontwikkelkit ter beschikking? Ik gebruik de TASKING M16C ontwikkelomgeving (da's mijn werkgever, vandaar ), maar porteren naar de originele Mitsubishi omgeving moet niet al te ingewikkeld zijn (behalve het dresseren van de linker/locator wellicht).

Prototypen op een PC zie ik niet zo zitten in dit geval - het meeste werk is toch bitgeneuzel in de drivers.

[juw]

Als ik kijk naar een FEM-Analyser of een Heiland dan zit in de eerste 30 jaar analyser ervaring (Wallner) met een goede praktische uitwerking van de meetprobe die denk ik nauwelijks te verbeteren valt.
De Heiland gaat nog een stapje verder ivm. het aanstuursysteem en de voorgeprogrammeerde calibratie's.

Dit maak je in een practische vorm niet even zelf, afgezien dat het mechanisch maken van een goede cosphi meetkop niet echt eenvoudig en goedkoop is.
Het enige wat van software goedkoop is, is het schrijven van een programma, mits je het zelf beheerst.
In het verleden zijn meerdere hobby systemen gepubliceerd (Foto & Labor, Elektuur enz.) Bijna allemaal goed voor de prullebak geweest. Voor het goed uitontwikkelen van een product is meer nodig.

Robert

(gelukkig geen marketing gestudeerd, maar wel electronica) - hé leuk onderschrift -

Daar was ik dus al bang voor, veel kennis in de software en een moeilijk te maken meetkop. Wat is een 'cosphi meetkop' (google leverde niets op.)

Bedankt voor de tips.

[juw]

Ik vind deze apparaten ook schandalig duur. Maar nu ik ze heb, zou ik er meteen weer dezelfde prijs voor betalen, want ze zijn het wel degelijk waard. Maar als jij iets evenwaardigs goedkoper kunt maken, dan ben ik een van je eerste klanten.

M'n doel is echt niet om 'm beter te maken, maar betrouwbaar en betaalbaar voor mijn manier van werken. (voor een erg zachte prijs.). Het doel is om de lichtmeter van een oude philips dokameter te slopen, en daarmee aan de slag te gaan en kijken waar het schip strand.

Het zal zeker geen commercieel product worden, of je moet ergens nog een stapel oude philips dokameters hebben liggen :-)

[Fotohuis]

Bij oude lichtmeters is de responsetijd van de meetcel vrij traag. Geen goed uitgangspunt voor een nieuw ontwerp.

Cos phi meetkop is een systeem met draaibare meetcel waardoor het mogelijk is bij dokalicht en open diafragma de multi-point metingen te doen.

Alternatief is een eenvoudige vlakke meetkop en tijdens de meting de dokaverlichting uit te schakelen. Ga je over op een dynamische meting (veel meetpunten in je negatief en dus een continu meting) dan is dit laatste de enige manier om correct te kunnen meten.

Groetjes,

Robert

[juw]

Ik was zo ver dat ik een eenvoudige lichtmeting kon doen met daaraan gekoppeld een belichtingstijd voor mijn typische situatie. Dat correleerde dan direct naar een enkelvoudige belichtingstijd waarmee ik m'n vergroter kon aansturen. De volgende stap was om de contrastomvang vast te stellen om op basis daarvan dan een uitspraak over het gewenste gradatiefilter te kunnen doen. Ook is het ding nog bruikbaar als timer voor de afzonderlijke baden. Er gaat een buzzer af als het tijd is om naar het volgende bad over te stappen. Die tijd is ook zichtbaar te maken op het 7-segment display, maar dat heb ik in de praktijk nog niet gebruikt (zou dat geen lichtsluier opleveren?).

Klinkt al redelijk werkbaar, en zeker uit te breiden.

In de praktijk bleek de positie van de sensor het grootste probleem. De donkerste delen en de lichtste delen uit het negatief zijn toch moeilijk te bepalen met zo'n klein sensortje. Daarbij zit het ding op een wat ongunstige plaats vlak naast een potmeter en half afgeschermd door een topboardje (nou ja, zeg maar een tobboardje ). Daar moet denk ik toch een wat geavanceerdere, off-PCB oplossing voor komen met een soort diffusortje erboven.

Dat hoor ik van meerdere mensen, het eerste doel zal dus zijn het zoeken van een goede meetsensor, 's ff marktplaats afstruinen op zoek naar defecte dokatimer

Anyway, gisteren nog even rondgesnuffeld op een oude harde schijf. Helaas zijn de repositories van het versiebeheerssysteem die daar op staan beschadigd en wat ik nog op mijn "nieuwe" systeem terug kan vinden is eigenlijk niet meer dan een handvol drivers. De applicatie was gelukkig niet zo bijster ingewikkeld.

SCCS / CSV / of clearcase ('t laatste hoop ik niet ;-) ) Jammer dat de applicatie niet meer te vinden is, aangezien ik eerst wil prutsen op een PC en voor Linux de meeste drivers wel te vinden zijn.

Wat voor ervaring heb je? Ik kan maandag de schema's wel even beschikbaar maken denk ik en wellicht de software ook wel - maar heb je een M16C ontwikkelkit ter beschikking? Ik gebruik de TASKING M16C ontwikkelomgeving (da's mijn werkgever, vandaar ), maar porteren naar de originele Mitsubishi omgeving moet niet al te ingewikkeld zijn (behalve het dresseren van de linker/locator wellicht).

Meer ervaring op PC/SUN basis dan echt embedded (alhoewel mijn baas 't 't liefst embedded noemt). Daarnaast het standaard gebeuren, vooral C en assembly.

Prototypen op een PC zie ik niet zo zitten in dit geval - het meeste werk is toch bitgeneuzel in de drivers.

Jammer, vooral wanneer je een Linux omgeving hebt kun je het on the fly aanpassen, matlab er achter voor 't rekenwerk, grafische userinterface er bovenop en wanneer het werkt de boel omzetten naar een ander platform.

Maar eerst de hardware even regelen. Maar ik ben zeker benieuw naar de applicatie, wanneer je die nog boven water kunt halen.

Groeten.

[jev]

SCCS / CSV / of clearcase ('t laatste hoop ik niet ;-) ) Jammer dat de applicatie niet meer te vinden is, aangezien ik eerst wil prutsen op een PC en voor Linux de meeste drivers wel te vinden zijn.

PVCS... Overigens gebruiken we na de laatste overname 3 verschillende systemen naast elkaar op de zaak: PVCS, SCCS (met een laagje erbovenop genaamd WBCS) en StarTeam. Hoog tijd om te standaardiseren en ik denk dat we binnen afzienbare tijd overgaan op subversion (veeeeel werk - we hebben een enorm ver doorgevoerde fabrikage omgeving te porteren...).

Jammer, vooral wanneer je een Linux omgeving hebt kun je het on the fly aanpassen, matlab er achter voor 't rekenwerk, grafische userinterface er bovenop en wanneer het werkt de boel omzetten naar een ander platform.

Ach, dat maakt mij allemaal niet uit. Sommigen werken nou eenmaal 't liefst in een luxe omgeving, anderen prefereren "bare metal". Voor dit soort toepasinkjes ga ik liever niet voor een PC port - het leeuwendeel van het werk zit 'm in de drivers. Er komt geen multithreading aan te pas en de software is uiteindelijk klein. Met de moderne ROM monitor, ICE en/of OCDS oplossingen maakt het voor het debuggen ook geen moer meer uit.

Ik ga nog eens op zoek in de oude backup tapes en zal morgen iig even de hardware die ik nu heb beschikbaar maken.