[desktop-discuss] LSARC/2008/058 - dcraw

[Brian Nitz]

I agree that frequent updates to capture new formats are something we 
should strive for.  Such a simple single source program could be a good 
test case to clear some crud out of the plumbing of Sun's processes and 
speed things up.

But I'm not convinced frequent updates absolutely crucial to the 
usefulness of dcraw.  It still reads the formats for a majority of 
existing cameras out there as well as Adobe's DNG (some of us have 
cameras dating back 5 or 6 years which can write RAW format(s).   I'd be 
interested in hearing about new cameras the latest dcraw doesn't support. 

What I'm more concerned about is the potential for stepping on someone 
else's IP when companies such as Sony and Nikon seem to be intentionally 
"encrypting" their white balance channel so you have to use their 
software.  If there are IP risks or format change intended to break 3rd 
party image readers, it might be safer to drop support for these brands 
even though I'm sure it will lead to complaints.

John Plocher wrote:
> In other words, this should go into a repository that Solaris users can
> easily update from, and the project team needs to commit to updating that
> repository on an agressive and proactive basis.
>
> Sounds like we (Sun/ARCs) need to better understand the repository 
> model(s)
> being contemplated here.  If only we had an ARC case for them... :-)
>
>    -John
>
>
>
> Lloyd L Chambers wrote:
>> As an avid photographer (diglloyd.com),  I'll weigh in here--
>>
>> 1.  Unless Sun provides frequent and regular updates automatically to 
>> support the latest digital cameras, including 'dcraw' in Solaris is 
>> likely to disappoint--new cameras are released on a constant basis, 
>> and a RAW-file converter must be constantly updated to keep pace.  
>> IMO, 'dcraw' seems inappapriate for Solaris, unless there is a plan 
>> in place to keep pace on the latest cameras.
>>
>> By way of comparison, Apple provides RAW support in Aperture, Preview 
>> and internal libraries, and they have to issue an update once a 
>> quarter or so.  Right now, I have a new camera, and it's not yet 
>> supported (though it soon should be).  This becomes annoying; any 
>> tool that isn't aggressively updated gets abandoned.
>>
>> In short, failure to aggressively update raw-file processing software 
>> frequently leads to it being out of date within a year.  To me, 
>> that's *much* more important than concerns about whether the 
>> interface is 'volatile' or something else--a square peg in a round 
>> hole issue IMO.
>>
>> Bottom line:  unless we have a team committed to frequent and regular 
>> updates, I vote against seeing this included in Solaris *at all*.
>>
>> I could be persuaded otherwise provided that there is a *funded* and 
>> well-articulated plan for aggressively keeping 'dcraw' current.
>>
>> Lloyd
>>
>> Lloyd L Chambers
>> lloyd.chambers at sun.com
>> LSARC
>> Sun Microsystems, Inc
>>
>> On Jan 30, 2008, at 5:34 AM, James Carlson wrote:
>>
>>> John Plocher writes:
>>>> Danek Duvall wrote:
>>>>> Perhaps we could keep track of these interfaces...
>>>>
>>>> If you are going to do all that, why not just do a contract - it is
>>>> just as much work, plus it is a well known mechanism.
>>>>
>>>> (I, too wish there was a better way...)
>>>
>>> I agree with John.  I'll also go further to say that asserting that
>>> because a project exports only Volatile interfaces it's somehow
>>> specially eligible to import Volatile as well is a syntax error.  It
>>> seems to belie a "FOSS == no review" scheme that just doesn't exist.
>>>
>>> We don't evaluate dependencies based on the stability of interfaces
>>> provided by a project.  We evaluate them based on the consolidations
>>> across which the dependency exists.
>>>
>>> In other words, better ways to deal with this issue are:
>>>
>>>   - Just raise the stability level of the library to an appropriate
>>>     level, given the consumers involved.  It's not as unstable as
>>>     asserted.
>>>
>>>   - Create a contract; it's how we enumerate consumers who will be
>>>     damaged by unexpected changes.
>>>
>>>   - Put them in the same consolidation and treat the dependency as
>>>     effectively Consolidation Private ("Volatile friends with
>>>     benefits").
>>>
>>> -- 
>>> James Carlson, Solaris Networking              
>>> <james.d.carlson at sun.com>
>>> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 
>>> 2084
>>> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 
>>> 1677
>>
>> ---
>> Lloyd L Chambers
>> lloyd.chambers at sun.com
>> Sun Microsystems, Inc
>>
>>
>>
>