<?xml version="1.0" encoding="ISO-8859-1"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ref="http://purl.org/rss/1.0/modules/reference/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://purl.org/rss/1.0/">
	<channel rdf:about="http://www.adjb.net/rss.rdf">
		<title>There is no end, but addition: Alex Brown&#039;s weblog</title>
		<link>http://www.adjb.net/index.php</link>
		<description><![CDATA[Views expressed in this weblog are my own, not those of my employer or of any other organisation]]></description>
		<items>
			<rdf:Seq>
				<rdf:li resource="http://www.adjb.net/index.php?entry=entry081006-181908" />
				<rdf:li resource="http://www.adjb.net/index.php?entry=entry081003-105734" />
				<rdf:li resource="http://www.adjb.net/index.php?entry=entry081001-155040" />
				<rdf:li resource="http://www.adjb.net/index.php?entry=entry080930-083856" />
				<rdf:li resource="http://www.adjb.net/index.php?entry=entry080928-223454" />
				<rdf:li resource="http://www.adjb.net/index.php?entry=entry080927-100437" />
				<rdf:li resource="http://www.adjb.net/index.php?entry=entry080925-144210" />
				<rdf:li resource="http://www.adjb.net/index.php?entry=entry080910-183259" />
				<rdf:li resource="http://www.adjb.net/index.php?entry=entry080906-124155" />
				<rdf:li resource="http://www.adjb.net/index.php?entry=entry080709-160624" />
			</rdf:Seq>
		</items>
	</channel>
	<item rdf:about="http://www.adjb.net/index.php?entry=entry081006-181908">
		<title>There is no more addition</title>
		<link>http://www.adjb.net/index.php?entry=entry081006-181908</link>
		<description><![CDATA[This is my last post on this blog.<br /><br />Service will be resumed on my <a href="http://www.adjb.net/" target="_blank" >new blog</a>. I will keep this old blog running in parallel for the forseeable future.<br /><br />Gentle reader, please update any bookmarks/RSS subscriptions as necessary!]]></description>
	</item>
	<item rdf:about="http://www.adjb.net/index.php?entry=entry081003-105734">
		<title>SC 34 Meetings, Jeju Island, Korea - Day 4</title>
		<link>http://www.adjb.net/index.php?entry=entry081003-105734</link>
		<description><![CDATA[<h1>SC 34 plenary</h1><br /><div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/oKzxoJzO43SKlIVT6S4MAg"><img src="http://lh3.ggpht.com/alexander.david.john.brown/SOXBN3pWnCI/AAAAAAAABMo/jVNI2KYQ0Lk/s400/DSC_0091_DxO_raw.jpg" /></a><br/><i>I took this shot on a pre-plenary stroll</i></div><br />I had slept deeply, I had slept long, and awoke in showroom condition ready to face the excitements of an SC 34 plenary: this is the forum in which all SC 34 members present meet to discuss and pass resolutions. In the event this went extremely smoothly: all <a href="http://www.itscj.ipsj.or.jp/sc34/open/1099.htm" target="_blank" >resolutions</a> passed with unanimous consensus by the attending NBs (Brazil, Canada, China, Côte d’Ivoire, Denmark, Finland, Germany, India, Italy, Japan, Korea, Norway, South Africa, UK, and USA). Only one issue had caused contention, and that was smoothed away amicably over lunch. <br /><br />The two most significant resolutions established two new working groups, WG 4 and WG 5.<br /><br />WG 4 was the result of my recommendations following the work convening (the now disbanded) Ad Hoc Group 1. We had met in London in July and decided how <a href="http://www.itscj.ipsj.or.jp/sc34/open/1055.htm" target="_blank" >we thought</a> OOXML should be maintained. The recommendation was essentially very simple: this should be a full ISO/IEC standard under purely International (i.e. National Body) control. WG 4 is the forum in which that will happen. Although Ecma’s existing individual experts will participate in this group, Ecma will have no voting rights and has been constrained to a purely administrative role – the SC 34 Secretariat (Japan) has decided to retain Ecma’s services as a subordinate secretariat for the new Working Group. WG 4 will be convened by the eminent <a href="http://en.wikipedia.org/wiki/Murata_Makoto" target="_blank" >Murata Makoto</a> (Japan), who’s strict impartiality (and strictness) will I’m sure keep WG 4 on the straight and narrow.<br /><br />WG 5 is the home for “Document Interoperability” (a tweet I received on the subject from <a href="http://www.webmink.net/" target="_blank" >Simon Phipps</a>, questioning whether documents <i>could</i> be said to interoperate sparked quite a discussion – in the end it was decided that yes, they could be said to). The immediate work for this working group is the new project working on 26300/29500 translation, but it’s likely I think that a number of new projects will start here before long. WG 5 will be convened by the excellent Dr Jaeho Lee (Korea).<br /><br /><h1>My retirement?</h1><br />With the arrangements made for WG 4, a vacancy arose for the convenorship of WG 1, and I was pleased to accept the honour of taking this role. It is a great responsibility, following in the giant footsteps of preceding convenors <a href="http://en.wikipedia.org/wiki/Charles_Goldfarb" target="_blank" >Charles Goldfarb</a>, <a href="http://www.is-thought.co.uk/mtb.htm" target="_blank" >Martin Bryan</a>, and Murata-san himself.<br /><br />On a personal level it must also be said it is a relief to step away from the standardisation of OOXML. Whatever one’s views about the merits of the spec, I think there can be no disagreement with the thought that being heavily involved with its passage is both tiring and stressful. For now, I’ve had enough.<br /><br /><h1>Impressions of Jeju</h1><br />Jeju is a beautiful and charming place, whose people are unfailing kind and helpful. We experienced a full gamut of weather from sunny skies to driving rain and high winds as we experienced the outer bands of <a href="http://en.wikipedia.org/wiki/Typhoon_Jangmi_(2008)" target="_blank" >Typhoon Jangmi</a>.<br /><br />I took some snaps throughout these meetings to decorate this blog, but for a much better impression (and a sight of real photographic talent), <a href="http://www.flickr.com/photos/dougerino/sets/72157607529481934/" target="_blank" >Dough Mahugh’s photos of Korea</a> are a must-see.<br /><br /><h1>SC 34 celebrates</h1><br />After the plenary, a few of us headed out to Jungmoon for some sightseeing and a bite to eat. After marvelling at an ooh-inducing sunset (aided in spectacle, it is said, by the air pollution from China) we toured some of the luxury hotels and casinos in the area before reaching consensus (with no dissent) that we’d prefer to eat a more rustic-style Korean barbeque. That we did, washing it down (naturally) with some more Korean vodka.<br /><br /><div align="center"> <a href="http://picasaweb.google.co.uk/lh/photo/yZWSHevrN0HvkNNefTx53g"><img src="http://lh5.ggpht.com/alexander.david.john.brown/SOXBP3zsAwI/AAAAAAAABE4/mvyVLy7kORI/s400/DSC_0182_DxO_raw.jpg" /></a> <br/><i>Jean Paoli being set up for a picture<br/>outside the Hotel Shilla, Jungmoon</i></div><br />So, after a tough year, what is the mood in SC 34? Positive, is my impression. The tensions surrounding ISO/IEC 29500 have dissipated and all agree that we have made the best arrangements we could for stewardship of the Standard and progression of work around it. With two new working groups now established the character of SC 34 is bound to change, and it’s possible future meetings will be double, or even triple the size we are used to as we attract more International interest. The future is bright, and we look forward to meeting up again for our “Prague Spring” in March 2009.<br /><br /><div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/bD152aIZ56hcnJ0-vmxUrg"><img src="http://lh4.ggpht.com/alexander.david.john.brown/SOYS5_9CqhI/AAAAAAAABF0/nVtUphVfsvM/s400/DSC_0204_DxO_raw.jpg" /></a> <br/><i>All’s well that ends well;<br/>the trip ends with a Korean barbeque</i></div>]]></description>
	</item>
	<item rdf:about="http://www.adjb.net/index.php?entry=entry081001-155040">
		<title>SC 34 Meetings, Jeju Island, Korea - Day 3</title>
		<link>http://www.adjb.net/index.php?entry=entry081001-155040</link>
		<description><![CDATA[<h1>Preparing for the Plenary</h1><br /><div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/zSZsQjgvJUsPeap_shp2wA"><img src="http://lh5.ggpht.com/alexander.david.john.brown/SOc7cfmsW2I/AAAAAAAABLs/vsMuW62MM5s/s400/DSC_0066_DxO_raw.jpg" /></a><br/><i>This Korean bog is so computerized it has an appreciable boot sequence;<br/>brings a whole new meaning to the term “core dump”</i></div><br />WG 1 met in the morning and its business was mainly consensus-building and drafting on topics already covered, in advance of tomorrow’s plenary. The plan is to create a new working group dedicated to document interoperability, and many NBs participated in a drafting panel to get the terms of reference for this group just right. There were also liaison statements to be written: to OASIS (concerning ODF maintenance), and to JTC 1 (concerning ODF maintenance) – again there was wide interest in making sure these communiqués exactly expressed the consensus International view.<br /><br />Meanwhile, back in <a href="http://en.wikipedia.org/wiki/Blighty" target="_blank" >Blighty</a>, our tireless and most excellent experts were scrutinizing the new ISO/IEC 29500 (OOXML) text to ensure all the UK’s BRM changes have been properly implemented. Three problems have been found so far and submitted to SC 34 as defect reports. I am sure there will be many more. <br /><br /><h1>Bye bye IBM?</h1><br />Following the threat made last week by Bob Sutor (VP, Vice President Open Source and Standards, IBM) that IBM would, as its first stated “principle”,<br /><br /><div style="background-color:#ddf;padding:20px;">
Begin or end participation in standards bodies based on the quality and openness of their processes, membership rules, and intellectual property policies.”
</div><br />a question being asked along the committee corridors by perplexed NB members is whether IBM has withdrawn its staff from participation SC 34. I have no idea, but IBM people are certainly conspicuous here by their total absence.<br /><br /><div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/2Daco7ue_AqFD4dCJsmDAg"><img src="http://lh5.ggpht.com/alexander.david.john.brown/SOOHuybq7tI/AAAAAAAABEE/0WACv3U6pvs/s400/rob.jpg" /></a><br/><i>Some chairs were empty at SC 34</i></div><br />In reaction to Bob Sutors’s post, the headlines (some from sources who really should know better) suggested that IBM would “leave ISO”. They can of course do no such thing. IBM is not a member of ISO (or IEC, or JTC 1, or any of its subcommittees) – mere vendors are not accorded the privilege of being members of an <i>International</i> organisation; only National Bodies (effectively, countries) are — hence the “nation” in “international”.<br /><br />The next steps in IBM’s plan is to hold a secret meeting (invitation only; secret member list; opaque funding) to discuss – would you believe – openness, perhaps before waltzing off to create a brave new standards world in <a href="http://secondlife.com/" target="_blank" >Second Life</a>: maybe there, IBM can be a nation!<br /><br />For myself I know first-hand that IBM does have some great people who have a lot to bring to International Standardization in all kinds of ways. Indeed IBM has made a historic contribution to SC 34 and its predecessor groups – no less a person than <a href="http://www.sgmlsource.com/" target="_blank" >Charles Goldfarb</a>, the “father of SGML”, was himself an IBM man. We need people of that calibre. But even if IBM is blasé about (what might sentimentally be termed) a betrayal of its heritage, they might take a hard-headed look at the benefits of being a full, good-faith player in International Standardization: I wonder how long, especially in these troubled economic times, IBM stockholders are going to tolerate the kind of valueless, out-of-control escapade the company is currently indulging in.<br /><br /><div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/rWn15vVYa5yGthUdnwbsSQ"><img src="http://lh3.ggpht.com/alexander.david.john.brown/SOOHvNUDe6I/AAAAAAAABEM/rL9L-P1coH4/s400/CFGandCats.jpg" /></a><br/><i><a href="http://www.sgmlsource.com/" target="_blank" >Charles Goldfarb</a>, markup languages titan and sometime IBM man</i></div>]]></description>
	</item>
	<item rdf:about="http://www.adjb.net/index.php?entry=entry080930-083856">
		<title> SC 34 Meetings, Jeju Island, Korea - Day 2</title>
		<link>http://www.adjb.net/index.php?entry=entry080930-083856</link>
		<description><![CDATA[<h1>Honeymoon Island</h1><br />That’s what they call it here, and – in season – this resort is throbbing with newlyweds. Right now though, it has a something of the ghost-town about it, as it is half-deserted apart from us standards wonks.<br /><br /><div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/7r7tl3wWtsqXnhSiBPXqtA"><img src="http://lh4.ggpht.com/alexander.david.john.brown/SODN1rfJ2RI/AAAAAAAABCU/c0MLmcAJ1h8/s400/DSC_0067.JPG" /></a><br/><i>The Honeymoon continues? Patrick Durusau (USA) and<br/>Jean Paoli (Microsoft/Ecma)</i></div><br />Today was a solid 9-till-5 meeting day, and for me the jet lag is beginning to take its toll. Luckily our Korean hosts have a steady supply of coffee – and that keeps us all in the game; that, and the ineffable fascination of every topic we discuss in WG 1. Take the topic of character registries for example. Now, even for WG 1 diehards this is a somewhat recondite subject area – so I am sure a few eyes glazed over when we addressing the question of whether to include a normative reference to <a href="http://en.wikipedia.org/wiki/ISO_15897" target="_blank" >ISO/IEC 15897</a> in our own CREPDL specification (FCD 19757-7). However, after an eloquent argument from <a href="http://pipl.com/directory/people/Hideki/Hiura" target="_blank" >Hideki Hiura</a> there was a clear consensus not to include it. Or, at least, no one (except the original proponent of the inclusion of the reference) contradicted him …<br /><br /><div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/3WNO8dP1IK5WGy9JkETC6Q"><img src="http://lh5.ggpht.com/alexander.david.john.brown/SODPQbzvTXI/AAAAAAAABCk/sgyZTEAMHPQ/s400/DSC_0072.JPG" /></a><br/><i><a href="http://pipl.com/directory/people/Hideki/Hiura" target="_blank" >Hideki Hiura</a> (left) and <a href="http://en.wikipedia.org/wiki/Murata_Makoto" target="_blank" >Murata Makoto</a> (Japan)</i></div><br /><br /><h1>Yet more ODF and OOXML</h1><br />… were the main topics of today, both separately and in tandem. Of most interest, perhaps, was the discussion surrounding the start of work on <a href="http://www.itscj.ipsj.or.jp/sc34/open/1035c.htm" target="_blank" >a project</a> setting out to describe the mapping between ISO/IEC 26300 (ODF) and ISO/IEC 29500 (OOXML). This had received wide and decisive voting support from countries in its ballot, though some countries had objected to its commencement due to the non-availability of the ISO/IEC 29500 text. That hiatus is now happily behind us and the project is set to proceed with a powerful three-person editing teams (from Germany, Korea and China).<br /><br />It is always pleasing to see widening participation in SC 34 and in these meetings we have been honoured with the presence of a large Chinese delegation. Word is that <a href="http://www.uoml.org" target="_blank" >UOML</a> may be coming our way shortly, and there are even rumours that there may be an opportunity for SC 34 involvement in <a href="http://en.wikipedia.org/wiki/UOF" target="_blank" >UOF</a>. Wow – if so, that would be a really positive opportunity for work on truly International document interoperability work, and would further strengthen SC 34’s role as the centre of the Office document format universe.]]></description>
	</item>
	<item rdf:about="http://www.adjb.net/index.php?entry=entry080928-223454">
		<title>SC 34 Meetings, Jeju Island, Korea - Day 1</title>
		<link>http://www.adjb.net/index.php?entry=entry080928-223454</link>
		<description><![CDATA[<div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/d0F1nqehxi2QoCXfV1hDFA"><img src="http://lh3.ggpht.com/alexander.david.john.brown/SOYkY-GF6vI/AAAAAAAABHw/JIDPo6uz0bU/s400/DSC_0138_DxO_raw.jpg" /></a></div><br /><br /><h1>ODF – Our work here is done?</h1><br />Day 0 had been concluded with a tasty Korean meal (washed down with possibly a tad too much Korean vodka) and it was very interesting to hear some of the views from NB members on how they thought the office formats future will play out (and no, there were no Microsoft, IBM or Ecma people at the table). One view was that ODF had served its purpose (to get MS formats out into the open) and should now declare victory before fading away gracefully; another was that OOXML would surely become the default format of the <a href="http://www.openoffice.org/" target="_blank" >OpenOffice.org</a> suite, and that this would crystallize the real option users had: to use FOSS or commercially-licensed Office packages. I’m not sure I’d go with either of these but still, it was refreshing to get some new perspectives rather than the stale repetitions that have too often characterised the exchanges of the past months. It will be interesting to see what really happens ... personally I think ODF is more likely to emerge as a kind of “default choice” than OOXML (not perhaps, that most users care). <br /><br /><h1>Into the meetings proper</h1><br />Sunday (Day 1) was a busy day of WG 1 meetings in the excellent facilities provided by our Korean hosts. In the morning we covered a number of <a href="http://dsdl.org/" target="_blank" >DSDL</a> topics, including Part 8 (DSRL) and the part I am editing – now called “Extensible Datatypes” – which has a <a href="http://lists.dsdl.org/dsdl-comment/2008-09/0054.html" target="_blank" >new draft</a> which will progress to FCD ballot. Rick Jelliffe, who sadly isn’t with us, had sent a voice message talking us through his fascinating proposed enhancements to Schematron – the Part of DSDL for which he is responsible. Very much business as usual for WG 1. However …<br /><br /><h1>OOXML shock?</h1><br />The afternoon was devoted to OOXML matters. Evidently, the sudden appearance of the final text of ISO/IEC 29500:2008 has come as something of a surprise for many; and the appearance of the <a href="http://www.itscj.ipsj.or.jp/sc34/open/1084.htm" target="_blank" >first defect report</a> (from Japan) shortly thereafter was a shock. Suddenly it’s all real; the clock is ticking and the Project Editor is obliged to respond to Japan’s report in eight weeks. <a href="http://en.wikipedia.org/wiki/Makoto_Murata" target="_blank" >Murata Makoto</a> (the convenor of WG 1) carefully explained the details of the maintenance regime and took us through an example of one of the Japanese defects, which centred on a BRM-mandated change (from Finland) that had not been properly implemented in the final OOXML text. No doubt other NBs, as a priority, will now scour OOXML to make sure “their” changes have been implemented, and submit defect reports accordingly where they have not. The UK, with its 600 or so accepted changes, has a lot of checking to do …<br /><br />I look on this though with a certain grim satisfaction, for two reasons. First because by insisting on timely defect handling SC 34 is compensating for a deficiency of the Fast Track process: the lack of National Body review of the final text. Secondly because one of the many problems of the JTC 1 standardisation of ODF in 2006 is the lax maintenance regime, which boils down to OASIS declaring: we’ll fix your reported ODF defects if we want to in our own good time, thank you very much. Partly as a reaction to this SC 34 was determined to hold OOXML’s feet to the fire and make sure the JTC 1 maintenance regime (one of the better processes described by the Directives) was fully applied and that this time, it was got right.<br /><br /><div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/8EalYQEIN98O4i9rQbaCgQ"><img src="http://lh6.ggpht.com/alexander.david.john.brown/SOYxREDfw3I/AAAAAAAABI8/DbJ9MJIib94/s400/DSC_0218_DxO_raw.jpg" /></a></div>]]></description>
	</item>
	<item rdf:about="http://www.adjb.net/index.php?entry=entry080927-100437">
		<title>SC 34 Meetings, Jeju Island, Korea - Day 0</title>
		<link>http://www.adjb.net/index.php?entry=entry080927-100437</link>
		<description><![CDATA[Day 0 is meant to be for acclimatisation – coming to terms with the time-zone, a spot of gentle sightseeing, that sort of thing … The formal meetings start tomorrow (Sunday).<br /><br /><div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/R_dU8P0vbglyba7wy-xekg"><img src="http://lh6.ggpht.com/alexander.david.john.brown/SOYUqok1tiI/AAAAAAAABGU/ncCHTIL6VoM/s400/DSC_0015_DxO_raw.jpg" /></a></a></div><br />As it is, however, a few pressing issues have demanded attention – one is a rather esoteric problem surrounding XML entity reference renaming in DSRL (follow along on WG1’s public discussion list <a href="http://lists.dsdl.org/dsdl-comment/2008-09/" target="_blank" >here</a>); the other is the impact that the sudden appearance of the ISO/IEC 29500 (OOXML) text has had. Suddenly, a lot of work which might have had to go on ice seems likely to proceed apace – for example the ODF/OOXML interoperability work and the defect handling of OOXML.<br /><br /><div align="center"><a href="http://picasaweb.google.co.uk/lh/photo/D3EWiaqaYjhd-8dAX8O3gA"><img src="http://lh4.ggpht.com/alexander.david.john.brown/SOYUvReAuwI/AAAAAAAABKg/yadWD9pFaFc/s400/DSC_0023_DxO_raw.jpg" /></a></div><br />NBs will also start to scrutinise the final 29500 text to ensure their own BRM-mandated changes have been implemented. In my opinion one of the many problems with the Fast Track process is that the text implied by the BRM result passes straight for publication (this is explicit in the Directives). It would be much more sensible all round, I think, to allow for an FDIS stage so that NBs could proof the text for the implementation of the resolved-on-changes.<br /><br /><div align="center"><table style="width:auto;"><tr><td><a href="http://picasaweb.google.co.uk/lh/photo/veAe5rbj_5gHKojq_CekTQ"><img src="http://lh6.ggpht.com/alexander.david.john.brown/SOYU0VDaYOI/AAAAAAAABGo/cM8icNv1o8k/s400/DSC_0046_DxO_raw.jpg" /></a></td></tr><tr><td style="font-family:arial,sans-serif; font-size:11px; text-align:right">From <a href="http://picasaweb.google.co.uk/alexander.david.john.brown/Jeju2008">jeju 2008</a></td></tr></table></div>]]></description>
	</item>
	<item rdf:about="http://www.adjb.net/index.php?entry=entry080925-144210">
		<title>SC 34 Meetings, Korea</title>
		<link>http://www.adjb.net/index.php?entry=entry080925-144210</link>
		<description><![CDATA[Say what you like about Vista, but one ace up is sleeve is definitely the ability to play <a href="http://www.ea.com/crysis/" target="_blank" >Crysis</a> using <a href="http://en.wikipedia.org/wiki/Directx_10#DirectX_10" target="_blank" >DirectX 10</a>. Eye candy indeed, and an astonishing feat of programming.<br /><br />I was intrigued to notice in the game&#039;s title sequence the other day that the island setting for the game is not too far off the coast of Korea. Coincidentally the venue for the <a href="http://www.itscj.ipsj.or.jp/sc34/open/1049rev2.htm" target="_blank" >upcoming SC 34 meeting</a> is <a href="http://en.wikipedia.org/wiki/Jeju-do" target="_blank" >Jeju Island</a>, and as I write I am in that state of nervous excitement that precedes any long trip. From leaving the front door it is going to be over 20 hours before setting foot in the meeting hotel. If everything goes smoothly.<br /><br />On a personal level I am expecting (hoping) to hear less at this meeting about OOXML than in the last few, and to be able to return to the important infrastructure XML standards (and in particular <a href="http://dsdl.org/" target="_blank" >DSDL</a>) that first lured me into International standardisation.<br /><br />So, no <a href="http://en.wikipedia.org/wiki/Nanosuit" target="_blank" >nanosuit</a> required ... we shall see ...]]></description>
	</item>
	<item rdf:about="http://www.adjb.net/index.php?entry=entry080910-183259">
		<title>Blown highlight recovery (or:  RAW vs JPG)</title>
		<link>http://www.adjb.net/index.php?entry=entry080910-183259</link>
		<description><![CDATA[In a comment to my <a href="http://www.adjb.net/index.php?entry=entry080906-124155" target="_blank" >last blog entry</a>, <a href="http://www.garshol.priv.no/blog/" target="_blank" >Lars Marius Garshol</a>, wondered whether the <a href="http://www.dxo.com/intl/photo/dxo_optics_pro/" target="_blank" >DxO Optics Pro</a> software I was using was any good at recovering “lost” or “blown” highlights – bright areas of an image which all get maxxed out and appear as pure white. Here’s a simple experiment to see how it performs.<br /><br />The first thing I discovered is that the “highlight preservation” feature is not enabled unless processing a RAW image, so with some trepidation (am I entering <a href="http://www.kenrockwell.com/tech/raw.htm" target="_blank" >the dark side</a>?), I set my DSLR to take NEF+JPEG, stuck it out of the window and took a couple of shots of Cambridge back gardens with a load of cloudy sky in view.<br /><br />The result out of the camera was as expected: much of the cloudy sky simply showed as white:<br /><br /><br /><div align=center><a href="http://picasaweb.google.co.uk/lh/photo/oyCGKUARJjb6I722QgSerA"><img src="http://lh6.ggpht.com/alexander.david.john.brown/SMf0jdZZQRI/AAAAAAAAA8Y/9XWh0SRBHQc/s800/DSC_0283.JPG"/></a><br/><i>JPEG, out of the camera</i></div><br /><br />Taking the NEF equivalent image and processing it through DxO Optics Pro with “highlight preservation – strong” selected yielded the following result (tip: if you&#039;re viewing this on a less-than-stellar LCD screen which is not good at <i>displaying</i> subtly-differentiated highlights, try tilting it to get an appreciation of what information has been retrieved):<br /><br /><br /><div align=center><a href="http://picasaweb.google.co.uk/lh/photo/PZDrPGWIdwXZXOQKjVwCkQ"><img src="http://lh6.ggpht.com/alexander.david.john.brown/SMf0j-E_j2I/AAAAAAAAA8c/aEISx7y-rEk/s800/DSC_0283_DxO_raw.jpg"/></a><br/><i>JPEG, processed from RAW</i></div><br />A striking improvement I’d say. From thinking that RAW was an unwarranted nuisance, from now I’m going to set my camera to take JPEG+RAW so that similarly lost highlights can be recovered if need be for interesting pictures. After it, if it looks better – that’s what matters.<br /><br />Of course the purist might say it would be better to get the exposure right to start with – but in many daylight conditions the light contrasts are just too strong for the sensor on a digital camera to be able to cope – film is better for that right now.<br />]]></description>
	</item>
	<item rdf:about="http://www.adjb.net/index.php?entry=entry080906-124155">
		<title>A Wider Perspective</title>
		<link>http://www.adjb.net/index.php?entry=entry080906-124155</link>
		<description><![CDATA[One of my more fun activities this year has been getting used to a super wide angle lens, the <a href="http://www.sigmaphoto.com/lenses/lenses_all_details.asp?id=3301&amp;navigator=6" target="_blank" >Sigma 10-20mm f4-5.6 EX DC HSM</a> to be precise. This is designed for cropped-sensor DSLRs and on my Nikon D50 with its 1.5x crop this focal range is equivalent to 16mm for a traditional full frame 35mm lense - in other words, wide.<br /><br />To get an idea of how wide, here are two pictures of the same scene (the light looked interesting at 07:30 this morning, so I headed into town to get these pictures). The first  is taken with the 18-55mm kits lens that came with the Nikon, at its widest zoom setting of 18mm (equivalent to 28mm in old money).<br /><br /><br /><div align=center><a href="http://picasaweb.google.co.uk/lh/photo/TPNTfru10OhQKXhyzZQuhg"><img src="http://lh4.ggpht.com/alexander.david.john.brown/SMJWxcFAEII/AAAAAAAAA2Q/Dl6b7bN-Jvs/s800/DSC_0199_DxO.jpg" /></a><br/><i>The Backs, Cambridge (18mm)</i></div><br /><br />Now here is the same scene at 10mm with the Sigma.<br /><br /><br /><div align=center><a href="http://picasaweb.google.co.uk/lh/photo/ft863pz-LPC6mrfS61VF_A"><img src="http://lh5.ggpht.com/alexander.david.john.brown/SMJWr4CPmjI/AAAAAAAAA2I/V1fixKRTzXc/s800/DSC_0198_DxO.jpg" /></a><br/><i>The Backs, Cambridge (10mm)</i></div><br /><br />Obviously one gets a lot more in with the wider lens, but this picture also serves to illustrate one of the big challenges of using a super-wide -- composition becomes much more challenging. Discovering the punts along the left hand side of the image was good, but the strip of field on the left adds nothing. A continual hazard of using very wide angle views is that one gets a load of extraneous junk in the edges of the picture. Photography guru Ken Rockwell has <a href="http://www.kenrockwell.com/tech/how-to-use-ultra-wide-lenses.htm" target="_blank" >recently written a fascinating piece</a>  in which he states the purpose of a super-wide is to get closer to the subject, rather than to &quot;get it all in&quot;, and he has some compelling images to support his case.<br /><br />Some other interesting things I found with life at 10mm:<br /><br /><ul>
<li>If the sky is at all interesting, you get full value</li>
<li>Distortion can be fun and dramatic, but if you aren't very careful to keep your horizon level you'll get some nasty distortion which is hard to correct</li>
<li>At tourist sites having a wider lense allows one to stand forward of everybody else taking pictures - nicer shots without flourescent anoraks in view</li>
</ul><br /><br /><h1>Distortion</h1><br />The Sigma 10-20mm is a relatively inexpensive lens, and has its faults including vignetting and all kinds of distortion. The end result is not helped when the person behind the camera (me) often fails to get the exposure just right. I use a  fabulous piece of software called <a href="http://www.dxo.com/intl/photo/dxo_optics_pro/exclusive_features/overview" target="_blank" >DxO Optics Pro</a> to help to compensate. The developers have analysed the optical performance of many camera/lense combinations (you have to specify what you have when installing the application), and using this data the application modules will automatically correct lense distortion when it processes images. It is also possible to correct for some geometric distortion by drawing parallel lines onto things in the source image which should be parallel. The results look pretty good to me and best of all the app seems to have the knack of adjusting brightness intelligently to rescue what might seem hopeless under-exposed or over-contrasty pictures.<br /><br />I wonder (heretical thought) if a cheapo lens and decent software outperforms more expensive optics -- it&#039;s not as if any super-wide lens is going to be optically perfect, after all ...<br /><br />
<div align=center>
<table><tr><td><a href="http://picasaweb.google.co.uk/lh/photo/jAv5Nz5W6A3WjE0Za6uQEA"><img src="http://lh4.ggpht.com/alexander.david.john.brown/SMJqnuWX13I/AAAAAAAAA4A/0or9tXfRbqk/s400/DSC_0278.JPG" /></a></td><td><a href="http://picasaweb.google.co.uk/lh/photo/9-gtMXSTdSyRz5NZldCoDg"><img src="http://lh6.ggpht.com/alexander.david.john.brown/SMJqlCo7wOI/AAAAAAAAA34/o07e5Nzfp6Q/s400/DSC_0278_DxO.jpg" /></a></td></tr></table>
<i>Back from the dead; badly exposed snap before and after processing. Notice automatic geometry correction too.</i>
</div>
<br /><br />
<div align=center>
<table><tr><td><a href="http://picasaweb.google.co.uk/lh/photo/yzHapgBTAuI-RtxiO7KXIg"><img src="http://lh4.ggpht.com/alexander.david.john.brown/SMJv-N65UBI/AAAAAAAAA4o/zsh-OK-9FM0/s400/DSC_0227.JPG" /></a></td><td><a href="http://picasaweb.google.co.uk/lh/photo/5iID80FsuZZayOFNhUZlog"><img src="http://lh5.ggpht.com/alexander.david.john.brown/SMJvNLFOc3I/AAAAAAAAA4g/vBMAgF8baAU/s400/DSC_0227_DxO.jpg" /></a></td></tr></table>
<i>Some more aggressive manual geometry correction and general sprucing of image.</i>
</div>
]]></description>
	</item>
	<item rdf:about="http://www.adjb.net/index.php?entry=entry080709-160624">
		<title>OOXML Appeal Synchronicity</title>
		<link>http://www.adjb.net/index.php?entry=entry080709-160624</link>
		<description><![CDATA[Groklaw has <a href="http://www.groklaw.net/article.php?story=2008070907285710" target="_blank" >published</a> a leaked ISO document to the web regarding the ongoing appeals over the 29500 project. Reading it, it is clearly not (as originally reported) the recommendation <b>of</b> the <a href="http://www.iso.org/iso/iso_technical_committee.html?commid=54996" target="_blank" >ISO TMB</a>, but recommendations <b>to</b> the TMB. The appeals process continues.<br /><br />Bearing in mind the fuss that was made about &quot;form letters&quot; earlier in the project, something new that immediately leaps off the pages is some common text in two of the appeals:<br /><br />From <a href="http://www.sabs.co.za/" target="_blank" >SABS</a> (South Africa; letter dated 22 May) :<br /><br /><div style="background-color:#ddf;padding:20px;">
we challenge the validity of a process that, from beginning to end, required all parties involved to analyze far too much information in far too little time, involved a BRM that did not remotely provide enough time to perform the appointed purpose of that procedure, and for which an arbitrary time limitation was imposed to discuss and resolve a significant number of substantial responses, despite the Directives not requiring any such limitation as to duration.
</div><br />From <a href="http://www.fondonorma.org.ve/" target="_blank" >FONDONORMA</a> (Venezuela; letter dated 30 May):<br /><br /><div style="background-color:#ddf;padding:20px;">
Venezuela challenges the validity of a process that, from beginning to end, required all parties involved to analyze far too much information in far too little time, involve a BRM that by far did not provide enough time to perform the appointed purpose of that procedure, and for which an arbitrary time limitation was imposed to discuss and resolve a significant number of substantial responses, despite the Directives not requiring any such limitation as to duration.
</div><br />Both NBs were asked to specify what specific remedial actions they were seeking and ISO got (among other things), from Venezuela (letter dated 23 June):<br /><br /><div style="background-color:#ddf;padding:20px;">
Change the title of DIS 29500 to "Converting legacy Microsoft documents to Office Open XML" in order to reflect the fact that it is only intended to convert such legacy documents and is not intended to conflict with ISO/IEC 26300. This change should be made to he scope of the DIS as well.
</div><br />and from South Africa (letter dated 24 June)<br /><br /><div style="background-color:#ddf;padding:20px;">
We request that the title of DIS 29500 be changed to "Converting legacy Microsoft documents to Office Open XML" in order to reflect the fact that it is only intended to convert such legacy documents and is not intended to conflict with ISO/IEC 26300 [...]
</div><br />As with the &quot;duplicate&quot; comments submitted in the 29500 letter ballot, it&#039;s difficult to know how this happened. Is one country copying the other, or is there a common source for both? One would have thought any self-respecting standards body would not brazenly crib the text of an appeal (an appeal!) from outside its own walls ...<br /><br />- Alex.]]></description>
	</item>
</rdf:RDF>

