Add camconst support for foveon files

[Beep6581]

Originally reported on Google Code with ID 2729

This patch adds camconst support for foveon files.
Ilias, could you add the camconst entries for the foveon cams please?

Ingo

Reported by heckflosse@i-weyrich.de on 2015-03-30 17:13:41

---

• _Attachment: camconst_foveon.patch_

[Beep6581]

Greetings Ted

To create a color profile for your camera I need an in-focus shot of a color chart
covering about 1/3rd of the frame from the center, without clipping, and I need information
about what chart it is you're using. If you have more than one chart, use the one with
more patches.

I cannot use any of the 6 CC24 shots you provided because even the darkest brackets
of both SD9 and SD10 versions are still very clipped in the light squares (at least
according to RawTherapee, which is the only program I can open them in) and the SD10
shot is badly out of focus.

Reported by entertheyoni on 2015-04-21 20:29:09

[Beep6581]

Re: #110

Hello,

I'm hesitant to respond because I know what a "yoni" is and, therefore, what "enter
the yoni" means.

Can't post any more card shots for the SD10, I've removed the hot mirror. As to the
chart I used, what more information is needed? I thought CC24 meant the Macbeth/x-rite?

Why must they be in focus? I deliberately made them slightly OOF to get more homogenous
color in the patches. Adobe's DNG editor had no trouble with that, back when I used
it. What are you using?

If you download Sigma SPP 3.5.2 you will be able to produce better images for color-profiling.

In any case, I'll be unable to do anything right now because my main computer died
and I'm trying to recover stuff to a spare computer as we speak.

Ted

Reported by xpatUSA on 2015-04-21 20:55:29

[Beep6581]

entertheyoni, try to set the SD9 clipping value at 8900, or the white-point correction
at 0.50 (under Raw White Points menu), as you prefer. Neither lamp-0.5EV.X3F nor sun0EV.X3F
are clipped at all and are reasonably sharp.

Reported by rnbc.r0 on 2015-04-21 22:44:13

[Beep6581]

Ted, the info needed for your cc24 chart is about it's geometry i.e patches vs dead
space analogies, which are different than x-rite passport's and the new x-rite cards,
because I cannot make agryll scanin to recognize the patches. http://www.argyllcms.com/doc/cht_format.html
Ideally there should exist a "old_cc24.cht" describing your card's geometry. Or we
have to build this cht file after measuring .. or use rawdigger but then we have to
decrypt the difference in decoding vs RT ..

For the in or out o focus .. if a target has scatches or dirt then by shooting in focus
we give to the profiling software the opportunity to exclude the outliers easily. If
it is blurred (OOF) then the defect area is spread and mixed with the useful area and
so harder to be recognized as outlier and excluded. I believe every sane profiler uses
robust methods to remove outliers .. 

DrSlony, I have preliminary camconst.json entries for SD9/10 just wait a bit to crosscheck
with the data dumps (Ted provided some) to declare a better WL, although I am afraid
that it varies strongly from shot to shot .. the color matrix is preliminary, built
using wrong BL I think

    { // Quality c, corrections for frame size, black and white levels not declared
properly
        "make_model": "Sigma SD9",
        "dcraw_matrix": [ 14996,-3468,-1425,5576,3642,972,1761,3773,3720 ], // experimental
calculated from sun0.icc data
        "ranges": { "black": 15, "white": 8050 },// black is already subtracted by
dcraw, white copied from x3dump data 
        "raw_crop": [ 20, 8, -18, -12 ]
    },
    { // Quality c, corrections for frame size, black level not declared properly
        "make_model": "Sigma SD10",
        "dcraw_matrix": [ 12555,-1865,-1125,5093,4120,867,1929,3810,3507 ], // experimental
calculated from .icc data
        "ranges": { "black": 0, "white": 5960 },// black is already subtracted by dcraw,
white copied from x3dump data 
      //  "raw_crop": [ 0, 0, -0, -0 ] // for temporary use to see and measure the
full frame 
       "raw_crop": [ 20, 8, -18, -12 ]
    },

Ingo, by the LUT you provided I understand that max value can be up to 32766 for SD14
!!. 
BTW this is somehow a σδ encoding .. we should expect this from Sigma :)

These old Sigmas look more complicated that Merrills !! and Dcraw's behavior is different
.. The Black Level look to be already subtracted (let hope its correct..) while the
White level is reported at 4095 which is wrong :( 

Reported by iliasgiarimis on 2015-04-22 00:28:58

[Beep6581]

re: #122 Ilias

Ted, the info needed for your cc24 chart is about it's geometry i.e patches vs dead
space analogies, which are different than x-rite passport's and the new x-rite cards,
because I cannot make agryll scanin to recognize the patches. http://www.argyllcms.com/doc/cht_format.html
Ideally there should exist a "old_cc24.cht" describing your card's geometry. Or we
have to build this cht file after measuring .. or use rawdigger but then we have to
decrypt the difference in decoding vs RT ..

For the in or out o focus .. if a target has scatches or dirt then by shooting in focus
we give to the profiling software the opportunity to exclude the outliers easily. If
it is blurred (OOF) then the defect area is spread and mixed with the useful area and
so harder to be recognized as outlier and excluded. I believe every sane profiler uses
robust methods to remove outliers .."

Then I can not help further, sorry.

"DrSlony, I have preliminary camconst.json entries for SD9/10 just wait a bit to crosscheck
with the data dumps (Ted provided some) to declare a better WL, although I am afraid
that it varies strongly from shot to shot .. the color matrix is preliminary, built
using wrong BL I think

    { // Quality c, corrections for frame size, black and white levels not declared
properly
        "make_model": "Sigma SD9",
        "dcraw_matrix": [ 14996,-3468,-1425,5576,3642,972,1761,3773,3720 ], // experimental
calculated from sun0.icc data
        "ranges": { "black": 15, "white": 8050 },// black is already subtracted by
dcraw, white copied from x3dump data
        "raw_crop": [ 20, 8, -18, -12 ]
    },
    { // Quality c, corrections for frame size, black level not declared properly
        "make_model": "Sigma SD10",
        "dcraw_matrix": [ 12555,-1865,-1125,5093,4120,867,1929,3810,3507 ], // experimental
calculated from .icc data
        "ranges": { "black": 0, "white": 5960 },// black is already subtracted by dcraw,
white copied from x3dump data
      //  "raw_crop": [ 0, 0, -0, -0 ] // for temporary use to see and measure the
full frame
       "raw_crop": [ 20, 8, -18, -12 ]
    },

Ingo, by the LUT you provided I understand that max value can be up to 32766 for SD14
!!."

I share your incredulity. I have just acquired another SD14, BTW. My other SD14 was
about the 9,000 mark almost saturated so where on earth does that number come from?

"BTW this is somehow a σδ encoding .. we should expect this from Sigma :)"

What?

"These old Sigmas look more complicated that Merrills !! and Dcraw's behavior is different
.. The Black Level look to be already subtracted (let hope its correct..) while the
White level is reported at 4095 which is wrong :("

In the context of this thread, I remain puzzled by all these references to black points/levels
and white points/levels - especially when "white levels" i.e. saturation levels are
given in the X3F meta-data for each camera (yes, different for each individual camera).

As to the cam-XYZ matrices, they are different in meta-data for each individual camera
(not model) so is there some sort of problem in using those values instead of trying
to dream up some arbitrary one-size-fits-all matrix per model? Every time I mention
this, it gets ignored.

5960 does appear to be in the ball-park (blue is 5970 on mine) but each layer has a
different value . . . of course! :-)

Ted

Reported by xpatUSA on 2015-04-22 00:56:24

[Beep6581]

Ted,

"What ?" ... ΣΔ .. http://en.wikipedia.org/wiki/Delta-SIGMA_modulation :)

- If we could rely on constants for BL/WL it would be less work for Ingo, so we had
to investigate this first ..
- Same with the per camera-body matrices, it's easier if we can use a constant ..
- I used the lowest of the three saturation levels, no need for per channel WL as the
difference is very small (0.02 stops). 

BTW is there any chance for x3f experts to give a hand in understanding/documenting
the x3f tags ?.

Reported by iliasgiarimis on 2015-04-22 01:21:13

[Beep6581]

@Ilias, I'll have a look at the tags in about 2 weeks.

@Ted, 'by the LUT you provided I understand that max value can be up to 32766 for SD14
!!.'

No, you have to be able to get back to 0 in one step. Because the min value is -16384
the max value is 16384. Whether this value is used in practice, I don't know.

Ingo

PS: From Thursday on I'm away for about 10 days.

Reported by heckflosse@i-weyrich.de on 2015-04-22 09:31:07

[Beep6581]

Reiner, sorry for the late response

"I think it is better that I am prepared for the test to minimize the number of files.
So I need your help for the test setup. First I will be limited to sunlight and a 1EV
stepping from -14EV to -2EV then 1/3EV stepping to +2EV relative to the guessed clipping.
Do you think FW is important? Which type of lens range is the best? You can inspect
the cams and lenses on my dpreview profile (rf-design)."

For a good start it will be nice to have ..
- black frames (One per ISO, but you can start with only basic ISO) i.e lens cap on,
small aperture, fast shutter speed, dark enviroment 
- "white frames" i.e. a flat featurless target, out of focus, +5EV overexposed so all
pixels are clipped
- passport shots using the 1/3 central width/height. As the less noisy the shot the
best statistics can be gathered use the best ETTR possible. The easiest is to bracket
0,+0.5,+1.0 (0 is the camera's auto exposure values). Use a relatively long lens at
around f/8 for less vignette and casts.  

For the passport shots at the frame's periphery, at present it's just an idea but we
could experiment mixing 2-3 renderings (one by the central icc + midspace_icc + corner_icc)
if some shots are available. For easier detection it's best to use wide lens with short
Exit pupil distance, at wide aperture, to trigger a lot of color cast ..
I am still not sure if it will be better than simply use the flat field method .. 
In anyway this will be a difficult way to characterize the various foveons and may
also difficult maths (for me at least) needed .. 

@ Ingo, it was me who guessed the 32766 possibility :)  

Reported by iliasgiarimis on 2015-04-22 11:40:08

[Beep6581]

@Ilias and Ted, sorry for confusion

Reported by heckflosse@i-weyrich.de on 2015-04-22 11:45:54

[Beep6581]

The LUT for the SD14 looks really weird, because the sensor won't go above 6000-7000,
so most values are unused... mine goes to 6900 or so, for all channels, but data above
6700 is basically non-linear junk.

I presume they calibrate each camera at the factory and derive the matrices, but the
difference between cameras isn't that big: I have two SD14s from different batches
and they look the same. I don't think this is an issue in practice.

White point: I guess the difference between 6700 and 5970 isn't that big: only 0.17
EVs... Perhaps make it 5900 to be on the safe side? Can you retest your camera? I don't
know... perhaps there should be a warning for the user of those cameras, "your mileage
may vary"... LOL

About one frame per ISO: these cameras have no hardware ISO! The only ones featuring
hardware ISO are the SD15 and maybe the DP1/DP2. Those that say "AFE" or Analog Front
End, in the spec sheet, have hardware ISO, all the others don't. The SD1 Merrill has
no hardware ISO also, as far as I can see from mine.

About the SD1 color at the periphery: I'll try to get some more samples for the SD1
Merrill soon, but this color difference depends strictly on the lens and aperture,
so can't be corrected universally. For example, on my telescope (1000/f5 newtonian)
there is no color cast, while the an old 50mm f/1.4 Pentax the color cast is horrible
at f/8 but non-existent at f/1.4! Sigma lenses tend to have their exit pupils far away
from the sensor, so the color casts aren't horrible to start with. Oh well...

Reported by rnbc.r0 on 2015-04-22 12:27:37

[Beep6581]

@Ingo

Re the SD14 look-up table, I did not provide it. But, while on the subject, may I suggest
that the values are not signed but represent unsigned 16-bit data?

@rnbc

Re the SD14 sensor actual saturation values (not the tag values, I think it is importance
that we identify which is correct - RawDigger or DCraw or your method.

My SD14 definitely saturates at around 9,000 as I've already said here, but you're
still stating 6,700 in spite of that.

Either RawDigger is wrong or your method is incorrect and this forum should discover
which, there being about 1/2 EV difference.

As to experts on X3F tags, I am no expert - but, over on DPR, Iliah Borg, ArvoJ and
Roland Karlsson seem to know a bit.

@Reiner

Perhaps I am being too picky about matrices - I agree that one per camera model will
work well enough. As to black levels and white levels, I've mouthed off about that
enough already.

Reported by xpatUSA on 2015-04-22 15:57:56

[Beep6581]

@Ted, the values are signed. I can point you to the part of dcraw source where they
are used in case you're interested. And the way they are used, p(n+1) = p(n) + lut(x),
doesn't make sense with unsigned values.

Ingo

Reported by heckflosse@i-weyrich.de on 2015-04-22 17:27:16

[Beep6581]

xpat, apparently different SD14s saturate at different levels... yours is 9000, mine
is 6900, others are 5900. This makes it trickier to support this camera.

Reported by rnbc.r0 on 2015-04-22 18:28:45

[Beep6581]

Thanks, Ingo, pardon my ignorance. No need to point to any dcraw code, I can't read
it.

best regards,

Ted

Reported by xpatUSA on 2015-04-22 18:29:47

[Beep6581]

re #122, when I'm back I'll have a look how to get all the values from metadata of x3f
files (for most of them I can have a look at dcraw code). That will make it easier
to do it right.

re #123, no problem.

Ingo (back in 10 days)

Reported by heckflosse@i-weyrich.de on 2015-04-22 18:49:49

[Beep6581]

@rnbc

Re:xpat, apparently different SD14s saturate at different levels... yours is 9000,
mine is 6900, others are 5900. This makes it trickier to support this camera.

Please call me Ted. Please post a saturated X3F from your SD14 and tell what your numbers
are. I'll open it in RawDigger and post the histogram. In spite of your own experience,
I've had 3 SD14s and they all saturated around 9,000 - so this test should tell us
something instead of batting numbers back and forth . .

Ted

Reported by xpatUSA on 2015-04-22 19:04:59

[Beep6581]

issue2729_07.patch committed to revision c318a74f6b4a
Issue stays open

ingo

Reported by heckflosse@i-weyrich.de on 2015-04-22 20:16:51

[Beep6581]

Re: #125

It looks like I've been fooled by outliers in the RawDigger histogram. The outliers
exist and, because I've looking at the max values only, I was fooled by these numbers.

So, @rnbc, further testing is not needed. I've just done some sky shots with the SD14
and it looks like peak saturation value for that camera is 6825 out of 4 shots and
the 3 channels.

Sorry for any confusion caused. I investigated because a shot that took earlier today
had a max value of over 14,000 which is ridiculous for an SD14.

regards,

Ted

Reported by xpatUSA on 2015-04-22 20:49:41

[Beep6581]

Here are burned samples from both my SD14s:

http://rnbc.dynip.sapo.pt/pub/x3f-examples-03/

Camera "b/01015276" is basically new from factory, having maybe 200 shots in total
(anyone wants to buy it? :D)... and is much newer than camera "a/01007259", which has
33000 shots.

They are fro different batches, up to the point where the infrared sensors were different:
the one in the older camera had no coatings, and the newer one has anti-reflection
coatings. Eventually I got another for the older one because sometimes it created reflections...

As you can see camera "b" goes up to 6720 and a few more. Camera "a" goes up to 6800-7000.
But to be on the safe side of things I would stay at 6500 maximum, because detecting
saturated zones in the sensor is critical for rawtherapee highlight recovery functions.

Reported by rnbc.r0 on 2015-04-22 22:29:25

[Beep6581]

So Ted and others, do we all agree SD14 white point is about >6500 and SD1/M white point
is about >4000 or so? Or are there any samples that dispute this? (Please put them
online!)

PS: call me Rodrigo, btw :)

Reported by rnbc.r0 on 2015-04-22 22:51:54

[Beep6581]

re: #129

@Rodrigo:

Yes, your SD14s are 6850 and 7150 saturated, see links below.

My SD1M was 4070 (good number without outliers) in RawDigger, so I agree with all that
you've said this time :-)

SD14 histograms:

http://kronometric.org/phot/xfer/Issue%202729/SD14/SDIMa_32977_burned.png
http://kronometric.org/phot/xfer/Issue%202729/SD14/SDIMb_00008_burned.png

saludos,

Ted

Reported by xpatUSA on 2015-04-23 00:47:27

[Beep6581]

Ted and Rodrigo, many thanks for the samples etc.

Just confirmed that for SD14 the Black Level has been subtracted somehow, and at exactly
the level one can measure at the optically shielded top and bottom areas so no need
to use "black" in camconst.json.

(I use RT's "save ref. image" with WB unchecked, and then Guillermo's Histogrammar
to take RT's decoding stats )  

The safe (left end of the distribution) White Level is at around 6700 as Rodrigo already
detected, but I don't know why the "saturation" value at the metadata is lower !!.
I am inclined to use the metadata as the difference is small.

I will continue tomorrow with building icc profiles based on the correct BL/WL data
for SD9/10/14 .. 

Reported by iliasgiarimis on 2015-04-23 21:19:08

[Beep6581]

Re: #131,

Reiner, I've uploaded 3 meta-data dumps from three different SD14s here:

http://kronometric.org/phot/xfer/Issue%202729/SD14/SDIM5815.X3F.txt
http://kronometric.org/phot/xfer/Issue%202729/SD14/SDIMa_32977_burned.X3F.txt
http://kronometric.org/phot/xfer/Issue%202729/SD14/SDIMb_00008_burned.X3F.txt

Also the utility by Arvo Jagel for dumping meta-data but excludes large sections like
linearization:

http://kronometric.org/phot/xfer/Issue%202729/SD14/X3Dump.exe

runs on Windows XP, can't guarantee it in any way. Simple command line interface

X3Dump [path\filename.X3F]

Ted

Reported by xpatUSA on 2015-04-23 22:00:48

[Beep6581]

> [...] I am inclined to use the metadata as the difference is small.

Just a stupid question: What are the values from metadata? I see a lot of "max" in
there... it's a bit confusing :)

Candidates:

- MaxOutputLevel (around 3000, seems too low)
- RawSaturationLevel (around 3000, seems too low)
- SaturationLevel (almost 8000 in one sample, around 6000 in the others... smells fishy,
but might be this one... :P)
- DBG_MaxRGB (same as above?)

If it's SaturationLevel/DBG_MaxRGB, it seems ok for my 2 SD14s, if a bit conservative.
Anyway, it's only 1/6 of EV to hard clipping. Probably the sensor wasn't linear enough
above those levels for Sigma's engineers taste :)

Reported by rnbc.r0 on 2015-04-23 23:16:13

[Beep6581]

#131, Thanks Ted, I already used X3Dump yesterday .. works fine on my win vista32 ..

#132, Rodrigo yes, this "saturation level" looks to match better with the raw histograms
.. although it's around 15% lower than what is supposed to be safe .. but maybe it
is so conservative to cover any sensor's non homogenuities which may appear at the
periphery .. your lamp only covers the center area ..

Reported by iliasgiarimis on 2015-04-24 00:00:06

[Beep6581]

# 133, Rodrigo, I think the problem with the clipping is more complicated. In addition
to analog clipping of source follower in the chip and the ADC, which i think is very
similar over the channels, there is a nonlinearity in the charge over voltage curve.
This will depend on the specific implant profile and change from wafer to wafer and
also with a wafer. The diode components responsible for this effect are modeled in
spice as VJ and MJ and define a nonlinear capacitance over voltage

CJ=CJ0/(1+V/VJ)^MJ

If you integrate the capacitance over voltage you will get the charge over voltage.
So each sensor will have a different nonlinear curve. I saw in the past a reenginering
where the output voltage of sensor is recorded with a digital scope and a gray scale
is used. I did not had the data for the gray scale but it seems that resulting staircase
also show this kind of nonlinearity. To be exact all three diode layers will be different.
Not using a counteracting "Linearization" will simply loosing SNR.

The seond issue is that the color transformation will change the clipping for the target
color space. So a clipping and color restoration for one color space fail for the other.
Up to now I do not have a clue how that should work in detail but I think the there
should be clipping in the layer space and a second color space transformation into
the target color space with the layer clipping values. Then the clipping algorithm
could use all informations for restoring. I did not study source code for clipping
and color restoring to judge hwo useful thsi kind of preserving the layer clipping
is but that is my first thought.

I got the 2 colorcharts but on weekend it will be rainy. The Novoflexar 3.5/35mm on
a M42 adapter have a aperture position which is seems to have the shortest distance
to the sensor. The bad thing is that it is not supported by SPP so I could not make
a comparison. So my question again is which lens from my profile (dpreview) seems to
be the best to stretch the color cast.

Reported by reiner@rf-design.de on 2015-04-24 10:56:29

[Beep6581]

We don't really know the electronics in those sensors... so this is speculation.

What I can tell you, from some chipworks analysis, is that the latest Merrill sensors
are completely different from the earlier designs. Less components per pixel, much
more sharing between layers... the earlier designs used a lot more components per pixel.

There is probably some non-linearity in the sensor, but remember: we don't need perfection!

Reported by rnbc.r0 on 2015-04-25 03:36:17

[Beep6581]

# 135 Reiner, if it's rainy you can start with tungsten I suppose ..

About the lens that is the most problematic for periphery (and not only ..) casts I
think it's not the focal length that triggers it but the short "Exit pupil distance"
which is not easy to find :(

Take a look at the table at the bottom http://www.lensrentals.com/blog/2014/06/sensor-stack-thickness-when-does-it-matter
and Brian Caldwell's suggestions how to measure http://www.dpreview.com/forums/post/54408600

Reported by iliasgiarimis on 2015-04-25 09:36:56

[Beep6581]

Once it's sunny and clear sky I'll take some more samples with the SD1-Merrill.

According to meteorology, not for the next 10 days... there is some sun, but it has
been quite cloudy, or sometimes high clouds. Typical over here in April-May...

Do you also need tungsten?

I had already posted both types of samples, but apparently the sunny one had some issues
with color casts.

Do you also need more samples of the SD14 also?

Thanks.

Reported by rnbc.r0 on 2015-04-27 09:13:45

[Beep6581]

I will review all presently available to me samples later today and report if and what
is needed ..

Reported by iliasgiarimis on 2015-04-27 12:56:07

[Beep6581]

Short Status on the ColorCast Angle

I take a look on various lenses for Sigma SA and most of them have a pupil exit more
than 23mm from the flange which is itself 44mm from the sensor.

The only exeption which I found is the 3.5/8mm fisheye with 15mm. The 2.8/10mm fisheye
is about 25mm.

Sigma SA Lenses
3.5/8mm - 15mm
2.8/100mm - 36mm
2.8/50-150mm - 45mm(50mm)

M42-Adapter-Lenses
Noflexar 3.5/35mm - 2mm (3.5-16) 9 blades
Auto Exakta 2.8/35mm -13mm (3.8-22) 5 blades
Jena T2.8/50mm - 6mm (2.8-22) 5 blades

So to compare the effect of color cast versus pupil exit angle I select the Sigma 50-150mm
at 50mm and the Jena 50mm.

The angle is then

>> (180/pi)*atan((sqrt(16e-3^2+24e-3^2)/2)/(44e-3+45e-3))
ans =  9.2046

and

>> (180/pi)*atan((sqrt(16e-3^2+24e-3^2)/2)/(44e-3+6e-3))
ans =  16.090

with the same focal length of 50mm. The color cast is also reported stronger for non-supported
lenses which are typical from the analog age. I think that the DC/DG lenses are not
only restricted to the 44mm flange but are specific designed to have pupil exit more
than 67mm away.

Because of these effects I expect that the color cast compensation for DP models is
much stronger and that also finaly after compensation there is a often observed color
difference between SD and DP foveon. Possible a reason to have fixed lens for DP models.

Reported by reiner@rf-design.de on 2015-04-28 21:03:43

[Beep6581]

I agree but let's be practical over here: we are not dealing with a spectrometer. We
only have 3 channels to work with, so not much spectral resolution :D And we know they
are differently attenuated depending on incoming light angle. That can be somewhat
solved with a flat frame... and it depends on exit pupil distance and aperture. I can't
see much more being done about it. Maybe some non-linear residual transformation also,
but not much more. A flat frame solves probably 90% of the problem, or otherwise I
suspect we are in big trouble :)

Reported by rnbc.r0 on 2015-04-29 01:56:10

[Beep6581]

re #141
Rodrigo, I do not have enough experience to judge the amount of function to compensate
the colorcast. I only collect arguments to be prepared for experiment. Spectrometer
grade processing is not my talk because we have only 3 channels to process. To understand
the color shift a spectral function is needed and if exercised proper would also give
the amount of color shift as well as the required correction function before an experiment.
But we do not know the wavelength dependend reflection and the microlens design. If
for instance a sufficient correction is bilinear interpolation of two color transformation
matrices, one for the center and the other for the corner, the code to implement the
correction is far lower than all discussion, setup, experimentation and extraction
here.

BR Reiner

Reported by reiner@rf-design.de on 2015-04-29 09:29:42

[Beep6581]

Finally a few days with clear skys, and therefore here are some new samples I hope solve
the issues with the previous ones. Sigma SD1M under midday sun with a clear sky:

http://rnbc.dynip.sapo.pt/pub/x3f-examples-04/

Reported by rnbc.r0 on 2015-05-17 23:54:16

[Beep6581]

exiftool shows the SD1's make and model as:

-EXIF:Make=SIGMA
-EXIF:Model=SIGMA SD1

RawTherapee shows "Exif data not available" in the (i)nfo panel, and "Unknown" for make and model in the File Browser > Filter

[Beep6581]

We still need to add entries to camconst.json for Foven models using safe white (and black?) levels, and to rename the shipped profiles from e.g. sd1_merrill_cloudy8140-CROP-WP10.icm to something more consistent with the other names which RawTherapee should be able to load automatically (once reading Exif of Foveon models is implemented).

[morosakubek]

Hi, Still all Merril's cameras shows that "Exif data not available", so as i think rawtherapee can't properly read the file.

[Beep6581]

camconst.json now supports Foveon files, closing.

Adding specific raw formats to camconst.json should be handled in separate issues.