View Full Version : Doka belichtingmeter.
Wanneer ik (als embedded software developer) naar zo'n lichtmeter als de http://www.rhdesigns.co.uk/darkroom/html/splitgrade.html kijkt, zie ik een kassie, met een relais, microprocessortje , lichtgevoelig elementje, wat knoppies en een display.
(Sorrie wanneer dit wat degenererend overkomt :-) )
Wetende dat er hier heel wat software developers rondlopen, komt de vraag in me op of iemand er al een keer aan gedacht heeft om zelf zo'n ding te maken. Of kijk ik er op dit moment iets te simpel tegenaan.
Ik kan met voorstellen dat de achterliggende theorie (voor het bepalen van de gradatie / belichtingstijd) wat complexer is dan ik me voor kan stellen. (Heeft iemand toevallig nog wat documentatie over liggen ?? ).
Of hebben we te maken met toch wat exotische hardware (lichtgevoelig element wat moeilijk te koop is ?).
Al met al, 't lijkt me wel een keer leuk om te brainstormen of 't mogelijk is om zo'n ding zelf te maken.
(Eerst een PC prototype, en daarna de software omgieten naar een embedded processor.)
Groeten.
Johan.
Ach so, een collega krasser ;). Ja, ik heb al eens met het idee gespeeld om iets dergelijks zelf in elkaar te schroeven en zelfs al eens wat software geschreven daarvoor. Een en ander op een Mitsubishi ^W Renesas M16C op basis van een oud bordje waar toevallig een lichtgevoelig elementje op beschikbaar was. Wegens gebrek aan tijd heb ik 't nooit afgemaakt maar de restanten kan ik misschien nog wel ergens terugvinden.
In theorie voor ingenieurs als jullie wellicht eenvoudig.
Alleen: splitgrade is ook elke vergroter uitrusten met de splitgrade automatiek om maar nog te zwijgen over de calibraties van de diverse papiersoorten.
Bovendien, waarom iets maken dat slechts hetzelfde doet dan een bestaand systeem?
Een stap verder zou zijn een splitgrade die rekening houd met niet twee uiterste metingen maar met bvb een honderdtal (snelle) metingen van je negatief.
mvrgr
Fred
Fotohuis
03-11-2005, 10:42 AM
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 -
argentic
03-11-2005, 12:35 PM
Wanneer ik (als embedded software developer) naar zo'n lichtmeter als de http://www.rhdesigns.co.uk/darkroom/html/splitgrade.html kijkt, zie ik een kassie, met een relais, microprocessortje , lichtgevoelig elementje, wat knoppies en een display.
Wetende dat er hier heel wat software developers rondlopen, komt de vraag in me op of iemand er al een keer aan gedacht heeft om zelf zo'n ding te maken. Of kijk ik er op dit moment iets te simpel tegenaan.
Het goede van dit soort analysers is niet zozeer de electronica of de eprom. Het is de filosofie gebaseerd op jarenlange praktijkervaring en heel veel calibreringstesten die zulke apparaten zo waardevol maken.
Natuurlijk, om een dergelijk apparaat 100% te maken heb je een hoop achtergrondkennis nodig. En ja, je kunt 'm kant en klaar kopen. Maar ja, kijk eens naar die prijzen...
Een simpel dingetje is best te maken. De vraag is hoe bruikbaar het eindresultaat zou worden en ik denk dat je met wat eenvoudige callibratie best een aardig resultaat kunt bereiken.
Enne... een EPROM? Achterhaald, nergens voor nodig ;). Een beetje moderne controller heeft voldoende flash geheugen aan boord - de M16C die ik noemde heeft maar liefst 256 kB flash en 20 kB RAM on chip... Als ik de tijd kan vinden om 'm af te maken laat ik nog wel eens weten hoe bruikbaar zoiets is in een simpele vorm.
PieterB
03-11-2005, 01:27 PM
mja software schrijven wordt steeds eenvoudiger. Ik ken niets van embedded systemen, maar 'normaal' programmeren is met talen zoals python en c# een makkie geworden....
Ik denk dat het grote probleem het ongeloofelijk aantal variabelen zijn, waarvoor je al héél lang ervaring moet hebben om deze goed op elkaar af te stemmen....
argentic
03-11-2005, 01:44 PM
Natuurlijk, om een dergelijk apparaat 100% te maken heb je een hoop achtergrondkennis nodig. En ja, je kunt 'm kant en klaar kopen. Maar ja, kijk eens naar die prijzen...
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.
Ach so, een collega krasser ;). Ja, ik heb al eens met het idee gespeeld om iets dergelijks zelf in elkaar te schroeven en zelfs al eens wat software geschreven daarvoor. Een en ander op een Mitsubishi ^W Renesas M16C op basis van een oud bordje waar toevallig een lichtgevoelig elementje op beschikbaar was. Wegens gebrek aan tijd heb ik 't nooit afgemaakt maar de restanten kan ik misschien nog wel ergens terugvinden.
H'mm, de uitdrukking krasser heb ik nog nooit gehoord, bitneuker wel :-)
Wat waren je bevindingen, den k je dat 't iets bruikbaars zou kunnen worden ?
Groeten.
In theorie voor ingenieurs als jullie wellicht eenvoudig.
Alleen: splitgrade is ook elke vergroter uitrusten met de splitgrade automatiek om maar nog te zwijgen over de calibraties van de diverse papiersoorten.
Bovendien, waarom iets maken dat slechts hetzelfde doet dan een bestaand systeem?
Een stap verder zou zijn een splitgrade die rekening houd met niet twee uiterste metingen maar met bvb een honderdtal (snelle) metingen van je negatief.
mvrgr
Fred
Het ging me er eigenlijk alleen om om een belichtingsmeter te maken die tijd en gradatie aangeeft voor de twee soorten papier die ik gebruik. Niet om ook nog een splitgrade automatiek aan te sturen (zou natuurlijk ook wel leuk zijn ;-) ).Om eerlijk te zijn heb ik gewoon bij willekeur een link naar zo'n kastje gepakt, ik had de inhoud van de pagina ook nog even moeten lezen.
Waarom iets maken ? Software kost me geen geld, alleen de hardware, dus op PC basis zou het erg goedkoop kunnen krijgen. Daarnaast ben ik een beetje een control freak en wil ook altijd precies kunnen voorspellen wat zo'n apparaat doet, en met zo'n kastje denk ik dat ik al snel wat extra wensen heb die ik niet voor elkaar kan krijgen met zo'n kastje.
Wanneer je zit te denken aan honderden metingen, zit ik zelf al snel te denken aan een negatief scanner. Zou het in principe niet mogelijk zijn om met een negatief scanner ook de belichtingstijd en gradatie te bepalen ?
PieterB
03-12-2005, 02:14 AM
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 ;-)
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.
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.
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
03-14-2005, 05:57 AM
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
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.
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.