Reputation
70,630
Next tag badge:
565/400 score
73/80 answers
Badges
5 170 391
Impact
~816k people reached

Feb
12
answered Problem With 3D Contour Plot
Feb
12
revised Problem With 3D Contour Plot
added 13 characters in body
Feb
12
comment Get Coordinates 4 significant digits limitation
@P.Fonseca It works for me if I use SetPrecision with anything except MachinePrecision (note the difference from $MachinePrecision which is a numerical value and will result in using Mma's built-in arbitrary precision with the same number of digits as machine precision---confusing? :-) Here's a piece of code to try: Plot[x, {x, 1950, 1950.002}, CoordinatesToolOptions -> {"CopiedValueFunction" -> (SetPrecision[#, 10] &)}].
Feb
12
revised Get Coordinates 4 significant digits limitation
added 1 characters in body
Feb
12
comment listplot very large numbers
@DaoTRINH Good point. I don't know if it auto-compiles or not. But it also has the WorkingPrecision option, so it can work with arbitrary precision arithmetic, even if it doesn't by default ... This comes useful as a simple brute force solution when there's some cancellation in the formula that eats up precision.
Feb
12
comment Importing a Canon Raw file (.CR2)
@Jon If you want to avoid TIFF files and want better integration, then the way to go is what rhermans said. Use libraw through LibraryLink. That should be straightforward, but quite a bit of work. If you do decide to go down that path, you can consider integrating it into the import/export framework for convenience. This will give you a solution of the same quality and convenience as built-in importers.
Feb
12
comment Importing a Canon Raw file (.CR2)
@rhermans libraw is pretty much the same as dcraw. Yes, it's possible to call it through MathLink or LibraryLink too, it's just going to be a lot more work than calling it through the command line (i.e. dcraw) and in the end it will achieve pretty much the same thing. It's really not clear to me if the OP is asking to achieve something, or to achieve something in a particular way.
Feb
12
comment Make Sinc'[0] return 0 instead of Indeterminate
@Rojo People would complain that "it's not computed". Maybe it could be forced using FunctionExpand ...
Feb
12
comment Make Sinc'[0] return 0 instead of Indeterminate
... in a mathematically correct way, and it's not difficult to see why. Since Piecewise won't give us proper derivative, it doesn't make a lot of sense to return a piecewise for Sinc'[x]. It would just delay the problem until the next derivative. OK, this is somewhat subjective, but after thinking this through I start to accept why they might have consciously made the decision not to both with Sinc'[x] in x=0. My point is that while they could have implemented Derivative[n][Sinc][x] to return a correct Piecewise for any n, taking another derivative of that result would fail anyway.
Feb
12
comment Make Sinc'[0] return 0 instead of Indeterminate
@Rojo I played a bit with piecewise functions and I think I know why this is not feasible: suppose the derivative were returned as a piecewise. Actually we might as well start from sinc[x_] := Piecewise[{{Sin[x]/x, x != 0}}, 1]. The mathematically proper derivative of Sinc should be what sinc'[x] returns. But now let's take the derivative of this once more: D[sinc'[x],x]. This will be a piecewise that's still 0 in the point $x=0$. However the actual second derivative sinc''(0) should be -1/3. This illustrates how Piecewise itself is unable to handle derivatives ...
Feb
12
answered listplot very large numbers
Feb
12
comment Make Sinc'[0] return 0 instead of Indeterminate
@Rojo Techinically it's true that the derivative should be Piecewise[{{..., x!=0}, {0, x==0}] but since it's a single point only it's not exactly a unique situation in Mma ...
Feb
12
comment Slider with non-linear behavior
On OS X pressing Shift+Options (I guess Shift+Alt on other systems) makes the slider move even slower. I can almost control the 5th digit after the decimal point in a range of (0, 1) like this.
Feb
12
comment Get Coordinates 4 significant digits limitation
This is quite strange. Note that if you use MachinePrecision instead of $MachinePrecision then it does not work.
Feb
12
comment Importing a Canon Raw file (.CR2)
@OleksandrR. Yes, only those are interesting, and it takes a bit of luck to catch them. Just orient the sensor vertically and take a few long exposure pictures in bulb mode. Sometimes there'll be a tiny line on the image, still less than a millimeter long probably.
Feb
11
comment Importing a Canon Raw file (.CR2)
@OleksandrR. ... and obtain a usable image! Because as you said that's both non-trivial and needs camera-specific data that's guarded by the manufacturer.
Feb
11
comment Importing a Canon Raw file (.CR2)
@OleksandrR. The bad pixel map and non-uniformity is corrected for already, but to produce a properly converted image afterwards you're right that you need the curves. Actually there are good reasons for reading the raw data. I used it for two things: looking at cosmic ray tracks (I needed non-demosaiced data) and for banding noise reduction. My camera has a pretty annoying banding at high ISO settings ... and I did manage to improve on it by tailoring the method for this particular camera. But I couldn't put back the de-banded data into a RAW file so I can use a proper RAW converter ...
Feb
11
revised Importing a Canon Raw file (.CR2)
added 16 characters in body
Feb
11
comment Importing a Canon Raw file (.CR2)
Also, while I haven't worked with CR2, the situation is probably similar to Nikon NEFs: Nikon doesn't document their RAW file format. Though it's TIFF-based, there's enough difference that you can't get usable data with a TIFF reader in a simple way. If you're a company like Adobe who wants to include NEF support in their software, you need to use the NEF SDK from Nikon, which you will gain access to only after approval. Otherwise you'll have to reverse engineer the format on your own like the dcraw people did.
Feb
11
comment Importing a Canon Raw file (.CR2)
@Jon I don't really understand what you are trying to do then. There's a simple way to get all the data into Mathematica, by using an external utility. Why are you looking for a complicated way to do the same without this utility? You'd just end up rewriting parts of dcraw. If you need decent performance, you'd probably end up rewriting it in C and using it through LibraryLink. There's no built-in way to read any of the myriads of RAW file types in Mathematica.