|
I'm trying to buy a Sigma 70-200 2.8 EX APO II MACRO HSM telephoto lens with a Nikon mount.
The lens can be bought on French sites (like pixmania or missnumerique) at around 1000€ [1] & [2].
You can buy it from B&H at around 800$, if you take into account the euro/dollar rate and the french VAT (20%) it costs 690€ [3]. (There is no other taxes except the VAT applicable when importing this to France)
Why is there such a difference ?
[1] Pixmania price
[2] Missnumerique price
[3] B&H price
I've done some tests today using a ISO-12233 resolution chart.
It confirmed my first impression :
At wide open aperture (1.4), the border resolution is poor and the center suffers of very high pronounced chromatic abberations : high contrast figures are rendered with a purple, yellow or cyan glare that can be as high as 10 pixels.
Stopping down at 2.3 helps : the center is sharp, scratching the resolution of the 10M pixel sensor of the D40x. The border are still soft.
At 5.6 aperture, the center reaches the sweet spot of the lens, the borders are still a bit less sharp, but nothing to worry about.
An aperture of 8 is uniformizing the lens performance everywhere in the picture : however, the resolution of the center (and thus the border) is still a bit under the one of the center when stopped down at 5.6.
At 16, a mild quality drop can be observed in the center as well as in the border.
Vignetting is a non issue when using 2.8 or higher aperture settings.
Yellow/cyan chromatic abberations are present at all aperture settings. But this is generally not a show stopper here.
The lens also shows a quite high barrel distortion (I've nothing to measure this, but it seems high for a standart lens, maybe around 1%).
To conclude, this lens has a bad optical design, this is not a big surprise here as it is a (cheap) russian copy of a regular nikon lens. However russian engineeners have fogotten to include some features in this lens such as multicoated optical elements that would have helped in reducing chromatic abberations, at least at ultra wide aperture settings. Buying a regular 50/1.4 Nikon AI-S lens seems to be a better choice, even if the price of such a lens is a bit higher (>150$ or more for an used one).
I recently bought an Arsat H 50/1.4 lens for my Nikon DSLR. It is a cheap lens (<100$), however it is not really easy to find. Some items can be catched on ebay.
This lens is a soviet copy of the Nikon 50/1.4 standart AI-S lens. The build quality of the lens is not comparable to high quality Nikon lenses. Anyway, the lens is fully made of metal and it feels like a solid rock. the zoom ring is smooth but the aperture ring seems a bit fragile. The engravings indicating the aperture and the focus distance are dumpy. The rubber band of the focus ring is a piece of crap : it is poorly assembled to the focus ring.
At wide open aperture, the lens suffers from excessive chromatic abberations when using it in normal field condition thus resulting in dreamy pictures, especially when using it focused at the infinite. The image below is a 1:1 crop of a shoot at 1.4 focused on infinite :
Stopping down to 2.8 helps a lot :
I've not done strict resolution tests, nonetheless, the center performance seems to be very good from 2.8 to 16, but border performance is only good from 5.6 aperture. At wide open aperture, the border resolution is awful, and the center resolution is not so good : the lens seems to suffers of high diffraction/reflexion in it (as shown in the above image), using it in low contrast and low light condition helps here.
Even if this lens is far for perfect, it is still a very funny lens to use and some good pictures may be produced with it. Here are some sample pictures that demonstrates that a reasonnable level of sharpness can be reached with it :
       
Above pictures have been taken with aperture of 1.4 & 2.8.
Go to the about:config page, search for an entry called gfx.color_management.enabled, if it does not exist, create this entry as a boolean. Then, simply set this to true and restart you're Firefox.
This workaround has been tested successfully on Firefox 3 Beta 4, and may not work with previous versions.
Click on the link below to test if you're browser correctly handles colour profiles. Two different picture have been sent 3 times to flickr using different color spaces (sRVB, Adobe RVB and ProPhoto RVB). If you can see color differences between pictures, you're browser is a piece of crap !
Note that in Safari, all colors are exactly rendered the same way  Thanks to Apple for taking care of beautiful colours on pictures !
The Test Flickr Gallery
What's amazing is that Flickr does not alter the original color space of pictures when resizing them.
If you are a Facebook user, you may have noticed that sometimes, you click on something you thought was a Facebook internal link, but you are redirected to another site. Facebook duped you !
See the picture below, the link is actually an ad with the Facebook CSS style : smart 
While I was uploading pictures from Lightroom to the web (flickr), I used firefox on OS X to preview uploaded galleries and colors of uploaded picture were insipid. I've first suspected Lightroom to create fucked jpeg files, but viewing with another web browser like Safari just shows perfect colors.
It seems that the Mac OS X version of Firefox 2 is not able to apply right color profiles to render jpeg pictures. The screenshot below is self explanatory...
The only workaround is not to use Firefox !
When you have a bunch of tabs open in Firefox, at some point, it starts scrillong horizontally. To disable this behaviour set browser.tabs.tabMinWidth to 0 in the configuration page.
Some times ago, friends of mine was joking about my love for this great thing that emacs is ; saying you have to do unbelieveable key combo to do simple things.
I'm proud to annouce there is a soft with more crazy shortcuts : Adobe Lightroom :
- go to the Library module : Shift+Alt+Apple+1
- go to the Development module : Shift+Alt+Apple+2
- Copy/Paste development parameters : Shift+Apple+C/V
- Copy/Paste metadata : Shift+Alt+Apple+C/V
I'm running my new dynamic_pager during last 3 days, I've not noticed any bad side effects : here is my vm_stats output after 20hours uptime, heavy memory and disk usage :
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free: 67541.
Pages active: 336302.
Pages inactive: 58724.
Pages wired down: 59391.
"Translation faults": 13792984.
Pages copy-on-write: 63882.
Pages zero filled: 12479434.
Pages reactivated: 31.
Pageins: 55306.
Pageouts: 0.
Object cache: 12432 hits of 155686 lookups (7% hit rate)
The kernel does not writes pages to the swap anymore (0 pageouts). The amount of inactive memory used is exceptionnally low for such a high amount of active memory (1312Mb active, 229Mb inactive). The single swap file of 64Mb is not used : I'm owning my Macbook Pro since december 2006 and I only seen this right after a reboot of the system.
I'm not sure everything described above are the result of my dynamic_pager hack, but it damn works !
If like me you cannot deal with the swapping in OS X, and if you have tried everything possible, even not to launch dynamic_pager (and you've seen that you're system is not usable anymore (on my mac the 2Gb was detected but the system was refusing to use more then 1Gb  )), then I have the solution : create another dynamic_pager that fits your needs
Actually, the original source code of dynamic_pager can be found at http://www.opensource.apple.com/darwinsource/10.5.2/system_cmds-433/dynamic_pager.tproj/dynamic_pager.c. You will need an apple developper account (that's free) do download it. If you know how to compile this, please add a comment to this post.
After a bit of hacking, (removing cryptic junk, calls to private code of the kernel that is not accessible for the public, hacks to make it compile and commented a macx_swapon call), here is the modified dynamic_pager.c. Once you downloaded it it can be compiled by using this awful command :
gcc -o dynamic_pager -no-cpp-precomp -DNO_DIRECT_RPC -framework CoreFoundation -framework IOKit -lSystem.B -R -DNO_DIRECT_RPC dynamic_pager.c -I/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers -I/Developer/SDKs/MacOSX10.4u.sdk/usr/include
Then (after having done a backup of the regular dynamic_pager) copy your brand new dynamic_pager to /sbin. Reboot and enjoy : it will only create a single swap file (64Mb), no less, no more.
I'm currently running it and it seems to work really fine. All my memory is used, not only the first 1Gb. The Inactive Memory is high as usual, but the single swap file is only marginally used.
The code posted above is just a big hack, when I will have more time I will clean up the code so that it will be a bit more understandable.
Enjoy.
Spotlight is an indexing tool that listen to every file change and then index the file (eg: the name of the file, it's content if it is a text file or metadata of it's a picture...). This is not especially useful if you are a bit organized. Even worse, when you are creating a bunch a big files (like copying 2 gigabytes of RAW files to the picture folder) the amount of IO needed by spotlight prevents the mac from being used by an human, the swapfiles grows (even with 2Gb of system memory).
To remove this piece of crap, just follow this how to.
Some times ago, I noticed that doing a lot of IO operation on encrypted loopback partition (like FileVault disk images) was trashing my system memory : after a while, the system began to swap a lot. I first thought some app was allocating huge parts of memory, but that was not the case.
At this time I suspected some memory leaks in the encryption or the disk image code of the Mac OS kernel. So I tried to do a lot of IO on a regular HFS partition. The same issue was present, but the swap usage was increasing slowier this time. The only solution I found to avoid this, was not to use disk intensive applications.
Unfortunetaly, as now use my mac to process RAW picture using Adobe Lightroom and this is a disk intensive application, so I bought 1 Go of memory to double the amount of RAM available for Mac OS. I was hopping this would definitevely solve my swap issue.
This was not the case, when I process a bunch of RAW file in a short amount of time, the system cannot refrain itself from swapping. Lightroom only eat 800M of memory, and while no other application if running. This only happen while using intensive disk IO operation (eg: processing RAW files or compiling many java files) and after the application is shut down the amount of physical memory used by the system is really high, so I come to conclusion that the IO cache of the kernel is just a piece of crap, eating a lot of memory without trying to figure out if there is enough memory to cache something : swapping memory pages holding disk cache is just stupid.
Is someone else is experiencing same issues, please let me know !
|
