# First build, High-Res v7 (#969fc80) with v3-alpha-server

**URL:** <https://openflexure.discourse.group/t/first-build-high-res-v7-969fc80-with-v3-alpha-server/2169>\
**Category:** Build Reports\
**Created:** [20 June 2025 21:45 UTC](https://openflexure.discourse.group/t/first-build-high-res-v7-969fc80-with-v3-alpha-server/2169 "2025-06-20T21:45:16Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![zeus](https://yyz2.discourse-cdn.com/free1/user_avatar/openflexure.discourse.group/zeus/32/2444_2.png) [@zeus](https://openflexure.discourse.group/u/zeus)\
**Post date:** [21 June 2025 09:35 UTC](https://openflexure.discourse.group/t/first-build-high-res-v7-969fc80-with-v3-alpha-server/2169/4 "2025-06-21T09:35:58Z")

</div>

> [@WilliamW](#):
>
> This is actually a loss in colour saturation at the edge of the sensor. It is caused by a lenslet array that is slightly offset from the pixels at the edge because it is expecting light to be coming at a large angle from the short focal length lens.
> 
> This is explained in [Flat-Field and Colour Correction for the Raspberry Pi Camera Module | Journal of Open Hardware](http://doi.org/10.5334/joh.20) . The colour mixing can be measured, and then the reverse tranformation applied to images will correct most of the problem. It is particularly noticeable for redish samples, which unfortunately includes h&e stained histology slides.

This actually makes alot of sense, and is the missing puzzle-piece in understanding, where this comes from, thank you very much. I already tought of the effect looking like a vignette that is present not evenly, but different depending of the color-channel, and already thought “that would have to be corrected before stitching to be beneficial”, but I did not get, that the auto-calibration already takes care of it. I did not mind to color-correct for this effect in particular, and my last color calibration was on a non-HE-sample, which might explain alot.

> [@WilliamW](#):
>
> Note this is not the case for the HQ camera, which is not optimised for a particular standard lens. I don’t know whether it has lenslets at all. I noticed your Printable. How did you use the OFM software with the HQ camera? The standard v2 and v3 server software are both tied to the Pi Camera v2.

This also explains alot xD.  
The linked printables-thingy from my wife is indeed using another camera-module, and it is indeed the HQ-Cam, just with a C-/CS-Mount. It is [this one](https://datasheets.raspberrypi.com/hq-camera/hq-camera-product-brief.pdf) and uses a Sony IMX477R as sensor (12MP). In this configuration it has no lens, at all, just the bare sensor, hard to say if it is using lenslets, but I did not noticed any vignetting at all, and this version is intended to be used with external objectives anyways (hence the C-/CS-Mount). There we used a standard-eyepiece-adapter to fit a regular Olympus CH-A Microscope (and - not seen in that printable - with a different-diameter-eyepiece-adapter on an Olympus VM-T stereo-microscope as well, which also works fine, even tough for 3d-objects some halo-ing is to be expected…). **This actually worked out of the box**. I noticed a somewhat smaller FoV (it looks to me like a higher (narrower) focal-lenght, maybe the eyepiece-adapter is correcting for a different (shorter) length of the optical tube), resulting in a smaller image-circle (at least it seems to me that you have a significant smaller image-circle as with just the eyepiece).

The second noteworthy difference was, that OFM’S color-correction is _way off_ what the picture actually should look like. Flat-field is okay and even, just white-balance (and gain to some degree) is completely off, giving a very teal image most of the time. However, for now I manually color-calibrated the Camera with grey things and noted down the values to be at least be always roughly at the right ballpark (unfortunately I don’t have a translucent grey-card…does something like that even exist? anyways, I digress…). Correcting for WB/Color is however not a big deal anyways, even afterwards in post-processing. As you can see in the Images in that Printables-Thing, The images produced by the cam are at least “okay” out of the Box for different objectives. Those are not post-processed or afterwards color-corrected, just the radiolaria-image was raw-processed (changed to B/W, some basic RAW-processing like sharpening, curves and contrast as well as some maunal “de-dusting” in GIMP for aesthetical reasons).  
So beside automatic color- gain- and wb-correction the HQ-cam does work actually fine with all tested RMS-Objectives, some of them HQ-Olympus branded ones (4x,10x,20x,40x), which all produced very useable results. We used the current stable (v2) build on the manual scope. Maybe for “modding purposes” a guideline on how to correct for different camera-models would be helpful, because other than calibration, the HQ-Cam works perfectly fine.

---

_[View the full topic](https://openflexure.discourse.group/t/first-build-high-res-v7-969fc80-with-v3-alpha-server/2169)._
