Sorry for the confusion. What I’m getting at is not the sensor as a stand-alone thing, but the light meter as a whole - including the display. Dedicated, handheld light meters usually have a swivel mounted sensor, so you can point the sensor in the right direction while keeping the display conveniently visible.
In general photography, it may just be a convenience and with at fixed sensor you could just turn around to change the sensor’s direction. This doesn’t work e.g. on a copy stand, as the display will then face the base board.
Having a button on the TOH to trigger measurement would help with this, but I think it would be more convenient to see the readout while measuring.
They are the same, except for one important difference. For incident light, you add a diffusing dome or disc over the sensor.
I’m afraid I don’t follow. How can ways to convey colour be irrelevant when colour is highly relevant? (RGB/CMY is needed for printing in analogue colour photography.)
The joy of feature creep ! Take your time, I’d say, and focus on your own needs first.
Make a mockup to check that the sensor isn’t covered when you hold the phone in different ways and that buttons (if you want any) are in convenient places.
Browse the data sheets for the various sensors that have been suggested in the thread. Check their spectral sensitivity, some may not be fit for purpose. Are they easy to interface with, hardware and software wise? Any calibration needed?
You may find that sensors of the same family are almost drop-in replacements for each other, meaning that electric connections and software control is similar. In that case, you could pick a more complex sensor even for a simple task. You, or someone else, would have the possibility to add more functions in software later.
Or, you may find a sensor that makes your task so much easier if you settle for the simple use case you had in mind.
Ah, now I understand. You want a TOH with the same hardware features as a conventional light/exposure meter. That’s legitimate. For my own use case however, I want it to be merely an additional feature of my daily-driven Jolla Phone, which means that any protruding parts which cannot be removed are a no-go for me. Rather something like this:
The sensor sits in the TOH shell and sees the light shining on the back side of the phone through a proper hole.
When not in use, its covered with a flat cap (probably a magnetic one), which is aligned flush with the rest of the shell.
When I want to use it, I just remove this cap and optionally place a diffusing dome or diffusing disc over the sensor (held by magnets).
When finished, I remove these attachments and put the flat protective cap back.
Are you worried, that the light emitted by the display will influence your measurement? In such a case the software (app) can be programmed to switch off the display before starting the measurement and switch it back on after the measurement is finished. This however would not work for continuous measurements. For such cases, I guess, you really need a swivel mechanism for the sensor.
It again makes a difference if gated or continuous measurements are required. For gated measurements, being able to immediately see the result just adds convenience. For continuous measurements however, it is a requirement.
True. I just didn’t want to go that deep into details here.
When I wrote that RGB and CMY are not relevant in analogue photography, I was referring to the purely analogue side of things - from the camera to the darkroom, but no further. In this realm, we are not thinking in RGB, CMY and friends, but in wavelengths and chemical compositions of our film emulsions and the liquids we use in the darkroom to process the exposed film and subsequently create enlarged prints on photosensitive paper from it, which does not require any digitization.
@munkstolen: I fully support what jojomen wrote in their reply to you. Don’t try to be a people pleaser. That will just end in misery for your feelings and motivation. Always remember: You are doing this project for no one else but yourself. If you decide at some point to publish your work and it inspires other people to do the same or something similar for their specific use case, congratulations!
No one shall expect from you to design anything according to just their specific likes. As we say in the free and open-source software scene: “Scratch your own itch.”
If anyone really wants a board like this, I can make it MUCH smaller and skip the ‘qwiic’ nonsense and just make the SDA/SDL pins available which is what you need. The sparkfun module is huge.
I know. However, such modules greatly lower the barrier for hobby TOH developers who just want to scratch their own itch. You don’t need to design anything in KiCad and friends, you don’t need to order any raw boards with your design from some manufacturer, you don’t need SMD soldering skills, but just through-hole soldering skills, which are much less challenging.
Sure, seasoned electronic developers will understandably go for more integrated, self-designed solutions, but that’s not the point here.
I’m actually saying that if there is interest, I’ll make the boards. The cost per board would be about 3 -4 euros (with taxes and tolls) with the main cost being shipping. EDIT: I order boards constantly so I can squeeze this in on another project to reduce costs.
Still waiting for https://github.com/sailfishos/symbiosis to come back It’s still unclear to me how the daemon works. The design looks like it will require an mcu for the I2C interface itself (or something from nxp).
I think you are correct. I3C is only partly backwards-compatible to I2C. For example: I2C clock-stretching is not allowed anymore on I3C as far as I know. A TOH base/identification board would thus have to provide 2 SCL and 2 SDA ports: 1 pair for connecting I3C peripherals and another pair with a buffer IC (and eventually pull-up resistors) inbetween for connecting I2C peripherals.
Yeah, we’re looking at different use cases. I actually just want a subset of what my handheld meter does, but eventually with the possibility to integrate it with other stuff via the phone. (I turn out to be bad at manually taking notes.)
I’m worried that I won’t be able to see the display with the meter laying sensor up on the base board of a copy stand or enlarger. But display light affecting metered values would also be bad, so measuring with display off makes sense. Good point!
Completely with you on this one, as I’m aiming for (edit: colour) prints rather than pixels. It’s just that it’s tedious to get the right exposure and correction filters by trial and error. I hope measuring RGB/CMY could provide a little help with that.
Maybe it could also be of use with mixed lighting, daylight of some kind plus an LED panel with adjustable colour temperature.
As you know, we’re interested in nanometers (wavelengths) in analogue photography, not RGB or CMY triplets.
I wonder: If you shine monochromatic light or at least light with a very narrow bandwidth onto a RGB sensor, can you somehow calculate the actual wavelength in nanometer of this light from the separate RGB values? You would at least also have to take the colourspace into account for which the sensor was calibrated (sRGB, Adobe RGB, and so on). Otherwise, the 3 plain values of the R, G and B part mean nothing.
Edit: Why take the complicated route, when you can determine the actual wavelength apparently much easier:
An auxiliary display would indeed make sense for my use .
Filtration in the colour head is still CMY (to cut out RGB respectively). Ideally, the RGB channels of the sensor would have their peak sensitivity wavelengths match those of the photo paper (or maybe those of the filters). Not sure I can count on that, so some experimentation will be needed.
My intuition says no, you can’t.
I haven’t checked the data sheets, but I guess the RGB channels have very little spectral overlap. (Unlike the eye.) So monochrome light will only excite one of those detectors. You will thus get a reading that is the product of the unknown light intensity and the unknown relative sensitivity of that detector at that wavelength.
You could get half an answer if you also have a wide-band detector to measure total intensity from the light source and you know the relative sensitivity vs. wavelength of the other channels.
I.e. say R intensity/W intensity is 0.6 and you know at what wavelength R sensitivity is 0.6 you would be close - but of course the sensitivity curve has two shoulders and I can’t come up with a trick to find out on which side of the peak this is…
Now, it would be good news if the RGB channels are in fact overlapping, because the channel that gives you a low reading would tell you on which side of the peak the wavelength. You might even be able to use the two values and the corresponding sensitivity curves to get a better estimate of the wavelength.
Of course, all this only works if you know the light to be monochrome and no other light is disturbing measurement. And I think this might be as far off-topic as we should stray here .
The AS7265x sensors give you not only 3 discrete curves which may or may not overlap, they give you 18 overlapping curves if you use the entire set. Check out their datasheet here.
Well, in this case it’s a discrete task that, unlike software, once it’s done, it’d done There is a satisfaction in that. It’s why I make hardware stuff, to come down from the constant struggle with software…
I was disappointed that this was not a 620 roll film back, twin lens reflex, with bellows to keep the low profile expected of today’s most advanced phone cameras.
! Take your time, I’d say, and focus on your own needs first.
It’s still unclear to me how the daemon works. The design looks like it will require an mcu for the I2C interface itself (or something from nxp).
You could add an additional display to the TOH in this case, such as