Marat S writes:
Does your sample have aperture slightly closed when set to f2? It causes nonagonal shapes of OOF point light sources especially noticeable when focusing up-close and seems to be common among early Batis 40mm samples.
I know one person who contacted Zeiss about this issue as soon as first images surfaced after Photokina, but they haven't told him whether it's normal. I really hope it's not.
Eyal O writes:
I’m glad to see that you have the Zeiss Batis 40mm f/2 CF in hand and are actively testing it. I’ve been scouring the web for info/images and am really looking forward to your thoughts/review. One thing that has been noticed over on Fred Miranda’s forum is the tendency for the camera to render background lights in a stop-sign pattern when used for close focus at f/2. It is unclear if this is:
1. An issue with very early copies
2. An issue only when using the close focus
3. An issue at all distances
DIGLLOYD: Similar to the Hasselblad XCD 90mm f/2, the Zeiss Batis 40mm f/2 CF wide open at f/2 does not show circular bokeh on out of focus highlights. This appears to be as designed. I have an inquiry into Zeiss.
Further insight below—the apparent diameter of the diaphragm can be seen to change with focus distance.
Zeiss Batis 40mm f/2 specular highlight bokeh at f/2
f2 @ 1/800 sec, ISO 100; 2018-10-22 12:02:36[low-res image for bot]
Sony A7R III + Zeiss Batis 40mm f/2 CF
Infinity focus versus close focus
Toggle the image below to compare. As the Zeiss Batis 40mm f/2 CF is focused closer, the apparent size of the diaphragm opening contracts. Hence at everything but infinity, the background out-of-focus bokeh wide open at f/2 will show the nonagonal shape of the lens diaphragm.
I determined that there is a two stop difference in exposure for focus at MOD vs focus at INF. I used an even gray material and then manually focused at INF then manually focused at MOD. This is good and bad: it is good in that it looks like Zeiss is not using the trick (very common) of shortening the focal length in order to maintain aperture. The bad is that the lens becomes f/4 at MOD. This is consistent with the size of the lens diaphragm seen below, well stopped down when the shooting aperture is f/2.
This is kind of crazy: near MOD, the lens diaphragm is stopped well down even as the shooting aperture on the camera is f/2! That explains the light loss, but it does not explain why it is stopped down in the first place.
MOD = Minimum Object Distance e.g., very close focus
INF = infinity focus
Zeiss Batis 40mm f/2: toggle to see infinity focus vs close focus
UPDATE and success: several very helpful readers helped me debug the issue—many thanks.
Not only should GMail (or any other mail server) not mark mail as junk, it also does SPF=PASS, which is an improvement over before where it was neither yeah nor nay.
This is for the nerds out there like me who run their own mail server—the desired thing to see in the headers is this:
Received-SPF: pass (google.com: domain of ****@diglloyd.com designates 184.108.40.206 as permitted sender) client-ip=220.127.116.11
The TXT record (SPF) turned out to be trivial since I use only one IP for email:
diglloyd.com v=spf1 ip4:18.104.22.168 -all
I always reply to courteous and appropriate emails.
In the past week, I’ve responded to half a dozen readers asking why no reply. There my response sits in the GMail JUNK folder, which all of these readers confirmed. I’ve had to resort to multiple different email accounts in order to get through (e.g., diglloyd.com, me.com, etc).
Please check your junk folder if you do not receive a reply, GMail or otherwise (Earthlink.net is the very worst of all).
This is a behavioral change apparently brought on by something over at Google. As far as I can determine, I have all my DNS and DNS-related records correct. I have no idea how I could get Google to keep its aggressive algorithm from junking my messages.
Invalid email address at PayPal
Sometimes readers/subscribers use bad emails even when subscribing, not checking if the email at PayPal is even valid. I have no way to contact these users—none at all since PayPal does not supply that kind of contact info in most cases—so I am helpless in that situation.
Email address that just doesn’t work
Sometimes the email is at a server that doesn’t even function, sometimes the server says “email box full”, etc. Example:
The following message could not be delivered to ****@earthling.net at host earthling.net (22.214.171.124) because the host is not accepting mail.
The following message could not be delivered to ******@gmx.info at host gmx.info (126.96.36.199) because the host is not accepting mail. 554-gmx.net (mxgmx116) Nemesis ESMTP Service not available
After 3 days the following message could not be delivered to *****@suddenlink.net at host suddenlink.net (188.8.131.52). The last attempt to send this message failed because the message was temporarily rejected. 421 dalifep02.suddenlink.net connection refused from [184.108.40.206]
DM3NAM03FT018.mail.protection.outlook.com rejected your message to the following e-mail addresses: *******@autonation.mail.onmicrosoft.com DM3NAM03FT018.mail.protection.outlook.com gave this error: Hop count exceeded - possible mail loop
The following message could not be delivered to ****@optonline.net at host optonline.net (220.127.116.11) because the sender address was rejected. 550 5.7.1 Unacceptable hostname 173-164-178-42-SFBA.hfc.comcastbusiness.net from host 18.104.22.168 : denied - 01 Reporting-MTA: dns; llc4.com
This last example is annoying: optonline.net clearly recognizes DNS as llc4.com (which is also diglloyd.com), yet it refuses the email. I’ve put in place DNS records, but either I’ve got it wrong, or some email servers do not check things like TXT records for email servers, e.g.:
smtp.diglloyd.com v=spf1 +mx +a -all
It is my understanding that this TXT record should make most mail servers happy. Maybe someone network nerd out there can help me figure this out. It’s not like smtp.diglloyd.com is unavailable on DNS:
diglloyd-iMac:DIGLLOYD lloyd$ ping smtp.diglloyd.com PING smtp.diglloyd.com (22.214.171.124): 56 data bytes