Messages

76

Camera-specific Development / Re: EOSM-Updated ML for 2.02 firmware

« on: May 09, 2014, 08:31:05 AM »

Hi 2blackbar, which speed booster did you modify, and how? :-)

+1000!

... and please post some shots!

77

Feature Requests / Re: LUT View

« on: May 04, 2014, 11:20:42 AM »

The picture style used for the LCD can be different than the picture style used in recoding.

78

Camera-specific Development / Re: Smoothing the transition to Magic Lantern.

« on: April 14, 2014, 06:46:57 PM »

My request: is it possible to implement a stable version of GOP and Slice Control back into ML?
Maybe not even all the complicated stuff, but at least a foolproof version of All-I recording (GOP=1) and maybe another inbetweener short GOP option?

Support this request 100%.  "No-artifact H264 (with boosted bitrate) is an exceptionally useful alternative to raw.  It would be nice if slice and d-block control were available, too.

Thanks for all of the great work!

79

General Help Q&A / Re: Does RAW actually increase dynamic range or does it just add bit depth?

« on: March 21, 2014, 09:14:54 PM »

practically all producers combine a sensor with a a/d-converter, that is able to at least preserves the needed accuracy. but the inversion (low bitdepth with high dynamic range) is wrong.

Sensors are often sold without the A/D convertor.

Don't know what is meant by, "(low bitdepth with high dynamic range) is wrong."  Cameras exist which have a higher dynamic range (yet lower bit depth) than other cameras featuring higher bit depth.  In addition, a camera can allow one to choose different bit depths while its dynamic range remains unchanged -- so one can have a lower bit depth with a higher dynamic range.

every 8bit-picture of hdr-data (as it is in a dslr) is just a simplification, based on processing. every example you'd show is just a reinterpretation, it was a high dynamic range scene (your brain helps you to say that).

Heck, every time one takes the signals from a sensor and digitally maps them to a chosen bit depth, one is "interpreting."  However, such "interpretation" would not change the capture range of the sensor nor necessarily change the dynamic range of it's analog output.

So, one can map a sensor's signals to a variety of bit, depths but that mapping doesn't change the dynamic range (hopefully) -- bit depth and dynamic range are two different properties.

if i'd show this 8bitHDR on a projector, the dynamic range of lowest to highest value wouldnt ever reach the old dynamic range of the original data, no matter if 500$ or 50.000$ projector..

Give me almost any projector that has contrast adjustment and let me choose two shades from a grey scale in the scene.  I will then create a greater relative amplitude range between the two projected shades, versus the two shades in the scene.

did you've seen ever a high dynamic range picture?

Yes.  I have seen analog and digital images that have a higher dynamic range than other images.

me not. everytime it was a nonlinear interpretation. Raw-Converter with preview? Lightroom fi? reinterpretation!) beside logarithmic/gamma there is no nonlinear mapping, that is interesting to us.

Not sure if Lightroom and similar programs change the actual dynamic range of the signal or if such programs just change the contrast/curve within the given dynamic range of the signal.

Furthermore, merely remapping gamma/curves in Lightroom (and similar programs) does not affect the bit depth per se -- the bit depth remains unchanged until it is intentionally reduced (usually when exported).  So, one is merely remapping tones within the given bit depth.

Also, I do not presume to declare which type of non-linear mapping is interesting to us, but the ones you mentioned are in wide use probably for practical reasons.

as i said before, visual sensors are linear. four times the amount of photons, four times the read-out-value .

That's true for the most part.  Response curves are not perfect, and they breakdown at the extremes.

Not sure what is the point.

[older entry] no need to discuss about it, but this:On the other hand, it seems that these examples demonstrate how dynamic range can relatively remain the same while the bit depth is changed.
[and]
Color Depth = (Resolution x Bit Depth)³

ok. i'm out.

Were you not demonstrating mapping different bit depths with the same sensor?  Does the sensor's capture range and dynamic range change just because the output is mapped with more or less bit depth increments?  It seems to me that you were demonstrating my point.

In regards to the color depth formula (for RGB systems), you can dismiss it, but it still remains a fact.

80

General Help Q&A / Re: Does RAW actually increase dynamic range or does it just add bit depth?

« on: March 21, 2014, 10:41:13 AM »

DR describes the difference between the highest recorded signal, and the noise floor.

Basically agree.  Might word it a little differently.

Bit depth, in a nut shell, describes the resolution (accuracy), of the digital system.

I would be with you a lot more if it was worded, "Bit depth describes the 'resolution-per-channel' of the digital system."  Really, bit-depth is the number of possible level increments per channel in a digital system.

With increased accuracy, you can capture increased DR.  They are separate components, but they are intertwined.

I am afraid that we differ strongly here.  Dynamic range and bit depth are two different, independent properties.  Increasing the bit depth does not yield an increased dynamic range (in most practical cases).

81

General Help Q&A / Re: Does RAW actually increase dynamic range or does it just add bit depth?

« on: March 21, 2014, 10:24:59 AM »

are you workin any scientistic kind? because i'm a little bit confused about some of your words..

I do not understand your question here.

no. are you talking about security cams without affection to good picture and with pre/postprocessing?

A camera can have a lot of dynamic range, but little bit depth.

I am not singling-out security cameras, although there are certainly some that have increased DR and an 8-bit depth.

However, there are plenty of other examples, too.  For instance, many cameras give a choice of bit depths -- yet the DR remains the same regardless of the chosen bit depth.  So, at the lowest bit-depth setting, the camera has its greatest dynamic range, but has it's lowest bit depth.

Dynamic range and bit depth are two independent properties.

"CAN"! - picturesensors giving linear data, means, to save and sample them accordingly, you need a "linear" system,

As I am sure you know, sensors give analog data, and that info can be mapped to digital values in ways other than "linear."

Regardless, given a linear mapping method, a camera can still have little dynamic range and a great bit depth.  Take any early 16-bit camera and compare its capture DR to that of a current 16-bit camera -- the newer cameras will generally capture a greater dynamic range.  So, the early cameras have little capture DR but great bit-depth.

its quite good described with the bitdepth. 1bit for 1ELV (>1bit) - theoretical meaning 14bit is able to sample/save nearly 14ELV of visual data accordingly without loss/artifacts. that doesnt mean, if theres a 14bit ad-converter, the source side (here: sensor) must deliver the full range.

I am not sure what the point is here, but the value associated with each incremental step in bit-depth in a linear system is not a universal constant.  That value can (and often does) vary from system to system, camera to camera.  That variation is a precise reflection of why DR and bit-depth are different.

lol. no. DualISO is changing the ampification per sensel-line. both different amplificated "pictures" are limited in their dynamicrange, one's losing data in the lowlights, the other loses values in full-well-sensor-area (highlights). they're kind of preprocessed.

Thanks for the explanation of Dual ISO, but I already understood the basics of how it works.

As I said, Dual ISO gives a phenomenal increase to the capture dynamic range, yet the bit depth doesn't change.  That fact is absolutely true.

However, Dual ISO does not change the dynamic range of each pixel in the sensor (I never claimed that it does).  In addition, with Dual ISO, one is sacrificing resolution and color depth along the vertical axis for the increase in capture DR.  I would also guess that Dual ISO makes the images more vulnerable to aliasing/moire.

By the way, a few years ago Panavision was working on its "Dynamax" HDR sensor, which used extra pixel groups of differing exposures, somewhat similar to Dual ISO.  "Dynamax" is now the name of Panavision's sensor division (don't know what became of the HDR sensor).

but you said "zillions of real life examples". fine.

As I said, there are countless examples in which dynamic range and bit-depth are independent.  Dual ISO is only one.

The situation that I gave above of setting a camera to its lowest and highest bit depth while yielding the same DR is another case.  There are many cameras that have such capability, hence there are many such examples of how bit-depth is independent from DR.

The above scenario of an older camera with 16-bit depth and low capture DR compared to the capture DR of today's 16-bit cameras is yet another case of how DR and bit-depth are independent.  There are many old and new cameras to compare, thus there a numerous examples demonstrating the independence between DR and bit-depth.

We haven't even touched on the differing dynamic ranges of digital systems and digital displays that have identical bit depths.

Again, we need look no further than ML for another example in which capture DR is independent from bit-depth -- HDR video.  With HDR video, the DR increases, yet the bit-depth remains unchanged.  Of course, we are not increasing the actual dynamic range of the sensor, and we sacrifice longer shutter speeds and suffer motion artifacts in exchange for the DR increase.

These general examples (along with the specific ML examples) are fairly clear, so I don't see the need to site particular digital cameras/systems to prove the point.  However, I will, if you like.

a switch with two states has no dynamic range.

Two shades can have dynamic range.

how do you describe dynamicrange between on and off? you need a "lowest" measurable value (not zero!)

Who said that the lower shade is "off/zero?"

However, zero is a given in any system, so, you are right, it should be considered as a third shade.

[/b]. leads to at least three states (or you said: two shades). means: [three states] 0, 0.5 and 1. whats the dynamicrange of that? other example: 4 states (2bit): 0, 0.33, 0.66, 1 (=1/0.33).. (16384 states) 14bit -> 1:16383 -> ln(16383)/ln(2) = 13.99 ELV

There is no way to quantify the specific dynamic range of any of those systems, unless the noise level is known.  On the other hand, it seems that these examples demonstrate how dynamic range can relatively remain the same while the bit depth is changed.

"color" is just an electromagnetic property. if you measure three separate frequencies by its amount (here: photons), you just measure the dynamicrange in finite frequencies.. (please dont talk about the simplifaction from graphic-cards-world)

Well, if you take color on  the "photon" level at the subject, you are talking about infinite frequencies.

However, my statement to which you responded involved the fact that color depth and bit depth are two different properties, so we are primarily referring to digital imaging systems.  For the sake of simplification, let's address RGB digital imaging systems, and disregard alpha channels, Bayer interpolations or any obscure digital color systems.  Let's also stick to simple raw imaging and not involve compression, dithering or any other such modifications.

Color depth in digital systems is a result of two primary factors:  resolution and bit-depth.  Here is the basic mathematical relationship:
Color Depth = (Resolution x Bit Depth)³

So, a small increase in resolution can yield a huge increase in color depth.  Of course, an increase in bit-depth also boosts the color depth.

That's pretty much it.

82

General Help Q&A / Re: Does RAW actually increase dynamic range or does it just add bit depth?

« on: March 20, 2014, 09:52:28 PM »

no, finally they're aren't independent.

Yes.  Dynamic range and bit depth are two very different and independent properties.

A camera can have a lot of dynamic range, but little bit depth.  By the same token, a camera can have little dynamic range and a lot of bit depth.  Furthermore, a camera can have a lot of dynamic range and a lot of bit depth, or it can have little dynamic range and little bit depth.  Dynamic range and bit depth are independent.

There are zillions of real life examples, but one need not look any further than right here at ML -- dual ISO.  Dual ISO gives a phenomenal increase the the capture dynamic range, yet the bit depth doesn't change.  Dynamic range and bit depth are two different, independent properties.

in terms of "datadepth" you need some bits to store linear digital signals,  as they come from a visual sensor.

Not sure what is meant by "datadepth."  However, yes there must be at least two shades in digital systems to establish a dynamic range.

the main aspect is, yes, you could get the whole dynamic range by compressing into this byte-field (as its in h.264) - but it looks ugly, if you like to tweak it a little, horrible banding is the most common artifact. try some picturepresets like flaat_12 - you can use them only, if you're on point while recording, if not, you re lost.. (and in most situations you have to tweak 12ELV to look natural)

I am not referring to how "ugly" an image looks -- I am referring to what dynamic range and bit rate  are.

By the way, banding has a lot to do with color depth, which is also different than bit depth.

(btw. its a everlasting discussion, how generally to define lower and upper ends of a usable signal. i made tests with an older 5d(photo) and yes there are more than 12 ELV Range, but the lowest lowlights are not usable, because the noise so much stronger than the useable picturesignal

Well, dynamic range is a pretty "cut & dry" technical term as it relates to analog and digital systems, and noise is factored into dynamic range.  A lot of people (including me) also confuse dynamic range with signal-to-noise ratio, but those two properties are more closely related to each other than are dynamic range and bit depth.

Wish I had more time to explain some things, but I gotta run.

83

General Help Q&A / Re: Does RAW actually increase dynamic range or does it just add bit depth?

« on: March 20, 2014, 08:33:04 PM »

I'm assuming the dynamic range (as in the ratio of the highest signal to the lowest signal) would still be the same with a RAW or a non-raw frame?  Does RAW enable the sensor to pick up a wider range of data?

Dynamic range and bit depth are two very different and independent properties.  As you said, dynamic range is the ratio (of amplitude) between the highest and lowest signal (above the noise floor) in both analog and digital systems.  Bit depth applies only to digital systems, and bit depth is number of digital level increments within the highest and lowest signal (including the noise floor).

The capture dynamic range of the sensor itself remains unchanged regardless of how its signal is processed after it is captured.  However, it seems clear that the h264 (and jpeg) processing inside the Canon cameras reduces the "capturable" dynamic range of the entire system to less than that of the sensor.

There's certainly more latitude in post to "stretch" the values you acquire with more bit depth, but I have been wondering if plain RAW video from a Mark III vs the h264 improves on the dynamic range.

Not sure what is meant by "to 'stretch' the values you acquire with more bit depth," but it seems clear that the use of raw data from Canon sensors will capture a greater dynamic range of values in the subject than using the Canon h264 (or jpeg) processed image.

84

Tragic Lantern / Re: EOS M versus T3i (600D) ?

« on: February 24, 2014, 09:08:40 PM »

I think the limit for flush rate on EOSM is 2, I don't remember off the top of my head if that makes all one type of frame. Really fast is a low number. This time gop isn't linked to flush so you may be able to do gop 1, it has been a while since I pushed the H264.

Thanks for the explanation!

When you say that "this time gop isn't linked to flush, "  do you mean in the latest TL builds or do you mean with the EOS-M vs. other cameras?

Here is what Gop1 Crop Mode ISO 1600 gets you:

Code: [Select]

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : Baseline@L5.0
Format settings, CABAC                   : No
Format settings, ReFrames                : 1 frame
Format settings, GOP                     : N=1
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 22s 731ms
Bit rate mode                            : Variable
Bit rate                                 : 110 Mbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Original height                          : 1 088 pixels
Display aspect ratio                     : 16:9
Original display aspect ratio            : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 fps
Color space                              : YUV


That's a useful list of characteristics.  How was it generated?

Thanks!

85

Tragic Lantern / Re: EOS M versus T3i (600D) ?

« on: February 24, 2014, 08:53:58 PM »

which one is posted daily on http://tl.bot-fly.com/  ??

I think that those builds descended from TL2, but perhaps someone from the #1/#2 period can clarify/enlighten.

86

Camera Emergency Department / Re: Did I brick my T3i/600D?

« on: February 22, 2014, 11:42:57 PM »

I don't that it is clear whether you copied the files directly or whether you copied the files by somehow using "EOSCard."

87

Tragic Lantern / Re: EOS M versus T3i (600D) ?

« on: February 22, 2014, 05:15:23 AM »

T3i and EOSM are fairly different: Sensors, processor, video modes, resolutions, sd controller, encoder.

I seem to recall a post somewhere on this forum that suggested the EOS-M has a greater tendency for moire'/aliasing than the T3i.

If you up the bit rate to the max "x" rate and make it flush really fast, it will dump the highest QP frames it "officially" can.

Would love to understand what all of this sentence means.  Does "flush really fast" mean a higher number in the flush rate setting?  Furthermore, are you saying that "flush really fast" results in high quality P-frames?

88

Tragic Lantern / Re: EOS M versus T3i (600D) ?

« on: February 22, 2014, 05:04:55 AM »

i never heard of TL version 1 or 2. I just always download  http://tl.bot-fly.com/

Here's TL1.

Here's TL2.

TL1 has more h264 controls (for the 600D) than TL2.

89

Tragic Lantern / Re: EOS M versus T3i (600D) ?

« on: February 22, 2014, 02:26:26 AM »

Not true at all. I have used every nightly build of TL since last July without any problems. Read all the threads for the M. And read my latest post I just made about H.264, CBR up to 20. 0, flush rate 30, GOP 1 shooting 1080p30 with audio on the M.

I thought that the nightly builds were a continuation of Tragic Lantern 2, not Tragic Lantern 1.

90

Tragic Lantern / Re: EOS M: GOP, BITRATE, FLUSH RATE settings for H264

« on: February 21, 2014, 10:03:33 PM »

The best GOP setting would be "1," as that setting eliminates inter-frame compression and its artifacts.  Some folks report good results with a GOP of 3 (inter-frame compression across two out of every three frames), and that setting allows a little more boosting of the bit rate.

In either case, the bit rate can probably be set to CBR 2.5 with a fast card and a fairly complex scene.

Perhaps someone else can chime-in on ideal slice settings, etc.

91

Tragic Lantern / Re: EOS M versus T3i (600D) ?

« on: February 21, 2014, 09:53:43 PM »

I have the T3i, and I just got the EOS-M.

The T3i can use Tragic Lantern 1, but the EOS-M cannot, so there are more h264 settings available with the T3i (D-block settings, most importantly).

However, I haven't had a chance yet to fully experiment with the EOS-M, but, using the latest TL builds, one can probably get close to the clean look of the T3i/TL1 combo.  Just set GOP to 1 (or 3, but no greater than 3) and boost the bit rate as high as possible (should be able to do CBR 2.5 with a good card and a moderately complex scene).

One big advantage of the EOS-M is the wide variety of lenses and adapters that it accepts.

92

Duplicate Questions / Re: New idea for bigger resolution, devs - get in and check it out!

« on: February 21, 2014, 05:23:48 AM »

and how exactly do you propose to make the square pixels rectangular? magic?

Binning each axis at a different rate is one way, but it sounds like the OP is okay with "pseudo" rectangular, which would simply mean using only one pixel for every "n" pixels along one axis.

I do not know whether or not either method is possible with the EOS-M, but I would doubt it, after reading about the many significant limitations of Canon cameras.

Certainly, one can make the pixels rectangular after the footage is recorded, but the shooting bandwidth problem would remain.

Of course, there are  cameras/sensors with rectangular pixels, but that is not the case here.

93

Share Your Videos / Re: Eos-m Timelapse

« on: February 20, 2014, 01:19:17 AM »

To use a lager battery, you could get one of these.

Just cut the cable that leads to the camera and connect five normal battery cells in series (7.5v), with the proper polarity, of course.

94

General Help Q&A / Re: 600D not detecting Magic Lantern

« on: February 19, 2014, 04:55:41 AM »

I'm running Win7 64bit, and explorer is set to "show hidden files"
[snip]
I'm pretty sure that this is where the problem lies, but have no idea what to do about it.

Try disabling "show hidden files" in Explorer, and see if the files are visible on the card through the card reader.  If they are not visible, then the files have the "hidden" attribute set and that condition is very possibly involved in your problem.

95

General Help Q&A / Re: 600D not detecting Magic Lantern

« on: February 19, 2014, 04:45:52 AM »

I will find a 4Gb card tomorrow and give it a go

Any 4GB, 8GB, 16GB or 32GB SDHC card should work.

Each file copied in turn on to the card then deleted from the computer before checksum performed. I'm not sure how I can verify that these results are valid??

All looks copasetic.  If you eliminated all traces of the firmware files from your computer and if the files on the card were links or were corrupted, then the md5sums would be off or some error message would have appeared.

96

General Help Q&A / Re: 600D not detecting Magic Lantern

« on: February 19, 2014, 12:11:29 AM »

Also, is your file manager set to read hidden files?  If so and if your computer is somehow creating files and folders with attributes set to "hidden," then you would see the files through your file manager and card reader, but your camera might not see the files.

Furthermore, do you have any automatic encrypting functions running on your machines?

97

General Help Q&A / Re: 600D not detecting Magic Lantern

« on: February 18, 2014, 11:59:18 PM »

Have you tried another SDHC card that is 4GB or greater (fat32), other than your 16GB card?

Also, you might try copying the firmware file to an SD card, and then delete the firmware on your computer (completely delete it -- in the trash or anywhere else on your computer).  Then, using your card reader, do an md5sum of the firmware file on the card.  This test should make sure that there is no strange file linking occurring, while also making sure that there is no corruption when you copy files to the SD cards.

Just curious, in what mode is your camera when you try to upgrade the firmware?

98

General Help Q&A / Re: 600D not detecting Magic Lantern

« on: February 18, 2014, 12:35:45 AM »

Can you try an md5sum of the CCF11102.FIR file?  I get  195defc3eef7cff7fa2317f7d8ee19aa.

Also, don't know if this matters, but the letters in the name of the firmware file from Canon are capitalized.

In addition, what are the file systems of the 2GB and 16GB cards, as formatted by the camera (just curious)?

99

Share Your Videos / Re: C-mount lenses on the EOS-M

« on: February 14, 2014, 08:12:09 AM »

Got my EOS-M with the Fujian 35mm f1.7!

The lens (and camera) is fantastic and fun, and it is amazing that it does not vignette on the ASP-C sensor (the lens is rated for a 2/3" sensor).

However, I am noticing an excessive "circular of flare" in the center of the frame, on the widest f-stops.  I know it is flare, because I can flag it with my hand.  This flare is so excessive, that, if a little bit of light hits my hand, the color of the "circle of flare" (on the side closest to my hand) changes to the color of my hand.

Anyone else notice the same phenomenon?

I think that the filter size of my Fujian is 35mm wide, so I will probably try a long lens hood.

100

General Help Q&A / Re: Optimal settings for H264 packed video

« on: February 12, 2014, 07:08:36 PM »

Set GOP to 1 (or, at most, 3).  Might have to use Tragic Lantern to find this setting.

GOP is an abbreviation for "group of pictures."  H264 compression can share image elements within a "group" of adjacent frames ("pictures") for the sake of lower bandwidth.  The size of this setting determines how many adjacent frames share image elements.  For example, a GOP setting of 3 shares image elements between every 3 adjacent frames.  Such sharing of image elements between frames is also known as interframe compression, and the greater the interframe compression, the greater the tendency for the appearance of artifacts.

So, a GOP setting of 1 eliminates H264 interframe compression -- each frame is its own image, completely lacking shared image elements with adjacent frames.  Any greater GOP setting shares image elements between adjacent frames, possibly increasing artifacts.

D-block settings can affect the appearance noise and blocky artifacts, but if such settings are currently available for the EOS-M, it would likely be in a version of TL.

Here is an article that explains some of the additional h264 settings offered by early versions of Tragic Lantern for the T3i/600D.  The article gives links to more detailed pages on this forum.