In late 2012, iFixit.com posted a teardown of the MacBook Pro 13″ Retina Display Late 2012 and noted that:

• The most striking layout change resulting from the shrink from a 15″ to 13″ form factor is the rearranged battery cells. This allowed Apple’s designers to cleverly tuck the SSD away underneath the trackpad assembly.
• The empty space next to the SSD is very un-Apple. It’s not like them to leave big air gaps in their newest, sleekest designs.
• Our first thought was that a standard 2.5″ laptop drive might fit in this space, and it almost looks like this little nook was designed with that in mind.
• Our 9.5mm Crucial SSD didn’t allow the bottom cover to be closed, but just by a smidge. We’ll see if a 7 mm or 5 mm super-slim hard drive could be incorporated into the space.

iFixit later posted a guide to replacing the SSD in early 2013, but at the time, the only SSD alternatives appeared to be 3rd party modules like the Transcend JetDrive ($280 for 480GB drive and external USB 3.0 case) or the OWC Aura ($218 for 480GB drive only).

These 3rd party options, which have been designed specifically for the MacBook Pro’s SSD form factor, have been outside of my price range. However, recently, I’ve seen adapters available that would allow me to use smaller form factor SSDs with my A1425 MacBook Pro. For example:

• mSATA SSD to MacBook Pro Retina (A1425 A1398) Adapter (Amazon, DX)
• M.2 SSD to MacBook Pro Retina (A1425 A1398) Adapter (Amazon, DX)

Combine these adapters with either a Samsung 850 EVO mSATA SSD or a Transcend M.2 SSD (respectively) and you could potentially upgrade the SSD for significantly less than the designed-from-scratch modules offered by Transcend and OWC. I researched the adapters a bit more and found that if I chose to go the M.2 route, that I would need to make sure the new drive was SATA rather than PCIe (such as the Samsung 950 PRO). At the end of the day, I ordered a M.2 SSD to MacBook Pro Retina (A1425 A1398) Adapter and a 512GB Transcend M.2 SSD from Amazon and decided to see if I could get it up and running.

I wasn’t sure if there were going to be any performance gains/penalties, so I checked the speed of the original OEM 256GB SSD using Blackmagic Disk Speed Test:

Not too bad.

When I received the adapter and new SSD in the mail, I backed up my old SSD onto an external drive using Time Machine. I also created an El Capitan boot drive so that I could wipe the old drive and restore the Time Machine backup to the new SSD. I erased the old drive and although I tried securely wiping the drive, there are some lingering issues with wiping SSDs. Now I was ready for the transplant. Using the iFixit SSD Replacement guide, I removed the old SSD in preparation for the new module.

The M.2 drive fit perfectly into the adapter:

And I threw the whole shebang into the MacBook’s drive caddy:

After reassembling the machine, I started up the computer using the boot disk and… It worked. Awesome. I restored the time machine backup onto the new drive and it booted up without any issues. One little hiccup is that Apple disables TRIM for 3rd party SSDs, so you need to make sure to enable it after-the-fact using trimforce. It’s also faster than the original OEM SSD:

If you have an older MacBook Pro that’s running out of space, this is an easy and very worthwhile upgrade.

http://www.youtube.com/watch?v=bLxYTT_0GEI

I tried my hand at processing the HDR video output and was able to get a reasonably nice tone-mapped video:

After the break, you’ll find how I processed the initial Magic Lantern video using MATLAB and exiftool and tone-mapped the output using Luminance HDR.

First, we need to process the video with a function I (poorly) named ‘Step1MovieToInterpolatedFrames.m’ to separate the dark and light frames. The video is first loaded using the VideoReader object. Then we check to see if the first frame is darker or lighter than the second. This is admittedly a bit of a hack, but given the gross differences in exposure, seems to work well enough. After determining whether the first is light or dark, we then loop through all the frames of the movie, saving the real frames and appending an “L” to signify they are “light” and, also, interpolate between the frames. Why go through the bother of interpolation? Well, there will be image registration problems with the tone-mapping if we assume that a given dark frame matches the earlier or later light frame, especially with high-speed motion. Interpolation helps us “smooth” these errors out. Note that ideally we would use a morphing algorithm (similar to the one used by Twixtor), but this is the quickest method for the time being. After saving each frame, I use exiftool to assign an aperture value. Note that this has nothing to do with the real aperture value, but helps Luminance HDR tonemap the composite image. We do this for the dark frames as well, but now we take into account the EV shift in the video’s ISO when writing the aperture value using exiftool.

The second function, ‘Step2FramesToHDRFrames.m’, takes the individual light and dark frames and generates tone-mapped images. We go through every frame and use the Luminance HDR CLI (command line interface) to generate an HDR image and tone-map it (here using the mantiuk08 tone-mapping operator).

And the final function (‘Step3HDRFramesToVideos.m’) compiles all of the tone-mapped images into videos (one for the light frames, one for the dark frames, and one for the tonemapped frames).

The code can be found at the bottom of the post.

So, what do each of the Luminance HDR tonemapping operators look like (with their default parameters) when applied to a video? Here’s the source (note that YouTube strips out the alternating frames, you can find the original MOV here):

Ashikhmin

Drago

Durand

Fattal

Mantiuk 06

Mantiuk 08

Pattanaik

Reinhard 02

Reinhard 05