Archives

Archives / 2009 / June

  • TIFF fax images, picture libraries, incorrect thumbnail generation, and SharePoint

    No Comments

    A welcomed feature of SharePoint is the picture library. This is similar to a document library but rather than storing documents, you can store pictures. You can store pictures in a document library too, you just don't get as rich a UX from it as you can with a picture library. Pictures uploaded to a picture library offer a few new features like slideshow views and auto-thumbnail generation. However, TIFF images sometimes have to be treated a little bit differently and this is where the thumbnail generation fails.

    When you upload an image to a picture library two additional images are generated. A thumbnail image that's size down to 160 pixels wide, and a web preview image that's 640 pixels wide. Andy Burns has a good blog entry on where these images are stored and Tech Training Notes has a good entry here on how to fetch this information in say a dataview web part for doing image previews.

    The auto-generated thumbnail is a great feature but problems arise when you upload some TIFF files. Recently I put together an image preview for fax images that were being sent to an email-enabled picture library. Knowing that the picture library would generate my thumbnails automatically I leveraged the fact that we could use this to avoid having to write a custom solution to do file manipulation. In addition to their image size, TIFF files can carry a resolution (represented in dpi or dots-per-inch). Most images (by default) are at 96dpi.

    You might recognize 96dpi because that's the default resolution that the Windows desktop renders at. This was Microsoft's attempt at achieving device-indpendent programming under Windows by using "device-indepndent units" or the oxymoron definition "device-independent pixels". In any case, 96dpi means that if you draw a one-inch square object then it will be rendered at 96 units high by 96 units wide. When the desktop is configured to run at 96dpi (the default) then that one-inch square will be 96 pixels wide by 96 pixels high.

    When a TIFF image is uploaded to a document library, SharePoint kicks off some .NET code (buried in an AutoThumbnailer class in the SharePoint Object Model) and generates those thumbnails for you. It does this by taking the image size and scaling it down as best as possible (I believe it will use the width as the norm and scale it down to 160 and 640 pixels wide for the two preview images and then adjust the height accordingly).

    The issue is that the fax images I was dealing with had two different resolutions defined in them. A resolution is the dpi that the image should be rendered at. Remember we said 96dpi rendered on a 96dpi display will be one-inch (or 96 pixels). Most images are built to this resolution by default and also (by default) the horizontal and vertical resolution is the same. Look at a picture on your hard drive in Windows Explorer by right clicking on it and selecting Properties. Click on the Summary tab and you'll see the details then click on the Advanced button (if you're looking at the "Simple" view) and you'll see not only the image size (width and height) but the image resolution (usually by default 96dpi but can be bigger or smaller).

    The fax images that I was dealing with had a height of 865 pixels and a width 1728 pixels but a vertical resolution of 98 and a horizontal resolution of 204. This is standard for TIFF images from fax machines (aka TIFF Class "F"). The thumbnails that SharePoint would create were of the matching aspect ratio. The numbers above look funny but using an online aspect ratio calculator like this one, you can see that 1728x865 is indeed the same aspect ratio as 640x320 and 160x80 (the sizes of the thumbnails generated). When the thumbnail images are created they're not taking into consideration resolution, only the size. So 640x320 is correct if the image was created for 96dpi. With a mismatched horizontal/vertical resolution the image is skewed and looks squashed. Clicking on the actual TIFF file in the picture library will launch the Windows Picture and Fax Viewer which adjust the image based on resolution and not dimensions.

    There isn't much that can be done to fix this since the thumbnails are already created. There are a couple of solutions, for example building your own event handler to resize images might be an option and there are plenty of image viewers out there that will correctly size things as they work from the original image. If you are building a custom solution just remember to take into consideration the image resoution vs. the screen resolution rather than image size. I'm just considering a custom solution myself to generate the thumbnails (via an event handler) and dropping them into the same named folders ("_t" for thumbnails, "_w" for web previews) which can be attached to a document library and will give you auto-thumbnails for any document library (rather than having to resort to a picture library). If you build your own then adjust the size like this:

    int adjustedWidth = screenResolution * (image.Width / image.HorizontalResolution);
    int adjustedHeight = screenResolution * (image.Height / image.VerticalResolution);

    So to render my original fax images on the Windows desktop (at 96 dpi) here's the results:

    width: 96 * (1728 / 204);
    height: 96 * (865 / 98)

    New image size (properly rendered) is 814 wide by 847 high. That's a more rectangular aspect ratio and matches the original fax (letter size). Now the image can be resized down to a thumbnail and won't be skewed.

    Long winded techno-babble post but hopefully that might clear up why your fax images in SharePoint picture libraries are skewed. Enjoy!

  • Account Names, SharePoint Setups, Server 2008 and Cheese

    1 Comment

    Recently I got a brand, spanking new Dell Latitude E6400 for work outfitted with Server 2008 (you won’t believe how hard that corporate battle was) and 8GB of RAM. We wanted to run Server 2008 as our workstation which would allow us a) the ability to run SharePoint natively and b) the ability to spin up additional/sandbox SharePoint instances using Hyper-V.

    Of course these machines are also on the corporate domain so running SharePoint locally proves a few challenges. For example you really don’t want to use domain accounts for your SharePoint setup as I’m offline a lot so with no domain controller that doesn’t work. Try as I might, I can’t make my machine a domain controller (what I usually do with a VM running SharePoint). The network guys seem to have a problem with that. So it’s local accounts for the SharePoint. There’s a few tricks to this to get it to work though.

    When I setup a new SharePoint development environment, I follow Scot Hillier's excellent set of instructions from Building Office 2007 Solutions in C# 2005. They start on page 35 of the book and IMHO the best instructions for configuring a VM or dev environment around as they use the principle of least privilege administration which is how you should roll when you build your dev boxes.

    With a machine on the network and the inability to use domain accounts, you regress to using local accounts for a local dev setup. I still setup the accounts as described in the book over a single account, but there are a few gotchas to know when doing this:

    • You cannot use a local group for the farm administrator group so don’t bother creating it. Just add users to the list if you need them. By default, after the install you’ll have BUILTIN\Administrators, the local SPConfigAcct, and whatever account you used to install the system with in the group. This should be sufficient for development.
    • When configuring the Office Server Search Service you must specify the Farm Search Service Account with a fully qualified name (even though it’s a local account) so use MACHINENAME\SPSearchAcct.
    • When configuring the Windows SharePoint Services Search Service you must specify the Service Account with a fully qualified name.
    • When configuring the Windows SharePoint Services Content Access Account use the account name without the machine prefix.
    • When creating sites I use the local hosts file as I don’t have control over DNS so I can’t create new A records. This of course means you can’t use Kerberos locally but that’s okay, NTLM is fine and I have VMs with domain controllers that I use for that testing. Create local host records for http://ssp, http://mysite, and http://sitename for easy access.
    • When creating the new Shared Services Web application you must account name without the machine prefix.
    • When configuring the Shared Services Provider you must specify the SSPServiceCredentials with a fully qualified name.

    When I setup a new system I create a few new web apps so I have different web configurations to work with. AC mentions he creates a publishing site, team site, and blank site. I create the following in new setups (YMMV):

    • http://sharepoint – My main development site used for pretty much everything. Things developed here are turned into features to be deployed to a staging/test environment. Uses the collaboration portal template.
    • http://collab – Stock SharePoint site that I create in case I need to get something untouched from it (master pages, etc.). I use this to sometimes see what the original looked like after I screw things up in the sandbox. Uses the Collaboration site template with a set of stock publishing, news, etc. sites created under it.
    • http://wss – Not really Windows SharePoint Services because I install MOSS but a blank site using the WSS templates (team, blank, wiki, etc.) when I need to try things out in pseudo-WSS mode. I have a few WSS VMs that I use for things like testing that something truly works in WSS-only mode but this site does me fine for the most part. Uses the blank site template.
    • http://pub – Publishing site. This uses different master pages and is a good site to have for checking content only type sites. I’ll publish content from sandbox to here sometimes to see what it might look like under different master pages. I’ll install pretty much all the master pages available out there into the site and it’s more of a look-n-feel test site than anything. Uses the publishing portal template.

    Hope that helps. Enjoy your Server 2008 setup!

    P.S. There is no cheese here.