Messages

(...) is white balance applied in the camera before or after the picture style is applied? This is something that I haven't tested. (...)

I had the same thought. And also that internal WB is apply directly from RAW (during debayering process), and PS WB *after* in RGB mode (ICC RGB/LAB way supposition). I hope not, because it should mean range will be short so reserved for 'film effects' stuff.

Indeed, I saw EOSU v3.5.0 but even in Europe we need 5D4 serial number to download it.
I'll try with EOSU 2.14.20a, I will see if we can play with color balance with this version.

Excellent discoveries guys.
Since we know now that PS are somewhere ICC, or we can inject ICC in PS, we can imaging many things!
So sure a good math log would be very nice (I always found that filming things of life in linear was inhuman), and I saw we also could modified the color balance if I'm not wrong (?); it will be pretty nice to generate a couple of PFs calibrated for some special situations, we could switch fast between then while we are filming. But I think I've a lack of information about the internal process; I thought after readings here and imaging that RAW/PS->H264 4:2:0 but if we can modify the color balance with PS do you how this is interfere with the internal color balance?
When I will found where to download a recent version of EOSU to load PF3 in my 5D2 I will try to make some tests..

Interesting

We use a 5D2 without the second low pass filter (replaced by a more 'open' filter in near IR and somewhere in UV) but with the front one always in place (it is a safety condition for us).
There's a little gain in resolution @1:1, but it's hard to say it comes from the low pass removed stage because the new filter is far better (high precision fluorite substract) than the original. And much harder to quantified the gain, it should be done with & without the filter, with the same optic (known with a better resolution than the angular resolution of the sensor) in the same conditions, in different spectral zones ( (s?)RGB ), etc.

Good point, big pixels of the 6D will be tolerant with old FD optics about resolution and for focusing, with 5D2 or 5D3 it's... Hard.

Very good job Kirill, very dynamic like this city, and a step better than the Porto TL/HL !

The hard stuff could be to know the exact time (with second accuracy, maybe with a fraction of second for Baily's Beads) of events in function of the equally precise observer location. I'm not sure that any software is accurate enough, maybe you should have to compute it from the polynomial besselian Elements of the eclipse.

Maybe a best (easier and safe) way will be to pre-program group sequences for the different events with specific parameters (TV/AV/ISO) and run them manually when events start (?). Because with an all pre-program job if something is going wrong you could miss precious moments, or all, and during a Solar eclipse there're always unpredictable things, even if you are very well prepared and trained.

Hello calypsob,

You're not the only one who thought to do that, ML direct to ST4 for dithering It's nice to see someone else !
I'm agree with a1ex, it's possible to send simple orders via PTP through the camera USB. Not quite easy by the way (I loose some neurons with the ptp.h !), especially if you want to drive an USB to ST4 interface. It looks like to transform the camera USB into an USB OTG (?), with a 5V power line from the camera (not safe IMHO), etc.
And it's not possible to drive the ST4 interface of your mount directly from the USB, you will need to use a pair of relays or optocouplers (solid state relays or eq.) between the USB and the ST4 because of the electronic level differences and because it's not safe too.
So in both cases you will need some electronic between the camera and the mount, and/or the camera and the USB-ST4 interface. :/

Another application will be to drive robot-focusers or EF lens from ML, by pointing a star in LV mode, with a real time FWHM algorithm... ^.^' <3 But it's an offtopic dream.

It never hurts!
I remember the original discussion, I thought you are re-lunching it.

I just took a look over this, tonight I'll see it closer. Sounds very interesting!
Specially about the question 'hardware or software binning?'.

(...)
I'd prefer to continue to focus on developing new approaches though, (...)

+1

This thread is massively interesting.

Wahô Since years, after open the card door I just wait LED stops blinking before to remove the card. I thought/hope the blinking card LED trick was active.

Beside, it appears that the best way is to remove the card when the camera is 'on' (power switch in 'ON' position). In this way on 5D2 it's perfectly safe (correct me a1ex if I'm wrong). Maybe it could be a important notice (?) face to the '5s waiting'. Or when we switch off the camera by opening the card door we should wait 5s too before remove the card?

An other problem would be if the same scenario appends (blinded autoexec.bin loading) in other cases; like "camera off - detach/attach lens" (because the card LED blinks while this operation)
And just to participate, "camera off - open the battery door on a grip -> card LED blinking" :/

However, since many years, just by waiting the LED stops blinking (sometimes it takes several seconds, even with a fast card), I never get problems.

On 5D2, removing the card too fast might cause permanent damage to the camera.

Is there no solution to prevent this a1ex?
Mark on screen 'please wait before remove the card, saving data..' or something, when user open the card door?

Alright folks, full-res silent pictures are now in the nightly builds!

Pô po pôo po ! Huge ! ^.^

@SpcCb: to experiment with dark frames, compile 5ce22358adb5 (not later). This feature caused problems (see last reports); it's not very hard to fix, but it adds quite a bit of complexity (if I fix this, it may delay merging fullres to main tree even more). So I've removed it for now, and revisit it after merging (but the code is still there to experiment with).

I saw it, don't worry

What do you mean by "zip exposure time"? (have a link?)

I mean camera who have capability to take ultra short exposures by electronic shooter, like 1/10 000s, what is considerate as a 0s exposure (zip => zero, in 'underground' language).
You can find it on cameras made by Finger Lake Instrumentation, The Imaging Source, Santa Barbara Instrument Group, etc.

It is a very important point in scientific imaging because with this kind of camera we can make very precise Master Bias Frames, very hard to get with a camera with a 'long' electronic exposure because we get 'some' thermal signal on frames mixed with other signals. It refers to our discussion about FPN reduction etc.

Beside, it's opening many other applications, like ultra short exposure time for high speed imaging, etc.
Things what we can do with CHDK for example.

@SpcCb: I've added the ability to take dark and nearly-bias frames (press half-shutter outside LiveView).

Probably it's not very useful without a way to mix regular pictures with dark/bias frames, but I think this would be a job for the scripting engine.

Still, this trick now lets you take a large number of dark frames without wearing the shutter mechanism.

note 1: by nearly-bias frames I mean dark frames with the shortest exposure time possible - same thing that you would get with a regular picture at 1/4000 and lens cap on, for example.

note 2: in LiveView, with some cameras, it is possible to take true bias frames (with zero exposure time) by removing the range checks from the shutter fine-tuning feature.

note 3: if we ever figure out how to drive the sensor at full resolution and with rolling shutter (thus removing the shutter speed limitation), true bias frames might be possible as well. But for now I'm kinda clueless about how to setup the sensor this way.

E-nor-mous.
Over flow by work right now, but right I get free times I'll experiment this!
Do you know witch camera could done the ZET (zip exposure time, what we have on scientific cameras)?

That's not true. FRSP runs in "LV mode" so that the shutter is open, but LV itself is disabled during acquisition, and you could have disabled the whole time if you wanted.

We can open the shutter and take FRSP without activated the LV? o.O
My mistake, I never could do this on the 5D2; I have to activate the LV to open the shutter and get access to FRSP. What version do you use?

Of course, if the LV _I mean flux processing made by DIGIC and screen_ is off it should not heat too much face to regular RAW pictures.
Stays the problem of bias frames BTW...

I see, for bright deepsky objects _indeed_ FRSP looks interesting.
However live view will be active during all acquisitions time so the thermal signal will be very high on frames. Sensor will reach 45~50°C (loc.temp.<10°C) in a few time and it will be very hard to reduce it with calibration even with hundreds of dark frames, because temperature rising is not linear and not stable during acquisitions. Plus bias frames are a bit... tricky to make in FRSP (see the minimum exposure time what you can expect, it depends of your camera) so the FPN + offset reduction is not perfect. :/

Very dangerous to do that (without specific filters), for the gear but first for your eyes.
Plus, like that, the Sun is fully burned without any details visible.

I recently started using ML on a 1100D for astrophotography. Great!
To gain more flexibility towards short but frequent exposures, I would like to use the silent mode.

Do you plan to use it for planetary or deepsky imaging?
Because there's no significant gain to use FRSP for astrophotography; too slow for planetary and not relevant about mechanical stress vs sensor heating for deepsky.

I send you a sample by PM, as I don't use this setup I just have in stock private pictures where we can see these hot pixels macro blocks.
If I get times next days I could try to make fresh ones with and without Dual ISO in the same conditions, if need.

Maybe ISO 3200 was defined as the high value of the Dual ISO (?).
In this case it generates a lot of _big (macro-blocks)_ hot pixels. I don't know why, maybe a question of pixel value or something who loose the link with the internal hot pixel removing feature, but with the 5D2 the maximum ISO to use should be 1600 in Dual ISO mode to not get this issue.
Note: it appends with short exposures too, long exposure does not matter in this case, even if it's not help (hot pixels are just more 'brighter').

That's right - how Canon encodes WB is still a bit of a mystery. We know how to interpret the Kelvin value (e.g. with WB routines copied from ufraw), but we don't know yet how to interpret custom RGB multipliers or WBShift values.

You could try converting the CR2 to DNG with Adobe DNG converter, then copying the WB tags with exiftool. IIRC, you only need to copy AsShotNeutral.

Indeed, Canon WB definition looks a bit complex. I thought RGB multipliers (what we can set in the ML WB menu) was enough to get a good render but I never get as good/fine results (ie. like done in the camera by Canon or done in post with a special software).
BTW we can see some of the Canon parameters in a CR2:

Code Select Expand

SensorRedLevel                  : 0
SensorBlueLevel                 : 0
WhiteBalanceRed                 : 0
WhiteBalanceBlue                : 0
ColorTemperature                : 2500
PictureStyle                    : User Def. 1
DigitalGain                     : 0
WBShiftAB                       : 0
WBShiftGM                       : 0
MeasuredRGGB                    : 948 1024 1024 963
ColorSpace                      : Adobe RGB
VRDOffset                       : 0
SensorWidth                     : 5792
SensorHeight                    : 3804
SensorLeftBorder                : 168
SensorTopBorder                 : 56
SensorRightBorder               : 5783
SensorBottomBorder              : 3799
BlackMaskLeftBorder             : 0
BlackMaskTopBorder              : 0
BlackMaskRightBorder            : 0
BlackMaskBottomBorder           : 0
ColorDataVersion                : 6 (50D/5DmkII)
WB_RGGBLevelsAsShot             : 1414 1027 1027 1598
ColorTempAsShot                 : 3898
WB_RGGBLevelsAuto               : 1876 1024 1024 1978
ColorTempAuto                   : 4122
WB_RGGBLevelsMeasured           : 1597 2354 654 1463
ColorTempMeasured               : 4122
WB_RGGBLevelsDaylight           : 2217 1024 1024 1691
ColorTempDaylight               : 5200
WB_RGGBLevelsShade              : 2539 1024 1024 1398
ColorTempShade                  : 7000
WB_RGGBLevelsCloudy             : 2383 1024 1024 1524
ColorTempCloudy                 : 6000
WB_RGGBLevelsTungsten           : 1668 1079 1079 2799
ColorTempTungsten               : 3200
WB_RGGBLevelsFluorescent        : 1950 1044 1044 2517
ColorTempFluorescent            : 3674
WB_RGGBLevelsKelvin             : 1341 1116 1116 3832
ColorTempKelvin                 : 2497
WB_RGGBLevelsFlash              : 2399 1024 1024 1509
ColorTempFlash                  : 6127
RawMeasuredRGGB                 : 0 0 0 0
CustomPictureStyleFileName      : BlackLift4

It looks there's a color matrix based on a discreet 4 pixels from the Bayer Matrix plus a magenta/green shift, modulo the Picture Style effect.
Maybe 'WB_RGGBLevelsAsShot ' seems to be the custom output matrix, what we should use to compute the RGB WB in the DNG (?) : Each params of the WB_RGGB* seems representing levels get from a reference.
For example, with the 5D2, when WB is set on Daylight the RGGB matrix is automatically defined with RGGB -> 2217 1024 1024 1691. Witch is false with a mod camera because we get more R and _obviously, but it depends of the modification_ more B. So the matrix should be adapted with RGGB something like 14?? 1024 1024 15??. We can see 1414 1027 1027 1598 for my camera, calibrated for Daylight.

Beside, I don't see why we can't change the RGB multipliers (in the ML WB menu) with +/-10E-3 increments (?). Changes made bumps of several .xx ? (sorry always away from my dev computer so can't browse the code..) Because I have precise RGB multipliers (@+/-10E-3) computed in post for my camera from very RAW files but I could not set it in the camera to see how the Canon WB_RGGB* are affected...

zeno2358 is not wrong somewhere; --wb is a very useful option in the 20-bit cr2hdr however there's no way to simply copy the CR2 WB in the DNG (?), in case of special WB.
I use a mod camera too and do it in post, but it's not really friendly for regular daylight photos.

Maybe the CR2 WB have complex parameters, not easily transposable in the DNG (?)...

Bonjour,

En premier lieu tu peux laisser un coucou sur la page des présentations, il y a même un fil de discussion en Français.

Ensuite pour le coup de l'Anglais, même si ce n'est pas de l'Anglais académique, tu peux utiliser les outils de traduction en ligne, comme celui de Google qui fonctionne relativement bien si l'on écrit dans un Français correct. Cela te permettra de te faire comprendre et de pouvoir traduire les réponses que tu auras.

Sinon, pour tes questions :
_. Non, "nightly2014aug75D3123" signifie que c'est une version automatiquement générée (la nuit, cf. nightly) avec les toutes dernières avancées, mais pas forcément stable. Même si certaines versions sont assez stables pour être utilisées tous les jours sans trop de risque. Attention, je n'ai pas dit qu'elles étaient parfaitement stables.
_. Pour ta question sur le menu son, il faudrait que tu sois un peu plus prolixe car il est difficile de te répondre dans l'état. Tu n'as pas de sous-menu où ?

Voilà pour un unique message en Français histoire de donner un coup de pouce au début, mais les suivants seront en Anglais.

The image magnification (M), only plays a role in how the pixels record the photons, right?

We are speaking about energy collected in all the field, with no consideration about the recording device, if I'v understood (?).

If the goal is to defined how many energy get each pixels of a sensor, it is quite different.

Do we want to compare with constant pixel size? If yes, it's like there's no magnification between samples, so the energy received is function of the f/d (with constant diameter we should get something function of the focal length).
Or do we want to compare with different f/d and different pixel size? (strange method, by the way) In this case it's like we also change the flux area covered by 1 pixel, so somewhere the energy collected.

The number of object photons available to the camera is solely determined by:

    Object flux (photons/second/square-meter)
    Aperture size (square-meters) and efficiency
    Exposure time


Focal length (and thus f-ratio) has absolutely no effect on the number of photons collected and delivered.

My car is blue, so my car is not blue

Maybe it could help (not absolute but can be use for an approach):

I = (T*pi*B)/{4*(f/d)²*(1+M)²}

I, image illumination in foot-candles
T, transmittance of the lens
B, object luminance in candles/square foot
M, image magnification

So yes, with using some 'perfect' accessories, if you compare two images at different focal length (all other param equals) but cropped to fit the same field it should be close in term of illumination (question of magnification).
But it is cheating a bit on the result samples.. If you compare raw fields of course lower f/d images will get higher illumination.