Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - tupp

Pages: [1] 2 3
1
Raw Video / Re: Advise on choice: 5Od, 7d, eos m
« on: August 22, 2018, 10:09:55 AM »
Yes.  The huge variety of lenses and adapters is a significant advantage of the EOSM.

With the right adapter, you can use C-mount (and PL mount), 16mm lenses that work wonderfully with the new EOSM raw crop modes, but you cannot do the same with any of the DSLRs -- not without an expensive, perilous mod.

You can also use speedboosters/focal-reducers on the EOSM to essentially give a full frame look when used with a full frame lens, and gain an extra stop of exposure, to boot!  The APS-C DSLRs can't take speedboosters/focal-reducers.

Also, you can use other special adapters on the EOSM, such as tilt/swing or tilt/shift adapters, which are perfect for full frame lenses on an APS-C sensor.  Again, this is not possible on the DSLRs.

The biggest drawback of the EOSM is the slow SD card controller, but the recent ML advances in SD card overclocking have largely overcome that issue.

2
Camera-specific discussion / Re: Canon EOS M
« on: July 16, 2018, 07:20:42 PM »
@AF-OFF
Thank you for the instructions on getting "full sensor" 1736x1120 raw working on the EOSM!  Very helpful!

Unsure on this bit:
Quote
Go to ML menu -> Scripts and select one of the mv1080p_12bit scripts.

There is a selection?  Which one is best?

Now I just have to figure out the easiest post "workflow" in Linux.

Thanks!

3
General Help Q&A / Re: Strange overriding dialog
« on: July 16, 2018, 07:11:16 PM »
Looks like a console with boot messages.

I am fairly certain that there is an ML menu setting to enable/disable this console.  I think there is such a setting in modules/debug.

Perhaps someone more knowledgeable can chime in.

4
Raw Video / Re: Uncompressed 14-bit RAW video testing - 5D Mark III
« on: June 08, 2018, 03:44:49 PM »
Ok, but if the resolution is the same in a case, color depth and bit depth has the same value.
Well, resolution and bit depth are the two, equally-weighted factors of digital color depth.  So, if the value of one of those factors remains constant (resolution, in your case), the color depth will change with the value of the other factor (bit depth, in your case).

Likewise, a 10-bit HD image will have less color depth than a 10-bit 4K image.

Also, an 8-bit 8K image will have more color depth than a 10-bit HD image. 

Don't really get the point of binning pixels? The image will still use the same amount of storage? Say if you go from 1080p 8-bit - to binning pixels and 10-bit?
Yes.  The "storage" required is essentially the color depth of a digital image.

In film you always talk about bit depth and the image resolution is known, in my world its not wrong as it affect color depth and always get same value if the resolution is the same.
Yes.  As acknowledged above, if the resolution remains constant in a digital system, the color depth increases/decreases with a change in bit depth.

However, with actual "film," there is no "bit depth" -- analog film is not digital.  So color depth of actual film comes from resolution (grain size) and from dye/emulsion properties (which, in combination, can be considered the analog "equivalent" of bit depth).

But yes this pixelbinning thing is possible, I understand how it affect bitdepth and color depth if you alter resolution, but why use it? Just because its possible?
In any situation in which one is down-scaling an image (such as the common 4K-to-HD conversion), it makes sense to bin the pixels to retain the color depth (and to also reduce noise and to avoid moire/aliasing).

Yes and even if the colordepth is increased?
The color depth of a digital image can never be increased, unless something artificial is added.

If you record your 8-bit signal within a 16-bit file, it won't be better then the original 8-bit/8 bits per channel (color depth).
Yes.  The image will not improve merely by putting it into a file/system of a higher bit depth.  On the other hand, in doing so you will technically have an image of a higher bit depth.

5
Raw Video / Re: Uncompressed 14-bit RAW video testing - 5D Mark III
« on: June 08, 2018, 06:13:35 AM »
This product claims to use supersampling which results in a pseudo-10-bit color sampling for improved color reproduction. Does this mean that encoding with this product will result in better quality than the original 8-bit hdmi?
Bit depth can be genuinely increased by binning together adjacent pixel groups.  However, resolution is sacrificed with such a method.

Also, such an increase in bit depth will not improve the color depth, as the color depth of an image can never be increased unless something artificial is added.  Contrary to popular belief, bit depth is not color depth.

Furthermore, artifacts in the original image (such as banding) will remain even if the bit depth is increased.

6
Looks good!

Thanks!

7
Camera-specific discussion / Re: Canon EOS M
« on: April 25, 2018, 10:20:49 AM »
dpjpandone worked on that code and he has moved on to other interests but his build with the All-I/GOP controls is still in his Dropbox and his Bitbucket account is still online though I couldn't find anything related to what you're looking for in there.

Thanks for the links!

I have already installed dpjpandone's build and enabled ALL-I and boosted the bitrate to 1.5x.  Will test soon, and, if there are no glitches, I will gradually increase the bitrate until the video breaks.

Quote
The topic you referred to seems pretty clear. Just uncomment this line:

platform/EOSM.202/features.h
Code: [Select]
//~ #define FEATURE_VIDEO_HACKS // unclean patching

and add these lines:

platform/EOSM.202/Makefile.setup.default
Code: [Select]
ML_SRC_EXTRA_OBJS = \
 video_hacksU.o \

Thank you!  So I can uncomment and add said lines to any recent version of ML source code?


Quote
Does clearing the settings remove the picture styles? I'm not sure, I'd have to try it out and see.
I think it does... it's mentioned in the ML install instructions.


Quote
Resetting the Canon settings usually isn't necessary. For me I found it sometimes helps after doing a Canon firmware update but otherwise I rarely clear the settings.
Thanks!!!  That was very helpful to know!  Saved me a lot of hassle!

8
Camera-specific discussion / Re: Canon EOS M
« on: April 24, 2018, 05:07:51 AM »
@dfort:

Thank you for the prompt reply!

I found where I previously inquired about the All-I/GOP controls in this thread here:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg156491#msg156491

You directed me to another thread in which some of the steps were outlined on compiling the GOP control:
https://www.magiclantern.fm/forum/index.php?topic=15685.msg152612#msg152612

I am unsure on a few things.  Is the code mentioned in the thread above included in the source, so all I have to do is uncomment the lines before compiling?  If not, where do I paste the lines into the source?

Also, I have read that it is suggested to reset the camera before installing ML.  Is this always necessary?  Doing so is problematic for me as I run Linux and have picture styles installed -- I would have to get access to a Windows/Mac machine to reinstall those picture styles.

Thanks!

9
Camera-specific discussion / Re: Canon EOS M
« on: April 23, 2018, 07:57:52 AM »
Hi!

Great work being done with the EOSM (and other models) in regards to raw with SD card overclock!

However, I am one of those strange outcasts who is still interested in shooting h264 with ALL-I frames.  Has any progress been made in getting GOP controls into the main build?

One big advantage of h264 ALL-I is that it utilizes the entire area of the sensor, so that the character of lenses designed for APS-C/S35 doesn't get obliterated by using a crop mode.

If it is not in the main build, instructions on where to get the code and how to compile it would be greatly appreciated.  I have installed the gcc-arm-none-eabi package on my Debian-derived distro, but I am a little rusty on compiling procedures.

As I understand, there is a 3x3 binned raw mode that allows the use of the full width of the sensor.  Is that correct?  If so, that might work, as long as there is no excessive aliasing/moire nor a pink dot problem.  From my scans of the threads, I gather that @dfort has made EOSM pink dot masks, but I am not sure how to apply them.

Thanks!

10
Camera-specific discussion / Re: Canon EOS M
« on: December 21, 2015, 07:26:43 AM »
Keep up the great work!!!

Thanks!

11
Camera-specific discussion / Re: Canon EOS M
« on: November 05, 2015, 07:53:26 AM »
Thanks, Licaon_Kter.

Is the "catch" the problem that is described in this passage (from the dpjpandone post in the thread linked above):
Quote from:  dpjpandone
If i recall correctly, the reason this is not included in main, is because the settings persist until you restart the camera, not only this, but the camera must be restarted with the same card (with the current implementation) in order to clear the settings, this presents a dangerous situation, as someone who isn't aware of this might remove their magic lantern card, and the GOP/flush settings don't go back to default

If so, I might keep using the "unmentionable fork" and its GOP controls, as, even though it is outdated, it doesn't seem to have this problem.

12
Camera-specific discussion / Re: Canon EOS M
« on: November 04, 2015, 03:16:44 AM »
Thanks, dfort.

It appears perhaps that Licaon_Kter knows something that we don't.  The dpjpandone thread that you link indicate that there were extensive GOP and flush rate settings back in August, but dpjpandone recommended having only the choice between IPP and ALL-I.  However, Licaon_Kter seemed to imply that now there is only the choice of either IPP or ALL-I (with a locked, default flush rate), in coincidence with dpjpandone's recommendation.

Were dpjpandone's suggestions incorporated since last August, and, if so, could that be the reason why your compile attempt failed?

13
Camera-specific discussion / Re: Canon EOS M
« on: November 01, 2015, 06:29:17 PM »
Thanks!  ALL-I is great!

Is this feature enabled, or does one have to compile?

14
Camera-specific discussion / Re: Canon EOS M
« on: November 01, 2015, 07:14:58 AM »
Do we have GOP controls yet on the EOSM?

Thanks!

15
Feature Requests / Re: Request: h264 GOP control in ML
« on: January 06, 2015, 06:38:39 AM »
Request for GOP control seconded!

16
General Help Q&A / Re: EOS M Help for newbie
« on: May 26, 2014, 02:30:35 AM »
Nothing happens when I hit any other key to bring up the ML Menu.
How is one supposed to do that?

Try tapping the touchscreen with two fingers.

17
Camera-specific discussion / 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!

18
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.

19
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!

20
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.


Quote from: chmee
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.


Quote from: chmee
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.


Quote from: chmee
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.


Quote from: chmee
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.


Quote from: chmee
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.


Quote from: chmee
[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.

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

Basically agree.  Might word it a little differently.


Quote from: Audionut
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.


Quote from: Audionut
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).

22
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.


Quote from: chmee
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.


Quote from: chmee
"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.


Quote from: chmee
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.


Quote from: chmee
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).


Quote from: chmee
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.


Quote from: chmee
a switch with two states has no dynamic range.

Two shades can have dynamic range.


Quote from: chmee
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.


Quote from: chmee
[/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.


Quote from: chmee
"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)3

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.

23
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.


Quote from: chmee
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.


Quote from: chmee
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.


Quote from: chmee
(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.

24
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.


Quote from: CyJackX
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.

25
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."

Pages: [1] 2 3