You’re basically saying that FastRawViewer is misrepresenting the data and cannot export a JPEG of that size. That’s wrong. It’s not reporting bogus numbers, it’s actually displaying the extra pixels (and yes you can see the difference with the vendor’s recommended crop shown in PhotoLab, especially when you have some objects in the frame near the edges). Being able to export a JPEG is irrelevant.
ApolloOne and Affinity 3 both report the larger size, display extra pixels in the same way that FastRawViewer does, and export JPEGs with the larger size.
Why are you so resistant to the idea that sensors and RAW files can have a bit more pixels than what vendors advertise in their camera specifications? It’s empirically true in my tests, and @Wlodek has provided a rationale for these extra pixels. Going “nuh-uh, the camera’s specifications say X” is a bit tiring. Camera specs are often limited and routinely gloss over technical details.
There are more cameras where the number of ‘pixels’ reported by the sensor is bigger than what’s in the jpg files or the manufacturer raw files. Maybe this has been asked already, but what does Adobe Report as the size ?
Fastrawviewer and other tools like that (not only based on libraw , but other ‘diagnostic’ tools for raw files report all the pixels really in the file.
The question is, are they usable. This might siffer camera to camera. There is a reason why the manufacturer is claiming the outer edges do not count, but why, only they know.
Maybe this helps in yields from sensors , maybe this is what their ?microlens array supports (and you might be lucky or unlucky). Maybe it’s there for extra demosaicing info, or for stabilisers or anything else , I don’t know.
Two of my Sony 24mp cameras have the same. Camera says it’s 6000x4000, Adobe says 6000x4000, dxo says 6000x4000 but it’s a really something like 6024x4020 in the file (been a long time, don’t know the exact res).
In the metadata of the raw files is often even cropping data, basically telling tools what parts of the sensor to cut off.
So, it’s not DxO. And what it’s reporting is camera spec. Means that you found a little bonus hiding away in your raw files , and if you want to toy with it , you have to get your hands dirty.
DxO (and this is true of all common demosaicing tools) uses the manufacturer’s “official” sensor size. This size is indicated in the metadata and is smaller than the actual sensor size. In no case (at least not that I’ve been able to verify) is the edge portion used. I don’t know the reason, but there must be one! It could be, as already mentioned, the need for additional photosites to calculate the RGB values at the image edges. Just a guess.
I’ll take the example of a Sony sensor with 42.4 effective megapixels. This is the sensor’s nominal and usable size. But it’s slightly larger, at 43.6 megapixels (Sony data).
The sensor’s usable size is 7952 x 5183, corresponding to the 42.4 megapixels.
During distortion correction, the actual usable image size decreases. In my example, given the type of correction (barrel or pincushion), the remaining resolution is, for instance, 7771 x 5183. We can either choose not to constrain the image, in which case we keep 7771 x 5183, or we can choose to constrain the image, and it will be resized to match the nominal image size: 7952 x 5183. We can also choose not to maintain the original aspect ratio, and we gain a few pixels: 7773 x 5183. However, this gain (when it exists) is highly variable because it depends primarily on the lens and its correction.