Nok engang har jeg tatt en titt i bildearkivet og gravd frem noen bilder, denne gangen fra en varm sommerdag i 2009. Disse bildene er tatt på Sandvesanden og Skudeneshavn.
Og når man først er i gang, hvorfor ikke ta bilde av at et bilde blir tatt?
Jeg har tatt et dykk i arkivet og sett om det er noen bilder der som tåler dagens lys. Eller i dette tilfelle, litt kveldssol. Alle bildene er tatt rundt Stakkestadvatnet i Tysvær.
Det er spesielt en ting som slår meg med dette bildet. Og det er forhåpenligvis noe du ikke kan se nå lenger. Dette bilde ble tatt før jeg gikk til anskaffelse av sensorrens. Bilde var full av små flekker, og med det så mener jeg en plass mellom 50 og 60 større og mindre støvflekker.
Her er en litt annen komposisjon fra omtrent samme sted men litt tidligere på kvelden.
Og enda litt tidligere, rundt 15 minutter før de to øverste, tok jeg dette.
Kanskje jeg skulle tatt en kveldstur der igjen. Det er noen år siden sist.
A few years ago I bought two Yongnuo RF-602 RX receivers and a Yongnuo RF-600 TX transmitter for my Canon flash units. Recently they started misbehaving. Sometimes the flash didn’t fire, sometimes it fired to late. When using the test button however, the transmitter worked fine. What I noticed was that the green light on the front of the transmitter was flashing more or less continuously (when connected to a camera and the camera was on).
The green light is supposed to light up when the shutter button is half-pressed, and I assume it sends a signal to the receivers to wake up the flash. I also suspect that this behaviour, where the green light is on for no apparent reason, is “jamming” the other signal.
If you have this problem, the easiest way to verify is to block all the pins on the hot shoe except the one in the middle, which is transmitting the trigger signal. I used a thin piece of plastic to test this. This silenced the false signal and allowed the real trigger signal to function.
The more permanent solution is to open up the RF-600TX and remove the wiring to the offending pin. The unit has 3 wires. One for the trigger signal, in my case the wire in the middle, one wire for the base of the hot shoe, let us call it ground, and a third wire going to one of the other pins. This will vary depending if you have the Canon or the Nikon model.
Figure out which wire goes to the center pin, and which goes to the ground. Cut the third wire. Or take a soldering iron and gently remove it, in case you want to reattach it. That is what I did. To figure out what’s what I used a multimeter.
By the way, this might slow down the sync speed. But in my case it never worked with anything higher then 1/160 anyways…
Update: I just thought about this. To wake up the flash unit(s) you can half-press the test button instead of the shutter button. Or just force the flash units from going into sleep mode.
The image in this blog post is from OzAdr1an on Flickr and has been modified.
A few months ago I started tinkering with an old DOS-based game trying to figure out its internal data structure. Progress was good in the beginning, and I was quickly able to alter the saved game to give myself some advantages.
Long story short, after a while I needed to figure out how the game handled a particular part of the savegame, since I couldn’t figure it out using a hex editor. But since the game was using a DOS extender, also known as DOS/4GW, loading it directly into Ida Pro Free wouldn’t help. It only gave meaningless garbage in return.
I found the open source DOS extender DOS/32. This has a utility known as SUNSYS Bind Utility which can be used to “Unbind and discard existing Extender/Stub from LE/LX/LC executable” as it says in the documentation.
Place the utility, along with the executable in question, in the same directory and fire up Dosbox (or the real thing) and enter the following command.
SB /U filename.exe
This will produce a unbinded file which can be loaded directly into Ida Pro Free. In my case I ended up with a file ending in .LE, which stands for “Linear Executable”.
Hopefully this can help others who want to peak into old DOS games.
Hvor mange bilder har du tatt totalt, hvor mange har du slettet? Hvor mange bilder tar du før du sitter igjen med det ene gode?
Under Haugesund Triatlon tok jeg litt over tusen bilder. Siden dette er et arrangement med mye action og bevegelse så sier det seg nesten selv at ikke alle var verdt å ta vare på. Men så slo en tanke meg; hvor lenge kan jeg regne med at kamerat holder ut?
Jeg har et orginalt Canon 5D. Det nærmer seg 10 år gammelt, og det er ingen hemmelighet at et speilreflekskamera før eller siden vil svikte. Canon oppgir at 5D sin lukker (shutter) til å holde ut sånn cirka 100.000 bilder. Mitt første speilrefleks, Canon 350D, kun 50.000.
Begge disse kamerane mangler en teller som holder styr på hvor mange bilder som er tatt totalt, på nyere kamera så er dette informasjon som er lett å få fatt i. Men så fikk jeg en tanke. Alle bildene jeg har tatt vare på ligger ganske godt organisert. Kamera tar bilde med løpenummer fra 0000 (eller 0001?) til 9999. Så hvis jeg leser inn alle filene jeg har i kronologisk rekkefølge, og fyller hullene og tar høyde for filer som passerer 0-punktet. Ja, da har jeg vel ett tall som ikke burde være så langt unna sannheten? Det blir ikke helt perfekt, men mye bedre enn ingenting.
Siden alle bildene lå i en grei katalogstruktur med “{år}/{år}-{måned}-{dag}/ {filnavn}”, så var det en enkel sak å hente ut filnavnene i kronologisk rekkefølge:
E:\> dir /b/s/l/o:gnd Lightroom > filer.txt
Den kommandoen gjør følgende:
/b – lister kun filene, ingen metainformasjon som størrelse, dato, e.l.
/s – viser filer i katalogen kommandoen kjøres mot og alle underkataloger.
/l – skriver ut listen kun med små bokstaver (“IMG” blir til “img”).
/o:gnd – lister i sortert ordre etter (g) katalog (n) navn på fil og (d) dato, eldste først.
Den siste kunne jeg ha spart meg siden filene allerede lå sortert i katalogstrukturen. Jeg har kjørt kommandoen i ettertid uten sortering på dato og det har ikke endret resultatet.
Etter denne kommandoen endte jeg opp med en liste på 77.057 linjer. Ikke alle filene var bildefiler, men disse kunne enkelt sorteres bort ved å filtrere ut kun linjer som sluttet på .cr2. Canons proprietære filformat for rå-filer. Da endte jeg opp med en liste på “kun” 26.257 filer.
Ett annet problem var at listen inneholdt både filer fra 5D og fra 350D kameraene. Her tenkte jeg først å sortere på størrelse, siden 5D har en mye større sensor og dermed også produserer større filer. Et greit skille her ville vært på 10MB, alt under var 350D alt over 5D. Men så oppdaget jeg at 350Den laget filer som het “img_{nummer}.cr2”, mens 5D hadde byttet ut den første karakteren med en underscore. Lykketreff! Å spørre filesystemetet etter størrelsen for hver enkelt fil ville tatt mye lengre tid enn å kun filtrere på filnavnet.
Med denne informasjonen lagte jeg et lite python-script som tok for seg listen, registrerte alle filene den fant og fylte inn hullene. Når en fil var 9976 og den neste 0019, så tok den ganske enkelt 9999 – 9976 og la dette sammen med 19. Denne fremgangsmåten virker fint så lenge det ikke mangler 10.000 sammenhengede filer, noe som er lite trolig.
Første gang brukte jeg den første fila den fant som utgangspunkt, men siden kamera nesten er nødt til å ha tatt bilde nummer èn så fyller den nå ut hullet mellom første fil den finner og 1.
Resultatet ble da som følger:
Canon 5D Found: 12262 (18.69%) Lost : 53336 (81.30%) Total: 65598
Canon 350D Found: 13995 (20.23%) Lost : 55169 (79.76%) Total: 69164
Det som er interessant her, bortsett fra at 350en ser ut til å ha gått over de 50.000, er hvor jevnt det er mellom antall bilder som er beholdt og antall bilder som er slettet på de respektive kamerane.
Jeg skal ikke påstå at hvert 5. bilde er et gullkorn, men det ser ut til å være den magiske grensen mellom hva som jeg anser som brukbart og hva som er totalt ubrukelig.