iWeb 1.1: Thinking outside the template:
... Just select the name of the page in the iWeb Site Organizer, and choose the Duplicate command in the Edit menu. An exact duplicate will appear in the main iWeb window, and its name will be highlighted in the Site Organizer panel, where you can rename it if you want....
Tuesday, May 30, 2006
iWeb 1.1: Creating new templates from old ones
iWeb 1.1x allows easy creation of new site templates. It's a big upgrade on 1.0!
Monday, May 29, 2006
Gamma and Windows Media Photo Spec: great resource for the photo geek
Microsoft requires one to sign a EULA to view their Windows Media Photo Specification spec. I've done that, and probably given them naming rights on our first grandchild. Of course promises to all powerful unregulated monopolies don't count -- ethically anyway.
Microsoft's inevitable evil aside, it's a well written document, available, of couse, only in Word's proprietary file format (the free viewers are windows only). Nisus Writer Express opens it -- with the usual mangling. The part that caught my attention was the discussion of Gamma, something that's otherwise been a mystery (read this too). Since I don't want to spend the next fifty years chopping rocks, I'll paraphrase.
Image related devices need to make the best use of limited resources (sensor response, storage, internal data paths, processing capabilities, power utilization). To do this they have their own internal schemes for assigning numeric values to "colors" (frequencies) and "brightness steps" [1].
The color part (aka gamut) is bad enough, but with color profiles and the like there's a somewhat standard way to transform an image between viewing devices. Somewhat is the operative word here, because even in the OS X world this is done incompetently. (Forget XP -- there you have to live in Adobe.)
The brightness steps are the real nasty. The WMP spec claims that "brightness steps" are a part of the color profile, but I've never seen software handle them. These "brightness steps" are the "gamma curve".
Brightness steps, alas, are a non-linear transformation. (This is when I wish I hadn't ducked Caltech's famously nasty applied maths course, so the best I can say here is that I wonder if "non-linear" is computationally problematic.) The brighteness steps are simplified as a single numerical value representing the non-linear transformation as a "power function".
Although the Microsoft spec claims that color profiles contain information on gamma, I've never seen any image rendering software do the transformations needed to correct brightness steps based on the gamma of, say, a default Mac display setting (OS X allows me to set my display "gamma", but the appearance of the UI changes, so the UI is not being transformed to match the new display setting.).
Decades ago Apple went with a gamma of 1.8 and IBM chose 2.2. (I think Sun did something different.) I suspect Apple's choice was more consistent with the crude image technology of the 1980s and IBM's choice was a better fit for what television used back then.
Whatever the original reason, we know IBM's choice won out. An image created in a Gamma 2.2 world will appear dim and "muddy" on a 1.8 display, conversely an image created on a PC will appear bright and garish on a Mac (people prefer bright and garish to muddy incidentally). This has nothing to do with the display being "brighter", it's the mismatch between the original "power function" and the rendering device "power function".
I'd wondered if Apple would take advantage of the Intel conversion to shift to a PC gamma, but I don't think they have. Much of the Apple UI looks a bit odd in a PC gamma, since it was designed for a Mac gamma.
I run my iMac monitor with a Gamma of 2.0. The OS X UI elements don't look too bad and, if I edit my images to be a bit "bright", my pictures seem acceptable on Mac and PC. It's an ugly compromise. The one thing I'd like to see in Vista would be for it to manage gamma translation in software, but I suspect that might be computationally tricky. (My OS X 10.5 wish list is another matter -- but Jobs never gives me what I ask for ...).
I would love to see WMP succeed -- if Microsoft were to make it an open standard. I would be shocked if they did that. I am pretty confident they will be evil. In their (weak) defense, I suspect they will be paying some patent holder licensing fees somehow.
I'd hoped for years that we'd go to JPEG 2000, but it has two fatal problems. The underlying mathematics are heavily patented (thanks to Wikipedia for finally answering my question of the past few years) and JPEG encoding on modern CPUs is both computationally expensive and energy inefficient. The patent problem has loomed larger thank to our governments idiotic management of the patent process. So JPEG 2000 appears to be a dead issue. (Adobe Acrobat, btw, provides JP2K encoding as an option, it works very well for text documents because it manages edges well even with significant lossy compression.)
[1] Even I know I'm oversimplifying here. I think to really understand what's going on you need a deep knowledge of the physics of the photo sensor and be able to map the transformed output of the sensor into the odd and archaic terminology of visual perception (read this). I wonder how many people really understand the end-to-end process. I'm guessing maybe five.
Update 5/30/06: So why don't we just update JPEG to fix its problems with 16 bit color and braindead metadata? Heck, I'd be delighted with 12 bits and Adobe XMP! I don't know. Really, it would be a huge improvement over what we have now, and really 99% JPEG with modern encoders is pretty darned good in terms of artifact and resolution. Sure the files could be smaller, but it would still a huge improvement over DNG and TIFF ... As a former manager once told me 'don't let the perfect be the enemy of the good...'
Microsoft's inevitable evil aside, it's a well written document, available, of couse, only in Word's proprietary file format (the free viewers are windows only). Nisus Writer Express opens it -- with the usual mangling. The part that caught my attention was the discussion of Gamma, something that's otherwise been a mystery (read this too). Since I don't want to spend the next fifty years chopping rocks, I'll paraphrase.
Image related devices need to make the best use of limited resources (sensor response, storage, internal data paths, processing capabilities, power utilization). To do this they have their own internal schemes for assigning numeric values to "colors" (frequencies) and "brightness steps" [1].
The color part (aka gamut) is bad enough, but with color profiles and the like there's a somewhat standard way to transform an image between viewing devices. Somewhat is the operative word here, because even in the OS X world this is done incompetently. (Forget XP -- there you have to live in Adobe.)
The brightness steps are the real nasty. The WMP spec claims that "brightness steps" are a part of the color profile, but I've never seen software handle them. These "brightness steps" are the "gamma curve".
Brightness steps, alas, are a non-linear transformation. (This is when I wish I hadn't ducked Caltech's famously nasty applied maths course, so the best I can say here is that I wonder if "non-linear" is computationally problematic.) The brighteness steps are simplified as a single numerical value representing the non-linear transformation as a "power function".
Although the Microsoft spec claims that color profiles contain information on gamma, I've never seen any image rendering software do the transformations needed to correct brightness steps based on the gamma of, say, a default Mac display setting (OS X allows me to set my display "gamma", but the appearance of the UI changes, so the UI is not being transformed to match the new display setting.).
Decades ago Apple went with a gamma of 1.8 and IBM chose 2.2. (I think Sun did something different.) I suspect Apple's choice was more consistent with the crude image technology of the 1980s and IBM's choice was a better fit for what television used back then.
Whatever the original reason, we know IBM's choice won out. An image created in a Gamma 2.2 world will appear dim and "muddy" on a 1.8 display, conversely an image created on a PC will appear bright and garish on a Mac (people prefer bright and garish to muddy incidentally). This has nothing to do with the display being "brighter", it's the mismatch between the original "power function" and the rendering device "power function".
I'd wondered if Apple would take advantage of the Intel conversion to shift to a PC gamma, but I don't think they have. Much of the Apple UI looks a bit odd in a PC gamma, since it was designed for a Mac gamma.
I run my iMac monitor with a Gamma of 2.0. The OS X UI elements don't look too bad and, if I edit my images to be a bit "bright", my pictures seem acceptable on Mac and PC. It's an ugly compromise. The one thing I'd like to see in Vista would be for it to manage gamma translation in software, but I suspect that might be computationally tricky. (My OS X 10.5 wish list is another matter -- but Jobs never gives me what I ask for ...).
I would love to see WMP succeed -- if Microsoft were to make it an open standard. I would be shocked if they did that. I am pretty confident they will be evil. In their (weak) defense, I suspect they will be paying some patent holder licensing fees somehow.
I'd hoped for years that we'd go to JPEG 2000, but it has two fatal problems. The underlying mathematics are heavily patented (thanks to Wikipedia for finally answering my question of the past few years) and JPEG encoding on modern CPUs is both computationally expensive and energy inefficient. The patent problem has loomed larger thank to our governments idiotic management of the patent process. So JPEG 2000 appears to be a dead issue. (Adobe Acrobat, btw, provides JP2K encoding as an option, it works very well for text documents because it manages edges well even with significant lossy compression.)
[1] Even I know I'm oversimplifying here. I think to really understand what's going on you need a deep knowledge of the physics of the photo sensor and be able to map the transformed output of the sensor into the odd and archaic terminology of visual perception (read this). I wonder how many people really understand the end-to-end process. I'm guessing maybe five.
Update 5/30/06: So why don't we just update JPEG to fix its problems with 16 bit color and braindead metadata? Heck, I'd be delighted with 12 bits and Adobe XMP! I don't know. Really, it would be a huge improvement over what we have now, and really 99% JPEG with modern encoders is pretty darned good in terms of artifact and resolution. Sure the files could be smaller, but it would still a huge improvement over DNG and TIFF ... As a former manager once told me 'don't let the perfect be the enemy of the good...'
Sunday, May 28, 2006
Mac backup software: SuperDuper wins again
A reader of this blog kindly directed me to a review of Mac backup software's ability to capture and restore metadata. SuperDuper did well, Retrospect and most other products did poorly. He didn't evaluate Apple's own tool - Backup.app.
A lot of work went into this article. Greatly appreciated.
A lot of work went into this article. Greatly appreciated.
Saturday, May 27, 2006
OS X desktop pictures: the black and white selection
There are lots of OS X Desktop pictures out there, but my new favorites are the black and white images bundled with 10.4. Most images make it hard to find my icons, so I've generally stayed with the system default. The black and white images are far more interesting, let color icons stand out very well. Practical and attractive.
WikiMapia: better when Google owns it
WikiMapia takes a Wiki approach to map annotation. Unsurprisingly, since this a neat idea, their server is now a cooling puddle of molten metal.
Hopefully Google will take it over.
Hopefully Google will take it over.
Thursday, May 25, 2006
Using iWeb on more than one Mac
Tech note: Using iWeb on more than one Mac
Move Users/username/Library/Application Support/iWeb/domain.sites to a share drive.
Move Users/username/Library/Application Support/iWeb/domain.sites to a share drive.
Changing workgroups for an OS X client
It's amazing what you can find in OS X Help files -- now that they actually work:
Changing the workgroup for your MacSome of this might be new in 10.4. I wish I'd noticed earlier. I'll post an update on all the effects.
If your Mac and Windows computers are in the same workgroup and on the same local network or subnetwork, it’s easier to connect to the Mac from the Windows computer. When the Mac belongs to the same workgroup as the Windows computer, its name appears in the Workgroup Computers panel of My Network Places.
“WORKGROUP” is the default Windows workgroup name for Mac OS X. Using Directory Access, you can change the workgroup name on the Mac to match a workgroup name you are already using.
Open Directory Access (in Applications/Utilities).
If necessary, click the lock icon and type the name and password for an administrator user on your computer.
Double-click SMB/CIFS in the list and type the new workgroup name in the dialog, then click OK.
Update 1/1/2010: In 10.6 Directory Access is no more. This control is now an advanced option in the Network Preference Pane. Open the Pane, click the Advanced button, then go to WINS to specify a Workgroup name.
When I did this in 10.6.2 I could select from a drop down, but my choice didn't "stick". I had to type it in.
Subscribe to:
Posts (Atom)