Menu

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.

Show posts Menu

Messages - guentergunter

#1
Raw Video / Re: Raw video on 5DMK2
September 09, 2014, 08:23:21 AM
Thank you reddeercity!

Quote from: reddeercity on September 09, 2014, 12:40:09 AM
@guentergunter, To me looks like Card write problems , I use to see this with my Slower Cards at higher frame resolution (Sandisk 60Mb/s cards).
Did you try an older build of raw2cdng to convert ?
I use Version 1.4.9 as it is the only version that can be read Cross platform (Mac/PC) with out green or pink cast at 16bit.

The pink cast is no big problem - since I convert and edit the footage in ProRes4444.
But I'll try that version out! Maybe I'll switch to native CDNG-editing in the future.

Quote from: reddeercity on September 09, 2014, 12:40:09 AM
So I don't think ML is the problem , More to do with Getting Hot and Card Write issue.
I know when my Lexar 1000x 64GB gets too hot it will drop frame even on lower resolution ,
usually after about an hour or so, and that's with 5D2.

What CF Cards are you using ?
What Raw build are you using ?

I'm using two Lexar 1000x card (64GB and 32GB) and one SanDisc Extreme Pro 90MB/s (32GB).
I used the "magiclantern-v2.3.NEXT.2013Sep08.5D2212" together with a.d.'s modification "6bb97bcbc0f4" (also build around this date).

Now that you say it: It could have been a heat problem.
Since the problem occurred on at least two cards (I don't remember witch ones), all brands are affected.


Would you say, that the actual nightly build "magiclantern-Nightly.2014Sep01.5D2212" is safe for production work?
Anyone knows which temperature is critical?


Thanks in advance!
#2
Raw Video / Re: Raw video on 5DMK2
September 08, 2014, 08:10:01 PM
I have a really big problem with banding!

I post it here first - but maybe it's worth a new threat?
Since it's not like what I've seen over the past by myself or by others.

Here's a frame demonstrating the problem:

https://www.dropbox.com/s/ktip4trlrqriiuq/Fehler.jpg?dl=0

Here are also the 16-bit CinemaDNG files:
DNGs from RAWMagic
DNGs from raw2cdng
Both programms are the very latest versions.

After three hours on the set, the problem appeared in the middle of a take and then periodically repeated through some following takes. Then it disappeared again and after one hour or so it came back.

I tried to reproduce the problem (overheating, different frame rates (since I shot 24.000 for the first time), all CF-cards used that day, that old build and the latest build with mlv) without success.

It's recorded with raw_rec.mo from an old nightly from last year. The reason for this is:
I didn't have the time to study latest developments and wanted to go safe using a build I already and successfully recorded three short movies with.
Anyway: The problem looks like a sensor error, since it's moving through the frame from bottom to top (with a duration of 2-3 frames).

I'm also afraid of just using MLV - since I'm not sure, if the problem really comes from that old build or rather from ML or the cam.


Any help would highly be appreciated!
#3
Quote from: reddeercity on April 08, 2014, 08:35:30 PM
Edit: use adobe color space in camera , will give you better skin tones and better color in general.

In other words: you claim, that the image recorded by raw_rec or mlv_rec differs when you change the color space of the camera?
That's not true!

"Adobe Color Space" is a RGB color space and thus NOT raw! It's used for compressing to jpg. So, the RAW buffer, ML reads from is not affected.

[However, when you shot pictures in (Canon)RAW, the embedded preview file differs (since it's compressed to RGB).]


It's up to everyone in what color space one works later on the computer. Here you will definitely get different results. But the .raw or .mlv files will always look the same!
#4
Magic Lantern v2.3 - Install Guide

I never saw any .cpgz file.
I suggest to delete and ignore it and/or to use another zip application.
By the way: OSX (just as windows) can unzip zip files right from the finder without any third party software. And it does it correctly!
#5
Hello g3gg0,
since a few days now there's a discussion about the future resolutions available for the 5D2 (and maybe other cameras).

It started with a1ex:

Quote from: a1ex on March 14, 2014, 09:55:26 PM
The horizontal resolution is restricted to multiples of 8 bytes and 16 pixels according to latest findings. This restriction is valid at least for 5D3 and 6D (didn't do much testing on other cameras), but I'd like to keep the code portable without camera-specific exceptions.

So, before including this change in nightly builds, I'd like to ask you which is better: 1888 with 8 pixels of black border that you will have to crop, or 1856 without any border pixels? Between these 2 values, there are no valid resolutions that respect the alignment restrictions.

This change was discussed here:

http://www.magiclantern.fm/forum/index.php?topic=3904.msg106087#msg106087
https://bitbucket.org/hudson/magic-lantern/pull-request/438/raw-recording-force-line-size-to-be/diff


In my opinion, it would be no problem to simply discard black borders from an image while converting to dng:


Quote from: guentergunter on March 24, 2014, 08:39:02 AM
...and it's also no coding effort to discard pixels while converting to dng. The user wouldn't even realize it!
This way, no one has to crop anything actively in post! It's simply done in background in the ever necessary converting (to dng) step.

I'm no programmer (just some very basic skills).
Thus it would be really great, if you could just leave a little comment about it as a programmer to help us sort things out for the 5D2 (and other cameras with the same problem):

Specific 5D2 threat

Thank you very much!
#6
Hello gnarr,
since a few days now there's a discussion about the future resolutions available for the 5D2 (and maybe other cameras).

It started with a1ex:

Quote from: a1ex on March 14, 2014, 09:55:26 PM
The horizontal resolution is restricted to multiples of 8 bytes and 16 pixels according to latest findings. This restriction is valid at least for 5D3 and 6D (didn't do much testing on other cameras), but I'd like to keep the code portable without camera-specific exceptions.

So, before including this change in nightly builds, I'd like to ask you which is better: 1888 with 8 pixels of black border that you will have to crop, or 1856 without any border pixels? Between these 2 values, there are no valid resolutions that respect the alignment restrictions.

This change was discussed here:

http://www.magiclantern.fm/forum/index.php?topic=3904.msg106087#msg106087
https://bitbucket.org/hudson/magic-lantern/pull-request/438/raw-recording-force-line-size-to-be/diff


In my opinion, it would be no problem to simply discard black borders from an image while converting to dng:


Quote from: guentergunter on March 24, 2014, 08:39:02 AM
...and it's also no coding effort to discard pixels while converting to dng. The user wouldn't even realize it!
This way, no one has to crop anything actively in post! It's simply done in background in the ever necessary converting (to dng) step.

I'm no programmer (just some very basic skills).
Thus it would be really great, if you could just leave a little comment about it as a programmer to help us sort things out for the 5D2 (and other cameras with the same problem):

Specific 5D2 threat

Thank you very much!
#7
Hello marten,
since a few days now there's a discussion about the future resolutions available for the 5D2 (and maybe other cameras).

It started with a1ex:

Quote from: a1ex on March 14, 2014, 09:55:26 PM
The horizontal resolution is restricted to multiples of 8 bytes and 16 pixels according to latest findings. This restriction is valid at least for 5D3 and 6D (didn't do much testing on other cameras), but I'd like to keep the code portable without camera-specific exceptions.

So, before including this change in nightly builds, I'd like to ask you which is better: 1888 with 8 pixels of black border that you will have to crop, or 1856 without any border pixels? Between these 2 values, there are no valid resolutions that respect the alignment restrictions.

This change was discussed here:

http://www.magiclantern.fm/forum/index.php?topic=3904.msg106087#msg106087
https://bitbucket.org/hudson/magic-lantern/pull-request/438/raw-recording-force-line-size-to-be/diff


In my opinion, it would be no problem to simply discard black borders from an image while converting to dng:


Quote from: guentergunter on March 24, 2014, 08:39:02 AM
...and it's also no coding effort to discard pixels while converting to dng. The user wouldn't even realize it!
This way, no one has to crop anything actively in post! It's simply done in background in the ever necessary converting (to dng) step.

I'm no programmer (just some very basic skills).
Thus it would be really great, if you could just leave a little comment about it as a programmer to help us sort things out for the 5D2 (and other cameras with the same problem):

Specific 5D2 threat

Thank you very much!
#8
Hello tonybeccar,
since a few days now there's a discussion about the future resolutions available for the 5D2 (and maybe other cameras).

It started with a1ex:

Quote from: a1ex on March 14, 2014, 09:55:26 PM
The horizontal resolution is restricted to multiples of 8 bytes and 16 pixels according to latest findings. This restriction is valid at least for 5D3 and 6D (didn't do much testing on other cameras), but I'd like to keep the code portable without camera-specific exceptions.

So, before including this change in nightly builds, I'd like to ask you which is better: 1888 with 8 pixels of black border that you will have to crop, or 1856 without any border pixels? Between these 2 values, there are no valid resolutions that respect the alignment restrictions.

This change was discussed here:

http://www.magiclantern.fm/forum/index.php?topic=3904.msg106087#msg106087
https://bitbucket.org/hudson/magic-lantern/pull-request/438/raw-recording-force-line-size-to-be/diff


In my opinion, it would be no problem to simply discard black borders from an image while converting to dng:


Quote from: guentergunter on March 24, 2014, 08:39:02 AM
...and it's also no coding effort to discard pixels while converting to dng. The user wouldn't even realize it!
This way, no one has to crop anything actively in post! It's simply done in background in the ever necessary converting (to dng) step.

I'm no programmer (just some very basic skills).
Thus it would be really great, if you could just leave a little comment about it as a programmer to help us sort things out for the 5D2 (and other cameras with the same problem):

Specific 5D2 threat

Thank you very much!
#9
Hello scrax,
since a few days now there's a discussion about the future resolutions available for the 5D2 (and maybe other cameras).

It started with a1ex:

Quote from: a1ex on March 14, 2014, 09:55:26 PM
The horizontal resolution is restricted to multiples of 8 bytes and 16 pixels according to latest findings. This restriction is valid at least for 5D3 and 6D (didn't do much testing on other cameras), but I'd like to keep the code portable without camera-specific exceptions.

So, before including this change in nightly builds, I'd like to ask you which is better: 1888 with 8 pixels of black border that you will have to crop, or 1856 without any border pixels? Between these 2 values, there are no valid resolutions that respect the alignment restrictions.

This change was discussed here:

http://www.magiclantern.fm/forum/index.php?topic=3904.msg106087#msg106087
https://bitbucket.org/hudson/magic-lantern/pull-request/438/raw-recording-force-line-size-to-be/diff


In my opinion, it would be no problem to simply discard black borders from an image while converting to dng:


Quote from: guentergunter on March 24, 2014, 08:39:02 AM
...and it's also no coding effort to discard pixels while converting to dng. The user wouldn't even realize it!
This way, no one has to crop anything actively in post! It's simply done in background in the ever necessary converting (to dng) step.

I'm no programmer (just some very basic skills).
Thus it would be really great, if you could just leave a little comment about it as a programmer to help us sort things out for the 5D2 (and other cameras with the same problem):

Specific 5D2 threat

Thank you very much!
#10
Quote from: a1ex on March 15, 2014, 06:53:43 PM
I can choose between 1856 and 1888 with no coding effort.

But you're right. Let's wait for the other side.
I asked already in the RAWMagic threat for a developer statement. Maybe someone with more inside in the other converters may just do it there...
#11
Quote from: Audionut on March 25, 2014, 02:15:39 AM
The entire point for the original question (1888 vs 1856), was to minimize code that is specific to a model.
Here, you want to add a bunch of code, specific, not only to a model, but to the resolution it records also.


No, according to a1ex, it's no special effort to implement 1888 into ML/MLV and maintain it.
So, the question now is: what to do with our 1888 mlv frames?


Quote from: Audionut on March 25, 2014, 02:15:39 AM
What about the checks for model and resolution?


E.g. "RAWMagic" from Thomas Worth (Click) already does check the camera model. So this little while loop could possibly be easily implemented.
The same goes for raw2dng or mlv2dng.

By the way: mlv comes with metadata about the camera model.


Quote from: Audionut on March 25, 2014, 02:15:39 AM
Cropping is a basic PP process.  It takes 1 line in an AVS script for example.


I agree, that it's very little effort.
But, I would rather crop in mlv2dng / raw2dng / RAWMagic / etc., since that doesn't need the user to take action.



To summarize the above 1888 way:

  • a minimum effort for ML is needed.
  • all dng converters need to add some simple lines into their routines; since checking for the camera model is already implemented or can easily be done due to the given metadata.
#12
Quote from: Audionut on March 24, 2014, 08:58:03 AM
Can you describe the process?

I'm no programmer, but I did some Java, C and VHDL at university. That's enough to know what's possible and to estimate the effort.

If you're already in C++ (or any other language), you could e.g. implement it with a while loop:

Given is the 2D pixel array (our frame) 'MLV_pic' with 1888 of width (thus 4 black pixels on left and right).

int crop()
{
    x = 4;
    while (x <= 1884)
    {
        DNG_pic[x-4][y] = MLV_pic[x][y];
       
        x++;
    }
}


That will give you the 2D pixel array 'DNG_pic' with 1880 of width and without the black pixels.
#13
Quote from: a1ex on March 15, 2014, 06:53:43 PM
I can choose between 1856 and 1888 with no coding effort.

...and it's also no coding effort to discard 8 pixels while converting to dng. You wouldn't even realize it!
This way, no one has to crop anything actively in post! It's simply done in background in the ever necessary converting step.

Seems like a nobrainer to me.
#14
Quote from: romainmenke on March 21, 2014, 12:57:47 AM
Not only will the 1888 exception make the camera less desirable for recording but if one day the devs decide they will no longer support the 5D2 because of exceptions like this, you will be forced to upgrade. That is what I think the essence of ML is. Upgrading existing gear through firmware updates, unlocking and creating features, so you don't have to buy new gear every year.

Future first!


Future first, but that's also true for image quality!


Quote from: xvince1 on March 21, 2014, 10:01:30 AM
To be honest, there's something I don't get : what the trouble to just add 1888 (if it's not too much complex to add in code) : All people who do not want to post-prod crop still can use 1856, and others can use max resolution ? (perhaps some notice in the readme file to warn about black border on 5D2, and that's all)


Folks, there's a solution everyone would be happy with:


You will always have to convert your footage (*.raw or *.mlv), since there's absolutely no hope, that these formats will be supported by any major NLE. You have to convert it!

So, what's wrong about the idea to crop 1888 to 1880 while converting to DNG? I guess nothing!


Besides: It's way harder to implement such resolution differences into the camera (due to performance issues, etc.). But in post, where you have to convert anyway it's equal if it takes a hundredth second more for each frame!


So, why not do it this way?
#15
Quote from: terranaut on March 17, 2014, 10:40:55 PM
if the only downside of the larger 1880 is the black column-edge pixels, any mlv converter could just have an auto-detect camera type, and when its a 5d2, crop the needed empty columns out to fit a desired ratio. or perhaps theres some type of plugin for premiere that intelligently doubles-up an images edge column pixels to fill in the adjacent black columns.

Absoluteley! Cropping the image before encoding to dng is easy to program and computed instantly.
And if I got a1ex right, it's no special coding effort to go for 1888. So, yeah I vote for that!

I'm also looking forwand for the tests from reddeercity.

P.S.: I don't see much chances for a premiere plug-in. First: You'll have to adopt it to any new version of premiere. And then? What about Finalcut or vegas or after effects or...
The faster, easier, simply better way will be to crop the borders right in the beginning while converting to dng. Then there's one program and not dozens of plug-ins.
#16
Well, there are differences. But I guess, they barely exist in real circumstances.
Also, there's so much more degradation from Moiré or crappy lenses or ISO noise, etc.
#17
The question is:
Quality (24 (effective) pixels more, no crop)   VS   A few seconds less clicking in post

I can understand, that any more steps in post drive you nuts - at least when you're in a pressure.
But I'm producing my own shorts (or other's as a camera man) without any time pressure in post. So, from this point of view, it would highly demand 1888 as for the higher resolution and no further crop.

Anyway, both options do not have much impact. But, for me it's only one thing, that drives me nuts:
Reviewing this decision from 10 years in the future, I will think: "I should have kept the reolution!" Because that is what lasts!
#18
Quote from: dd2020 on February 23, 2014, 07:14:26 AM
May I ask...
What's happen to this?
Look like ML on 5Dll cannot render  correct pixels when shooting at pattern things like buildings' windows or floors.
I used October 4th build and 32GB Sandisk CF Extreme Pro 1067X (up to 160MB/S read 150MB/S write)
Is this ML limitation of 5Dll ? or I have to change to other builds?
Or I have to upgrade to 5Dlll?

Today I will try new build, the October 24 th.

Thank you mates.

:)

Some additional info to what ted ramasola said  ;)

#19
Quote from: Kharak on February 08, 2014, 02:41:24 AM
@gunter

13:14, moneyshot! Very nice and shows the power a full frame camera.

too bad I dont understand German. I remember you published your film here, but I could only watch about 5 min as I don't understand the story :(

personal fan of wides.

Thank you :)

Btw, I just added some subtitles  ;)
#20
Quote from: edwmotion on November 23, 2013, 09:15:39 PM
haven't you noticed this?

lossless is lossy and lossy is lossless, options are inverted.

Does that problem still exist?
#21
You may wanna take a look at this little comparisson:


As you can see, Moire isn't completely eliminated with the VAF, but it's way better in the mid range.
In other words: there's still moire in really extreme cases. But the biggest part of what you'll find in the real world is gone!

----

My latest movie (see below) is entirely recorded in NON-crop-mode with the VAF. You can randomly scroll through it and will hardly see any moire.
Besides: Crop mode is free of moire (certainly without the VAF, as cmac explained really fine), but, you completely loose wide angle capabilities. Take a look at 13:14 mins. I used a 14mm-Lens - and created a look, you just can't in crop mode!



So, I would recommend a VAF with non crop mode for extreme wide angles. And once you got your VAF, the need for crop is gone in most cases (except really crazy zoom shoots).
#22
Quote from: ted ramasola on January 17, 2014, 05:16:18 PM
I would say the temp is not unusual.

I would even say: It's harmless!
Your sensor is build upon silicon transistors. And silicon can stand a lot of temerature (many hundred degrees). It's just, that components around (like housings, wires, etc.) will tire from too much heat.
But: Your camera has a build-in shut-down-safety-feature. And this feature starts long before the temerature becomes really critical!

In other word: Don't worry!  ;)

By the way: Transistors build into your computer operate all day long at temperatures beyond 50 or 60 degrees (irregardless normal cooling). And it does not harm them as well.
#23
Quote from: a.d. on January 12, 2014, 08:58:05 PM
@guentergunter
great movie and I really enjoyed your film. My favourite character is Konrad 'caused of his dialect "Grummbeer". ;) I also like the backyard setup of the business man: Roman Venus, neo-classicism and the French formal garden => cliché! ;D
btw You are quite talented in story telling!

Thank you very much! I tried to realize and implement as much of what I know about film as possible (only limited by time and costs).
So, I'm glad you enjoyed it  8)
#24
Here it is: my first movie that was entirely shoot RAW.
Beside the story and directing, I operated the camera completely myself. So, I got a feeling about how it is to go the RAW-way.

Enjoy:




The shooting time was around september last year with build 2013/09/04.
- 2.20:1
- 2 Lexar 1000x cards (32GB + 64GB)
- VAF-5D2b + several fixed ND filters
- I always tried to to exposure to the right (ETTR) as far as possible.

Also it was very time consuming to backup the cards after every 7 or 14 minutes of filming (backup took 20-40 minutes on my Laptop with external drive)
My six batteries were more than enough.
And I had no (real) problems with my two Lilliput HDMI-monitors.

I collected 1TB of just RAW-data and it several times took one complete day (!) to render the daily media (white ballenced and illumination corrected) via After Effects into ProRes4444 (witch I used to cut and grade, etc.).


On the other side: What came out is one hell of an amazing quality!!
It was absolute fun to do white ballence, grade, denoise, etc since there are no bandings and/or blocks from too much compression.

Just one thing:
Thanks to the ML-devs, I will definitely never ever have to shoot without RAW again!
Thanks!
#25
Quote from: Kharak on September 23, 2013, 02:49:46 PM
3. Are you referring to Focus peaking? Cause its available in the last 3-4 builds. Called FPeaking in menu I think and there is Digic peaking which you adjust according to the FPeaking.

Hmm, when I activate DIGIC-Peaking, the image is just pretty much sharper or it is black without any image, but with lines indicating high contrast areas.
But it's comparable at all to 'normal' peaking.

Am I missing something?