- Post
- #787839
- Topic
- Info: Millennium Falcon drone
- Link
- https://originaltrilogy.com/post/id/787839/action/topic#787839
- Time
TV's Frink said:
Darn it, for a second I thought RedFive was back.
lol, for just a second? you catch on pretty quick.
TV's Frink said:
Darn it, for a second I thought RedFive was back.
lol, for just a second? you catch on pretty quick.
http://www.engadget.com/2015/09/03/disney-is-selling-a-millennium-falcon-drone-starting-tomorrow/
What a piece of (high-tech) junk 😉
and why didn’t we have toys like that when I was a kid. 😦
Don't know if this ever been posted here.
https://www.youtube.com/watch?v=akS9vnPf80g
anyway, it should have been...
team_negative1 said:
Here is a previously posted partial comparison, between the Bluray (Top), and our cleaned and stabilized version on the Bottom:
========================================================
http://www.dailymotion.com/video/k6pZLtY4DKauXf4Ykxi
Note the many missing frames from the Bluray, and the overly bright color correction.
While there is more detail there, this does not seem to match up with what would have been projected in theaters.
Team Negative1
hmm, this is strange because I found even more frames missing than you already pointed out in your BR sample, but when I also found a duplicated frame I started to suspect your BR source might be the problem. And as far as I bothered to check all frames are intact in my BR source.
I don't think frames missing here and there in the middle of scenes on official releases are a common problem, framecount differences are usually caused by uncareful trimming/splicing at the beginning or end of scenes.
thorr said:
I respectfully disagree that they are soft. If you ignore the "softness" of the movie, and look more closely at the fine details of the image, it is very sharp. There is some print damage on the frame and you can see it clearly. I don't think a 4K, 10K or whatever is going to get much more out of it. It is what it is.
I was looking at the print damage too and got the impression it could possibly be sharper. Also I was looking for the grain structure but that sample is probably to compressed to determine that. I feel the grain is very important to capture/preserve as it is random from frame to frame and thereby can contain/reproduce more detail when film is played and the grain pattern gets 'temporal added up' (so to speak).
Still team -1 efforts and results are amazing no question there.
team_negative1 said:
Another sample of ROTJ:
========================
http://img844.imageshack.us/img844/1031/nbny.jpg
Team Negative1
Very nice samples although a bit soft and I do have a feeling a 'real' film scanner could squeeze out even more details, hopefully this will be your next upgrade :-) yeah I know not that easy to accomplish, but still, awesome prints like this certainly deserve it.
Are you 'scaning' with a camcorder now instead of the canon compacts, are you going to rescan the SW print?
yeah manual IVTC is some work but more or less the only way to do it if you want it done properly.
if only the GOUT had had it done that way it would've been so much better.
[edited]
[edited]
negative1 said:
ww12345 said:
It shouldn't case color shift unless it was on an Eastman stock or something fade-prone, in which case the colors being removed would be part of the base dissolving or decomposing.
Filmguard is cleaning out that scratch line - it has minor cleaning properties. Basically, when you see a black scratch, that is dirt in the hole. Each of the other colors are emulsion layers being exposed, until you get to the white/clear base color of the film!
correct, this is what cinch has to say about it:
"no, it doesn't alter color space at all. the change on the dolby trailer was just due to different color temperatures set on the capturing cam, that's all. filmguard doesn't even cause changes in opacity, so it is optically clear."
later
-1
Good to hear, I suspected different settings had caused the colourshift after I also watched the oceans 11 sample which didn't show any noticeable shift at all, although here the cleaning effect wasn't as pronounced either compared to the DD sample.
Do you plan to recapture whole SW and possibly ESB with FG treatment then? if these promising test results seems consistent of course.
Filmguard (right sample) seems effective even on long vertical scratches (or dirt lines?), perhaps almost too effective as some light is beginning to shine through on the right edge of the scratch, so you'll get a white line instead of a black one, but overall the cleaning effect is quite impressive.
Is the colour shift caused by Filmguard? there's much less green in the treated sample.
A few more slight changes:
(129158 - 129574) changed to:
129146 - 129574
this is a strange one the error actually occur before the scene change.
(166214 - 167938) changed to:
166214 - 168066
(168300 - 168761) changed to:
168237 - 168761
Hopefully this is all of it, all the main affected areas was already found by msycamore and I really don't think I'm going to find more of them. So it seems all that's needed is the slight adjustment on some of the frame numbers to account for the blue shift.
Here's a smoother sample, with the script that shifts the blue more on the right side than on the left side (top sample), which is slightly better for this particular scene than the chromashift(c=2) (bottom sample), but perhaps not really worth the extra hassle.
Moth3r said:
Red5, what are you using to view the video and take screenshots? Your viewer is not interpolating/upsampling the chroma when converting YV12 into RGB - you can tell by the blockiness at the extremities of the strong reds.
I seem to recall you get this if you load an AviSynth script which delivers YV12 into VirtualDub - you can get smoother results if you add ConvertToRGB() at the end of the script.
Yeah I see what you mean, I was using old Virtualdubmod and actually had the ConverttoRGB() at the end of my test/work script although mostly for CCE mpg encoding reasons, I didn't know this also resulted in smoother RGB conversion, but now it was bypassed by a return(last) further up the script. Thanks for the information this is good to know.
Nothing more from me, not right now anyway ;-)
msycamore said:
Before I update the first post, are we sure this blue shift is present on all those parts in the transfer?
As You_Too already said the blue shift seems to follow the red shift close enough in most of the affected scenes.
Although I would suggest these slight changes to your frame numbers.
(90888 - 96650) changed to:
90888 - 96324
96447 - 96650
(96325 - 96446 is then untouched)
And (163146 - 165249) changed to:
163146 - 165306
^ I should have been clearer, I was talking about your main chromashift-fix.
Look at the three blue lights bottom left, top sample has chromashift(V=2), bottom sample has chromashift(V=2,U=2)
@msycamore, here's a sample with my script, no colourspace conversion needed.
BTW did you try also shifting the blue plane the same amount and places as the red i.e. chromashift(v=2,u=2) , the blue error isn't as obvious as the red but it's definitely noticeable.
^ Yeah it's true you can't fix that with the chromashift filter but you should be able to resize only the U (blue) plane i.e. like this:
(just a quick and dirty example, there're probably better ways to do it)
blue=last.bicubicresize(724,480)
mt_lutxy(last,blue,y=2,v=2,u=4)
you'll need the masktool filter.
Great find BTW with the chroma errors, they are indeed ugly and very 'unfilmlike' and really need to be fixed.
Thanks for the update -1, great to hear the project is steadily progressing.
Looking forward to some samples of the filmguard cleaning process.
negative1 said:
Red5 said:
-1, I think you have a colorspace conversion error in those samples.
Black level is at 16 should be 0
White level is at 235 should be 255
Sometimes it gets this way depending on the program used to create the jpgs.yeah, this is a simple export from avidemux,
i didn't mess around with the colors or options originally.
one quick of changing the black levels blew out the whites.
feel free to correct, and post results.
later
-1
No real need to correct the contrast is pretty good as it is, but perhaps in other samples it could be more noticeable.
I usually export from virtualdubmod, if it accepts the video file that is, and it won't do jpgs.
Thanks -1
Interesting to see how much more is visible in the 35mm compared to the GOUT even after cropping the rounded corners, right side should perhaps be cropped slightly more and it also depends on how much you can keep due to the overall condition of the print, it still looks a bit to smooth though probably due to rescaling/compression.
-1, I think you have a colorspace conversion error in those samples.
Black level is at 16 should be 0
White level is at 235 should be 255
Sometimes it gets this way depending on the program used to create the jpgs.
-1 what type of denoising are you using or is the smooth look just a result of downscaling, would love to see one or two raw.
Those lines should not be there. But what caused them I've no idea. maybe it could be that your disc actually is faulty but I would first try it in another player.