Sign In

Red5

User Group
Members
Join date
17-Nov-2003
Last activity
4-Sep-2015
Posts
94

Post History

Post
#674804
Topic
team negative1 - star wars 1977 - 35mm theatrical version (release details and updates)
Time

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.

 

Post
#662267
Topic
team negative1 - star wars 1977 - 35mm theatrical version (release details and updates)
Time

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.

Post
#661977
Topic
team negative1 - star wars 1977 - 35mm theatrical version (release details and updates)
Time

team_negative1 said:

Another sample of ROTJ:

========================

http://img844.imageshack.us/img844/1031/nbny.th.jpg

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?

 

Post
#586220
Topic
Making our own 35mm preservation--my crazy proposal
Time

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.

 

Post
#585696
Topic
Making our own 35mm preservation--my crazy proposal
Time

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.

 

Post
#581676
Topic
Get rid of the Chroma Shift in Empire (GOUT)
Time

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.

Post
#581579
Topic
Get rid of the Chroma Shift in Empire (GOUT)
Time

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.

 

Post
#581471
Topic
Get rid of the Chroma Shift in Empire (GOUT)
Time

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

 

Post
#581279
Topic
Get rid of the Chroma Shift in Empire (GOUT)
Time

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

 

Post
#566299
Topic
Star Wars Colortiming & Cinematography (was What changes was done to STAR WARS in '93?)
Time

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.

 

Post
#566297
Topic
Best source for the Mos Eisley speeder pass-by shot
Time

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.