Messages

Yeah, sure, a great high-resolution flip-screen is the thing missing in 50D.

I have a question. If I understand things right, the 600D feeds a low resolution image to the H.264 codec, then it is upscaled to 1080p resolution, so basically, this means that the 1080p H.264 it's NOT a real Full HD resolution, isn't it ? Well, in this case, what if we match with RAW the same original resolution that H.264 gets before rescales the video ? In that case, doesn't it mean, that we have obtained the 1080p ? We just need to upscale the raw video to 1080p just like the H.264 does. Correct me if I'm wrong on this please.

That resolution is 1732 X 974, just slightly smaller than 1080p.

The only real aspect ratio that I think is still missing is 2.40:1 (Bluray 1920x800 standard), cause 2.39 doesn't divide evenly.

P.S. But assuming that resolutions are equal to multiples of 32, it makes no difference between 2.39/2.40 anyway...

What does 3x zoom mode give to h264 and what's the difference? (I can't see it)

Yea, it just stopped working immediately.. it never flushed a single buffer. Maybe on 255M you'd get a decent string of frames.

So does it work slowly, or doesn't work at all? Maybe a buggy asm? If try at 320x240 or 160x120 res - is the concept working?

Maybe d's from canon, and he gave us an incomplete puzzle that we need to solve ourselves?
Or maybe d's from canon and he gave us a non working code sample so we lose our heart and don't try 10-12 bit raw again?

I was more meaning what's the correct way to stretch it back to the correct aspect ratio, e.g half the horizontal resolution

There is no FAQ yet, because changes are evolving constantly. First and most important - raw is a crop from the sensor center (or side), and that's the biggest problem - cause you get even more crop to your 1.6x canon crop.
Also setting different canon modes impacts on how raw is shoot:
- 1920p mode is normal, but can be more slow (cause canon YUV buffers are big and consume more space).
- 720p@50/60fps is squeezed vertically at 166% ratio, so you can record more sensor at the same bandwidth (so less crop). But you loose vertical details and need to stretch it in post by 166%.
- 640x480p mode is fast (cause YUV buffers are small and leave more memory/cpu to raw) - so that's a preferable mode if you don't like squeeze.

Also you need to control fps with FPS Override (cause raw can't shoot long on 50/60fps - too much bandwidth).

That's generally it. Read the whole thread from the beginning, and you'll understand much more about it.

I see that the problem is that every line of text is called from different function, so it will be hard to combine everything in one line.

But also I see that there are coordinates, so maybe the parts of text can be just spread across the screen horizontally and hope that they won't overwrite each other?

Worth a shot but the numbers contract.
So you'll get stuff like this:
<**.>   5247F3984MB 20.8MB/s001.RAW

Then format it With spaces, tabs, or whatever. Leading zeroes, etc...

Surely it will overwrite something. It's the matter of _how much_ it will overwrite. Now it overwrites the CPU load :-)

One line in the bottom (or top) looks like the best option.

Weird if its pinking up in 720P with GD off... I'll have to shoot  a bunch of long files and see. I made the memory less aggressive between then but I don't think any other major changes. I can put it back since pink frames are from CPU hiccups. Preview lets you see them real time.. but also causes them..

Dunno, maybe worth a try. The videos aren't long. I shoot high res like 1536, 1600, 1728 etc, with 100-300 frames - and sometimes they appear (3-5 of them for 200-300 frames).
Yesterday was a worst pink-day - shot a great thunder-storm from inside on a field, but each and every vid had pink-frames :-(
Today shot kids in a park, and got only 2-3 shot corrupt of around 20 shot.

Maybe it's some electro-magnetism? :-D

---

Btw, raw over-contrast playback is a playback issue. Just caught it:


You can see that the same video played twice - first one on the left is very "blacky", and the second playback (and beyond) - on the right - it played back normally.

Then shot a bunch of videos without noticing playback issues (except the first frame from previous happening sometimes), and caught it again, but after second playback it also became normal.

So just some playback problem.

Have to test 1728... that area had problems originally. Full res would come out at the wrong width (all frames were pink). Hopefully this was sloved with raw rec rewrites. Other pink frames would be from GD.

1728 works okay now, using it from time to time.

Either this is a converter bug or last "cut off" frame remains in memory. I haven't seen this with in camera playback. Will be on the lookout.

This appears in RAWanizer, and in raw2dng, and even in-camera (btw, if changed resolution of the next recording - then the first frame is garbage). So seems that it remains in memory. Than means that there's a bug there somewhere (maybe causing pinkframes too?)

Playback issue is a bit weird, they seem to play back normally for me, just slow and grayscale.

I will try to picture how it looks on-camera, to test whether it's a playback issue or recorded raw issue. Just need to "catch" it, and also need to have the possibility to playback earlier raw-file, so waiting for new build.


Also I'm having random pink-frames from time to time. Say the first one is with pink one, then I can do 5-10 videos without any pink-frames. And then a couple with. And then without again...
I remember that when I was using "[600D] Aspect Lock.zip build + newest raw_rec.mo" on 27 May (see video in reply #295 http://www.magiclantern.fm/forum/index.php?topic=5494.msg41262#msg41262 ) - I didn't get any pink-frames at any resolutions (all complete recordings from that day are in the video, and there are no pink frames visible)). And on one of the latest builds they appeared again.

If you're going to move recording stats to the bottom, so it doesn't cover CPU usage, then I'll investigate the CPU stats and it's dependency on pink-frames. Maybe some service runs in the background occasionally and loads full-cpu? Or something...

Mainly shooting 720p squeezed, GD off.

Yes, I confirm the bug:
- Some RAW files have the first frame DNG from previous RAW sequence. It's not identical to the last frame from previous RAW, it just somehow is written to the next RAW container instead of the previous one.

Also when I playback some RAWs in-camera - they're displayed very black and over-contrast. And other RAWs does not - displayed normally, smooth grayscale.

Btw, shoot something today, and noticed that the first frame of the video is the same as the last frame from previous video. Dunno, maybe it's RAWanizer messing something up, can check tomorrow again with raw2dng.

Oh! Finally! Fixed the squeeze koeff to 3:2! Thanks, waited for it.

Started getting pink frames, btw (even on previous build, just after saying I didn't get any for a moment

I dunno, I didn't get any magenta frames for a week or so (the last one I remember was when I shot Silent Pics with Global Draw On).

Magenta / Pink frames are the enemy / challenge now.
Everything is working fine, but magenta frames...
It would be good idea all developers concentrate in this major issue from now...

Global Draw Off? Do you record in Video mode with 640x480 canon resolution? PAL?

@1%: Since raw is a dead end on the 600D (Even with 8-bit compression we couldn't record higher than 1280 X 720 ), what's about recording YUV 422? Is anybody still working on that for the low speed cameras?

I also wouldn't say it's dead. With 8bit we can get a full-sensor 1728x543 with lineskipping. Which then can be stretched to 1728x905, that is just a bit less than 16:9 ratio.

Now it's just that we still have only 14bit, and I'm losing hope that we ever turn it down to 12/10/8...

The new "[600D] New.zip" build now works okay, without any "File create" error. Thanks!

I have 2.3 plus the nightly build (5-29-13) plus the Tragic Lantern build (800 Fileman)

Hm... I never installed ML nightly builds... just Tragic Latern over ordinary latest 2012 build.
Is nightly necessary?

I also have "File create error" with [600D] 800Fileman.zip.

Tried the latest nightly build from 29 May, but same.

Card is formatted exFat.

my malloc total is 96M, can I increase it someway?
do you think is it better to let canon menu in 1920 x 1080 24p or would be better to set it to 640 x 480 25p + fps override to 24p?

Half of this thread is about dev-guys finding a way to increase it

Yes, sure 640p with fps override 23.976 (or something near) is needed. Maybe that's your problem also.
And Global draw OFF.

You guys could be looking at the registers to see if 10bit can be made in camera.. there are functions like set_craw bits, etc. Just have to find the correct one.

Could you tell please where can we look at these?

The magic lantern team is known to be tireless in making canon cameras rocks. I am sure you all are doing your best for raw.

So here is a list of widths wich are close to the maximum resolution 600D can handle without skip frames or magenta frames in 16:9

856, 854, 852, 850, 848, 846, 844, 842, 840, 838, 836, 834, 832, 830, 828, 826, 824, 822, 820, 816

a tip would be to start from the highest values and go decreasing until find which one works good.

many thanks

I guess only implementing the custom resolution (at least for testing period) can make everyone happy

I am not expert in computing, but as far as I have known, the LUT things looks very good, but that sounds that we will have a lot of codes like: if x<y0 and if x>y1, x=y2, these kinds of codes are known to stall the CPU to a halt. d's method should be more suitable for CPU to do, and it already working real time reportedly by several one here who have actually loaded it into camera and tried, and we only don't know why the program halts. Maybe d can mercifully display his source code, maybe there will be someone who can look closely to see if there is something more we can do. d's method sound more straight-forward to me, and easier. To achieve better rounding and accuracy probably, soundingly to me, we only need to change from (x * 12) / 14 to (x * 2^12) / 2 ^ 14, and the cpu might be able to collaborate with that.

Nope, LUT things will be just y = lut [ x ], and that's all.

And about the calculations you mention - they are easily done (like g3gg0 said) with bit shifting:
Raw14b: 13598 = 0011 0101 0001 1110
Shift 2 bits right =>12bit = 0000 1101 0100 0111 = 3399
13598 * 2^12 / 2^14 = 13598 * 4096 / 16384 = 3399.5 = 3400

So no need for calculations at all. Rsh solves it on cpu-elementary level.
If you need better rounding (like said), add half of the bits (2bits = 4, so add 2) to number before shifting:
(13598+2) = 13600
13600 Rsh 2 = 3400

Bug I have found with the latest "Still sprinkle free."  When hacked mode is on my screen locks up and starts shaking back and forth.  It continues to record and I can stop it but it happens every time hacked mode is enabled.  Using a SanDisk 30 MB/s 16gb card.

That's what the hacking mode is all about - freezing live-view to gain speed, so it's normal.

Huh... who thought Canon would scan the full 3:2 frame when they struggle with line skipping to keep with the high fps...

Yup. Well who knows, maybe scanning the full sensor, skipping half of the lines is faster, than cropping the 16:9 region from sensor...