Roman Lebedev wrote:

> Hi all.

Hello dev's, 

please find attached some thoughts about the planned deprecation.

> This mail is primarily targeted to all the owners of Nikon cameras.

bunch of them in the last decade, actually two.

> As you may have seen, an issue with white level for some
> nikon cameras (or so i thought) was discovered by me:

great. really! 

> In the meantime i have adjusted white levels for all the cameras i
> could find samples for.

great. thx a lot. 

> But unfortunately, for some cameras i was unable to find samples.
> Below, you will find a list of all the cameras for which i need
> samples.
> IMPORTANT: if you see your camera in that list, it is imperative for
> you to provide
> a sample set, or else your camera will not be supported in next
> darktable release!


found D70 is on the way. 
hope the best for others.

kind regards
# announced NIKON depreciation is a no-go

## first info

From: Roman Lebedev <>
To: darktable-user <>,  darktable <>
Subject: [darktable-dev] PSA: ATTENTION NIKON OWNERS !!!
Date: Fri, 7 Oct 2016 16:00:48 +0300

or else your camera will not be supported in next
darktable release!


## why using open-source software

because it's sustainable. maybe not perfect. but good enough
1. First question for using a Digital Camera: is it in dcraw?
2. Second: always use RAW. Nothing else.

D70 raws from 2005? __NO Problem__. The camera has long gone.

## which software

* [dcraw]( the reference
* [ufraw]( always with me, even on 7year old netbook
* [darktable]( for work. and fun. and ...  (99% used)

# Confusion

## who is informed
* darktable-user
* darktable-dev

## who is not informed (maybe the other 98%)
* users of any distribution where some more-or-less actual version of darktable is provided

## what will happen if a dumb user updates a +0.0.1 version?
* backward incompatible changes will be introduced. (for darktable normal and accepted behaviour)
* loosing silently old pictures. ymmd.
* no easy rollback. depends on the time when you realize the breakage.

## and what happended to a git user
* #@!^^# in gui:
* failed to read camera white balance information from '2005...nef'  'working..' (stale)
* showing the skull icon after reentering lighttable

* only seen because started on command line:

[rawspeed] (20050507-15004070-NIKON_D70.nef) Camera not supported (explicit). Sorry.
[temperature] failed to read camera white balance information from `20050507-15004070-NIKON_D70.nef'!
[temperature] `NIKON CORPORATION NIKON D70' color matrix not found for image
[temperature] failed to read camera white balance information from `20050507-15004070-NIKON_D70.nef'!
[temperature] failed to read camera white balance information from `20050507-15004070-NIKON_D70.nef'!
allocation failed???


# Conclusion
i'm bored and disappointed. sorry.

# whats next

## taking a look at [semantic versioning](

whatever API means. (supported cameras, modules, xmp, database(es))
where database is more internal, could be regenerated out of xmp's.

Given a version number MAJOR.MINOR.PATCH, increment the:

    1. MAJOR version when you make incompatible API changes,
    2. MINOR version when you add functionality in a backwards-compatible manner, and
    3. PATCH version when you make backwards-compatible bug fixes.

point 7. for marking something deprecated ...
and then wait an amount of time i.e. one or two releases.
point 8. for introducing incompatible changes

my feeling: always all released versions shoud have been major? j/k

## giving a valuable feedback to the user
* version has to introduce a deprecation message when database of user shows findings
  (for ex: sql-ing for known cameras and give a big bummer on screen and log to provide raw files)

* keep non-optimal whitebalance stuff. better than to nuke. maybe mark previews.

Attachment: pgpUmd4xMc0v5.pgp
Description: OpenPGP digital signature

Reply via email to