View Full Version : 4:4:4 12-bit Uncompressed DVX100


Pages : 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Stephen van Vuuren
May 5th, 2004, 02:32 AM
The google results I was hinting at are proprietary studies from Instat and iSuppli if you must know. They are only available for purchase, not for posting and linking. But the results can be inferred form the discussions and new articles on technology news sites and abstracts that reference them.

Firewire 800 was barely mentioned in the context.

First of all, you keep using "firewire" and "SATA" as equivalents - they are not. SATA is both a drive technology and a interface. Firewire is an interface only.

Firewire is a great interface and the standard for DV interconnects. I use it every day.

But storage is another matter. Capturing tapes to NLE drives is an enormous waste of time and money. Direct aquistion to disk is the future. The best low cost disk technology is SATA - now and in the future - not firewire; as firewire is not a disk technology but an interface stacked on top of disk technology.

Some firewire drives today and all firewire drives in the future will have SATA drives inside.

I'm suggested to Juan that he start with a SATA drive and firewire interface to begin with. So we agree here since you have not indicated what type of drive Juan should put inside the firewire enclosure.

But a SATA II external port will be faster, more efficient and eventually lower cost due to volume. And they will be available soon - I'm not wrong about that.

Peter Plevritis
May 5th, 2004, 03:21 AM
Some numbers.

-image size: 773x495
-3 channel 16bit TIFF file = 48bits
-single image size (uncompressed) = 2.189 MB
-52.536 MB/s at 24 fps
-60 minutes at 24fps = 185.74 GB

As has been discussed 16bit tiffs are way more than needed for the 12(10 now) bit data. But it does make it much easier to work with.


Some other numbers to note.

D1 (601) 422 ntsc uncompressed video:
720x486, 0.67 MB/frame, 20 MB/s, 60min=70.4GB

HD1080 444 24fps uncompressed video:
1920x1080, 5.9 MB/frame, 142.4 MB/s, 60min=692.5GB

Jason Rodriguez
May 5th, 2004, 07:44 AM
SATA isn't the problem that I used to think it was. There are external enclosures (although not powered which might be a problem for a hand-held camera), and the interface does support hot-swapping. Additionally you can purchase cardbus adapters for SATA, so there shouldn't be any problems on the laptop front. Frankly I think it's only a matter of time before SATA does overtake the external hard-drive market over firewire800, but that may take a year or more before stuff is readily available, right now SATA stuff is quite sparse whereas firewire800 is everywhere. So while we may argue over this fact over and over, I'd say we go with the solution that works now and gives us greater choice, because frankly if we wait around for another year just to get a hard-drive interface that we want, then they'll be something else on the horizon and nothing will ever get done.

BTW, on the other topic of 10-bit linear Cineons, all those files should be compatable with every program that supports Cineon/DPX-the reason being that the lin-log conversion takes place via a look-up table inside Shake, combustion, etc. All these programs read the log file as a linear file, that's why they look so "light" when you open them. After applying a LUT, you get the linear image the way it should look. With Juan's approach of using a linear Cineon file, you'll simply ignore the loading of the LUT.

One thing though, I thought the RGB files off the A/D converters was 12-bit. If you use a 10-bit linear Cineon, then you're loosing a lot of the highlight dynamic range. I'd say use either a 10-bit LOG Cineon to perserve that dynamic range, or else use a 16-bit Tiff file. I would find it very unfortunate that you'd have all this dynamic range and then clip off the top two bits to squeeze it into a 10-bit linear file, destroying the advantages of the extreme highlights that this camera can handle. Just my .02 cents.

Juan P. Pertierra
May 5th, 2004, 08:16 AM
I agree with Jason, and this is the same reason i came to integrate FW800 to the design. As much as SATA looks great and right now seems like it is the future, FW800 is what is available right now. Perhaps when I apply this mod to one of the new 3-CCD HD cameras, SATA will be more mainstream and we can switch over to that....besides, the added bandwidth WILL be needed then. :)

The cineon format supports 12-bit linear, so it can still accomodate all the information. I think someone said that 10-bit is the most common, but like jason says, i'd rather go 16-bit TIFF than sacrifice 2-bits/channel of color, unless the user explicitly wants to.

Juan

Jason Rodriguez
May 5th, 2004, 08:42 AM
BTW, just curious, do the 7200RPM Hitachi 2.5" HD's sustain a high enough data rate to support the 16-bit TIFF's? I was thinking you might be able to use one of those smaller drives for a "magazine" if you will, and then offload that onto a much cheaper 3.5" HD attached to a laptop after the fact (or just keep swapping out the 2.5" drives if you have the cash :-)

Juan P. Pertierra
May 5th, 2004, 09:29 AM
I checked out all the small laptop drives (including the hitachi's) that i could find, and it didn't seem like they could handle it, at least by any significant margin.

However, if you have anything particular in mind, just see if it can do at least 42MB/sec sustained write....the numbers peter posted are correct, yet a bit over-bandwidth for the actual application, since it actually captures 12-bitsRGB(36bits) and then later converts the data to 16-bit TIFF's. So the actual sustained write rate is ~42Mb/sec.

This number is for the final application however, when dummy bits are stripped out. Right now, because of all the dummy bits present in the raw images, my test computer is recording ~63MB/sec sustained, with a hard disk 2 years old that i bought at circuit city. Stripping out the dummy data and using a modern FW800 drive is a much better situation. :)

Juan

Stephen van Vuuren
May 5th, 2004, 10:30 AM
Juan:

For some reason I'm having a really hard time making this point. There is no such thing as a "FW 800" drive. Inside, you will have to put either a EIDE or SATA drive.

Guest
May 5th, 2004, 10:59 AM
You are absolutely correct Stephen. I have not seen any FW800 external cases that accept SATA drives, only EIDE. I don't think it wouldn't make a difference in speed whether a SATA or EIDE drive was used in a FW800 external case anyway.

Juan P. Pertierra
May 5th, 2004, 11:08 AM
Stephen:

I agree, and i know exactly what you mean. :)

But, what should we call my LaCie 200GB drive from now on? =)

Juan

Ben Syverson
May 5th, 2004, 01:36 PM
<< For some reason I'm having a really hard time making this point. >>

It's because it's not a very good one. We're not discussing the type of actual hard drive mechanism to use, because this project does not include an internal drive. We are discussing what kind of port to put on the box. You will then connect a cable to the port to an external drive. The external drive has an internal drive in it -- and yes, if we're talking about a FW800 drive, 99.99% of the time, there's an IDE drive in there.

But you seem to be a bit confused as to what you're arguing for. Are you really saying we should put an SATA port on Juan's box? That's what you seemed to be saying a few posts ago.

<<There is no such thing as a "FW 800" drive.>>

Wow. Actually, the term "external drive" refers to the whole package, just like "computer" doesn't just refer to the motherboard. "External drive" is often shortened to "drive," if you've already made it clear that it's external. Therefore, it's perfectly reasonable to call an external drive a "FW800 drive," or a "Firewire Drive," or a "USB2 drive," etc. It doesn't matter whether there's a SCSI or EIDE or SATA II drive. If the back of the durn thing has Firewire ports, it's a Firewire drive. Unless you're on some kind of Quixotic quest to abolish abbreviations, I'll keep on saying "firewire drive" rather than "EIDE hard drive within a FW800 enclosure."

<< inside, you will have to put either a EIDE or SATA drive. >>

Or a SCSI drive. So what are you saying? That we should use SATA in FW800 enclosures?

<< The google results I was hinting at are proprietary studies from Instat and iSuppli >>

Convenient! But unless these were studies specifically of the media/video market, and unless they were conducted at least 6 months after FW800 came out, I refuse to believe that you're somehow more informed than me on this particular issue.

Bottom line: I know FW800 is the best choice, Juan knows, Peter knows, Jason knows, everyone seems to agree that FW800 is the best currently available choice... except for you, Stephen...

- ben

Guest
May 5th, 2004, 01:57 PM
I think FW800 is the way to go (EIDE drive in a FW800 enclosure) using a FW800 cable from camera to drive. Yes, there are some using SATA external, including myself, but it is not proven itself yet and the cables are not as durable as FW especially on the road. My 2 cents.

Stephen van Vuuren
May 5th, 2004, 02:16 PM
Ben:

I think my point is an excellent point despite it's alleged unpopularity. And I always think having various perspectives is important.

Having a SATA drive in a FW800 enclose gives far more options than a EIDE drive in a FW800 enclosure. Especially if Juan offers a removable tray that could plug into a hot-sway SATA enclosure. That would be a nice speed boost over FW800. That would provide both FW800 and SATA options as well as being backwards compatible with EIDE systems (via SATA/EIDE adapter). Everybody wins.

I'm not confused about what I'm proposing. I was continuing previous discussions about this in this thread from several months ago that you were not a part of.

I said then, that by the time Juan had a working prototype, SATA II had a good chance of being ratified, which it is. I also felt that once he knows if he's just going to self-assemble a few unit on a low scale or look for a larger business model and outsource manufacturer/assembly, looking at SATA drives makes sense to me.

I still think Juan is some months at a bare minimum away from having a product to sell. While SATA II looks like pie in the sky for external drives to you right now, it might be different in several months.

I personally don't think calling something a "FW800 drive" in this thread is accurate. While that's fine for a label on a box, we are discussing Juan building a item from scratch and technical accuracy is very important. He could outsource and buy a direct drive recording but I got the impression he wanted to design and build his own.

Per the market share studies, I don't have the money for them either and sorry if I gave that impression. I did look at a number of the articles written about them and made my own conclusions. Which could be wrong.

Bottom line: All the bold lettering in the world is not going to make me less of SATA proponent. I understand why you favor FW800. Why not agree to disagree?

Stephen van Vuuren
May 5th, 2004, 02:19 PM
<<<-- Originally posted by Don Barzini : I think FW800 is the way to go (EIDE drive in a FW800 enclosure) using a FW800 cable from camera to drive. Yes, there are some using SATA external, including myself, but it is not proven itself yet and the cables are not as durable as FW especially on the road. My 2 cents. -->>>

Don:

There are several FW800 external enclosures on the market using SATA drives - I've seen mostly rack mount styles so far, not portables, but the chipsets must be out there. I recently was shopping for all sorts of drive options and recall seeing them.

Also, SATA II changes the external cabling and hopefully new, durable, longer cables will come to market quickly.

Anybody else desperate for more clips from Juan :)

Ben Syverson
May 5th, 2004, 02:30 PM
Why not agree to disagree? Because you fundamentally misunderstand what Juan is building.

He's not building something with an internal drive, hence a "removable tray" is of no use. He's building a box that will connect to an external hard drive of your choice.

Here's the important part: your choice. So if you really love SATA II that much, you'll be able to get a SATA hard drive in a FW800 enclosure.

However, you also don't realize that the FW800 drives Juan is using are perfectly adequate for this application. There's absolutely no need for a "nice speed boost over FW800," because we're not even approaching the max transfer rate of the drive, let alone the interface.

Furthermore, although Juan may be months off from shipping a product, he's developing and testing right now. You don't develop with non-existant technologies.

I just really, really, really don't understand how we can still be having this conversation...

- ben

Jon Yurek
May 5th, 2004, 02:31 PM
I think the question is why are we arguing over what's going inside the FW enclosure when the FW enclosure itself is hot swappable? You could have SATA, EIDE, SCSI, or Fibrechannel hard drives... or a RAID-style multiplex across 50,000 floppy drives for all I care. If the connection from the drive to Juan's capture device is FW800, then we, frankly, don't need to worry about what's going on inside the enclosure as long as it can handle 50MB/s sustained write speeds.

It's really not that critical. Juan said he's going with a FW800 interface, so that's what he's going with. If, at some later point he decides that SATA2 would make a better choice, then we can jump off that bridge when we come to it.

[Edit: ... yeah, and what Ben said. :P :) ]

John Cabrera
May 5th, 2004, 02:46 PM
Ben,

No one wants to be told that they "fundamentally misunderstand" something. By making statements like that you invite the converstation to continue.

Why not agree to disagree? Cause you can't say that in one sentence and then in the next tell someone their wrong.

Stephen van Vuuren
May 5th, 2004, 03:07 PM
Ben:

I am encouraging Juan to build a interface and drive mount box and/or belt-shoulder rig for the DVX or offer it as an option, perhaps even supplying the drives as well.

If he just does a port only, ie. just a Firewire FW800 and the stream down the port, a number of issues may come up:

e.g. controlling the start/stop record process, dealing with all the possible drive, enclosure and chipset combos, dealing with cable length and quality issues. It might be a real tech support compatability issue. Now if he just decides to hand assemble a few units on the side or build a few prototypes to market around, a simple FW800 port is fine.

But I think an elegant, secure, supportable drive solution is a vital part of this soluiton and would vastly increase it's usability. A partnership with an existing company that already does the direct drive recording is also an option.

Ben Syverson
May 5th, 2004, 05:17 PM
Now we can agree to disagree.

FW800 is a robust standard that can easily support groundbreaking features such as "stop" and "start," and you need only look at the many FW DTD solutions to see that this is easily done.

I don't believe you'd have to support chipsets individually -- I think FW800 abstracts them and provides a common interface. However, you may need some way for the device to know the physical details of the drive -- can these be queried from the drive over FW? Juan may know.

Having a port is the most elegant option, since it allows the maximum flexibility. It may not be as easy as an affixed drive, but from what Juan has said, it doesn't seem to be a massive hurdle either.

Now, since Juan has all but settled on a box with a FW800 port, can we once and for all drop this aspect of the discussion?

- ben

Stephen van Vuuren
May 5th, 2004, 05:55 PM
Ben:

If you find the discussions tiresome, don't particapate. Your recent posts directed towards me appear to contain a lot of frustration, sarcasm and condensation. If that's not what you intend, perhaps you should re-word them.

I realize firewire supports start/stop commands, but external firewire drives lack controls for it. I would also like to see onboard shuttle/review controls for going back to the monitor as well a LCD display for dropped frames, time/space remaining etc.

The QuickStream DV drive from MCE has an interesting approaches to some of these issues. However, a standard firewire portable enclosure won't have these features (redundant buffers, internal battery, LCD etc.).

However, I feel this field is wide open - if I were a hard disk engineer, I think the QuickStream could be improved.

Obin Olson
May 5th, 2004, 06:09 PM
can't you guys let Juan do the work and stop bombing him with this stuff? I don't even want to read the board anymore..drop it

Ben Syverson
May 5th, 2004, 06:25 PM
Obin's right -- I think there's only one person here still invested in this discussion, so maybe he can continue it with himself...

Stephen van Vuuren
May 5th, 2004, 06:51 PM
I think it's unfortunate that Ben chose personal attacks over healthy discussion of the issues.

I realize Juan is hard at work on getting this to work - I've been in this thread from the start. However, I still think the drive/recording issue is a vital issue to the success of this unit, especially since it should be able to work on other cameras and a reliable field recording setup will prevent it from being something that requires a bunch gear ro record with.

However, since the vocal opposition is to drop it, I will. I also will remove all the drive discussion from the thread between Ben and I if Juan wants to us to clean it up to make the thread easier to follow.

Ben Syverson
May 5th, 2004, 07:32 PM
Stephen, I didn't mean for any of my comments to seem like personal attacks; I was indeed trying to have a healthy discussion of the issues, however I didn't understand the context you were discussing SATA II in, and you didn't make that context clear until your last couple of messages. That was frustrating.

I (like a few others here) mistakenly thought we had all moved past the idea of a dedicated drive and tether, when clearly this is still a big issue for you. If I had understood that from the beginning, I would have politely ignored you. Instead, I thought you were arguing for a SATA II port on Juan's box, which is neither what you wanted nor a good idea.

I apologize that I became frustrated -- it's clear now that we weren't even arguing about the same thing...

- ben

Stephen van Vuuren
May 5th, 2004, 07:40 PM
Ben:

That's one problem with this thread - it's so long and has been going on for so many months it's hard to keep all the tangents up to speed.

The Agus35 suffers from the same issues. I would like to see some type of branching thread for these heavy topics here - I'll mention something to Chris as it would make it far easier for people coming into long-standing threads easier.

Anyway, no hard feelings and sorry for the confusion.

Ben Syverson
May 5th, 2004, 07:48 PM
No hard feelings here either, and my apologies.

Here's an idea: could we make this topic its own forum under the "Special Interest Areas" section?

Mark Grgurev
May 5th, 2004, 08:01 PM
Its probably impossible to do but I was just wondering. Would you be able to make a memory card reader to make custom gamma curves for the DVX100? If so, it would be great if you make one after ur done with this project.

Sorry for being a little off topic.

Juan P. Pertierra
May 5th, 2004, 09:21 PM
Stephen, Ben, and the rest <g>:

Regardless of the thread getting a little 'heated', i think just about every post contains useful information and good , well informed opinions, even if we feel passionate about our points. I wouldn't expect any of us not to. :)

To answer Stephen's question, yes, the start/stop can be handled over firewire, just like if the capture box circuitry where a PC itself. The circuitry in the box accesses the drive just like a PC and when the recording button is pushed, starts writing files to the drive.

However, i think there's a point we are overlooking here that eliminates SATA directly, and that is that right now the FW800 port on the device can also be connected to a computer directly, for recording on the machine's hard drive. This will be done through a device driver on the machine side, which will allow the camera to access the drive on the PC. This is simply not an option with SATA because it is simply not as flexible as firewire. I can write a device driver on the PC side to do just about anything, but if we go straight to SATA, all we can do is hook directly to hard drives.

SATA is definitely a better hard drive interface, because that's what it is designed to do..however FW800 is not primarily a hard drive interface, but rather a flexible interface that can be used for just about anything...since this app involves more than just writing to a drive, firewire is a good choice.

Let's hear it! :)

Juan

Rodger Marjama
May 5th, 2004, 09:54 PM
Originally posted by Stephen van Vuuren : Ben:

That's one problem with this thread - it's so long and has been going on for so many months it's hard to keep all the tangents up to speed.

The Agus35 suffers from the same issues. I would like to see some type of branching thread for these heavy topics here - I'll mention something to Chris as it would make it far easier for people coming into long-standing threads easier.

Anyway, no hard feelings and sorry for the confusion.

If you've got moderator privileges, just lock any threads that reach 500 replies and start a new thread.

For this thread it should be "4:4:4 12-bit Uncompressed DVX100 - Part II"

-Rodger

Stephen van Vuuren
May 5th, 2004, 09:59 PM
There's no official moderator here, so I've been holding off, though Chris had talked about me doing it here. I sent him an email earlier.

Rodger Marjama
May 5th, 2004, 10:07 PM
<<<-- Originally posted by Stephen van Vuuren : There's no official moderator here, so I've been holding off, though Chris had talked about me doing it here. I sent him an email earlier. -->>>

So I see...

Make sure to link to the original thread on the opening post if you guys do this. We have a few threads for our products on some different boards that went over 2000 replies if I remember right. It also helps indexing and search engines if you limit thread sizes. Setting an arbitrary post number seems to work well.

-Rodger

David Warrilow
May 5th, 2004, 11:12 PM
Hi,

fist I have to say thankyou to Juan for his brilliant virtuoso work on this project, which is not only very exciting but is also giving all of us a rare glimpse 'behind the curtain' on our camcorders. What we pay for is not always what we 'get' with these units...

As I understand it, the normal lattitude rating on prosumer camcorders is only a few stops (5-8?) with the higher end cameras pushing 8-11 stops (correct me if I'm wrong on the numbers here). But it's apparent that the latitude coming off the DVX100 chips is far greater than anything that we've been accustomed to in the past with our cameras. Does anyone know how to measure this difference in range? Even an educated estimation would be enlightening since it would give us a better indication of what our cameras are capable of, rather than what we're used to getting from them.

Again, great work Juan.

Best,

DW

Juan P. Pertierra
May 6th, 2004, 04:01 AM
One of the tests I am planning to do today or tomorrow, is to take outdoor and indoor snapshots of the same scene with my 35mm camera, and the DVX raw. This will give us a better idea of what the latitude is and i for one can't wait to play withe footage and see if I can get it anywhere close to the look of film.

I am going with ISO400 film because i read somewhere this is what most CCD's correspond to roughly...

I will have the film images scanned off from the negatives at 2K resolution and put on CD at the lab so i can post them...

Juan

Luis Caffesse
May 6th, 2004, 08:58 AM
Juan,

Most people seem to agree that the DVX100 is roughly the equivelant of 320ASA (when shooting at 24P with 0db and a 1/48 shutter).


http://www.dv.com/jive3/thread.jspa?threadID=300000694&start=0


http://www.dvxuser.com/cgi-bin/DVX/YaBB.cgi?board=news;action=display;num=1068605987


I did see one post on Dvinfo which claimed a 640ASA equivelance, but the majority of posts claimed 320. I think the 640ASA may be true when shooting at 60i with a 1/60th shutter speed, which is not the case here.


I realize you can't get 320ASA film for your still camera, but 400 should be close enough.

-Luis

John Cabrera
May 6th, 2004, 08:06 PM
Juan,

Did you ever figure out why the darker areas of the DV clip you uploaded are considerably brighter than the darker areas of your raw capture? The explanation about the distribution of 24bits across 8bit codec doesn't seem to explain why those areas would have to be brightened by the codec as well. Only why information in the brightest areas of the frame might be sacrificed. It would make more sense that panasonic brightens the footage at the same stage that color correction functions occur in the camera in order to help out overall with low lighting. I don't know... I may be way off... but if you captured a raw clip and then captued the same thing with a ND filter on enough to match the darks and midtones of your raw footage, we'd get a better idea of exactly how much information in that sky is actually being lost... please explain what I might be missing if you can.

John

Juan P. Pertierra
May 7th, 2004, 10:38 AM
John,

All DV/RAW comparisons where frames shot under the exact same conditions, so you can see what the DV output for the specific RAW data is.

I'm not sure about the darks either, but do note that the adjustment from 12-bits to 8-bits is not the only correction done by the camera. There are tons of other modifications done to the video which could be causing this...it could also be my settings on the camera which i haven't checked in a while since the joystick is disconnected.

It is possible, however, that since the color is not paletted, they moved the entire limited 8-bit range (which doesn't cover the entire latitude) to somewhere in the middle, sacrificing a little low end, a lot of the high end, but compressing the 8-bits in the brightnesses that they thought you would work under...this would give more color precision in that specific range, while sacrificing high end and low end latitude.

Just a theory...

Juan

Juan P. Pertierra
May 7th, 2004, 11:06 AM
Oh, and an update:

I started on the code work yesterday, but finally gave in to a couple of days without sleep <g>

However, i did snap pictures of the outdoor shot with my 35mm camera and the DVX at the same time...i got em developmed but even though i was using the on-camera spot meter, they came out a bit over exposed, and to all honesty the DVX captured a way better scene but is not a good measure.

I will try to do it again today or tomorrow, and try some slightly underexposed shots by the camera's spot meter. I do have a couple of indoor shots of my lamp which makes a good test of the range in brightness, so I am going to take some shots with the DVX of that as well, and see what it looks like...

Juan

Leif Thomas
May 7th, 2004, 11:48 AM
I'd like to post my try of the colorcorrected cap9_RAW:

http://www.filmerforum-koeln.de/user/leif/cap9_RAWcc.tif

the colors now seem more like the DV (although - of course - more natural) und I also lightend it up a bit...

I'd LOVE to see your 35mm / RAW / DV comparison! But why scanning the 35mm on 2K? A simple NTSC-Scan would be better to compare.

BTW:
Do you already have a name for your system? I think it's time :)

Nicholi Brossia
May 7th, 2004, 12:23 PM
Juan,
Would it be possible to write your code so that the hard drive records a flipped image, or even a way to toggle back and forth from normal to flipped modes?
Like many others on this board, I think your 4:4:4 system will coordinate perfectly with a 35mm adapter. Recording the image with correct orientation would helpful in the longrun. Although, if its too much of a hassle, flipping in post is pretty easy too.

Juan P. Pertierra
May 7th, 2004, 12:34 PM
Nicholi,

That's not a hassle at all, and in fact already implementing it...the function i wrote to deal with the inverted blue channel can invert images in any orientation, and thus you can save them inverted vertically if you'd like.

Luis Caffesse
May 7th, 2004, 12:40 PM
Just to make sure everyone is saying the same thing:

The 35mm adapters flip the image vertically AND horizontally, right?

so the image would have to be flipped not only vertically (like the blue channel you mention Juan) but horizontally as well.
(or rotated 180 degrees, same thing)

As was already mentioned, this would be simple enough to do in post, but it would be a nice addition if possible.

-luis

Nicholi Brossia
May 7th, 2004, 02:02 PM
Yes Luis, you are correct.
The image must be flipped both horizontally and vertically. Just for further reference, this is also referred to as inverting (flip vertically about the x-axis) and reverting (flip horizontally about the y-axis) or, like Luis said, rotated 180 degrees.

Juan,
Am I understanding correctly that the user will be able to switch between the normal and flipped modes? If so, this would be excellent for use with switching between 35mm adapter projects and other projects recorded with just the native camcorder.

Either way, Juan, you're doing excellent work.

Juan P. Pertierra
May 7th, 2004, 02:11 PM
Yep, that's correct, the user will be able to decide the orientation completely, that is there are check boxes for flipping horizontally and vertically, as well as rotation up to 270 degrees.

In other news, i know nothing about color correction so this is mostly for fun. It took a similar shot of the lamp and attempted to make it look as much as i could as the film output.

Now, the main problem I had was that since I do not have control over exposure because it is disconnected, all i have is the ND filters, and one of them was too bright and the other too dark. I started with the dark one and had to push it A LOT. I basically clipped a lot of the low end in the levels and it shows in how saturated part of the image is...still if i got this far with this dark an image, once i have the camera closed and i can vary the exposure, i can get adjust the light going into the camera to be in the correct range...

http://expert.cc.purdue.edu/~pertierr/sample1.tif
http://expert.cc.purdue.edu/~pertierr/sample2.tif

Juan

Juan P. Pertierra
May 7th, 2004, 05:36 PM
A noise free 4:4:4 10-bit uncompressed -> HD frame, with some of my own color correction...

http://expert.cc.purdue.edu/~pertierr/cap10_RAW.tif

Nicholi Brossia
May 7th, 2004, 08:27 PM
I don't mean to be annoying, but I've noticed a bit of chromatic abberration in cap10 RAW (http://expert.cc.purdue.edu/~pertierr/cap10_RAW.tif) and sample2 (http://expert.cc.purdue.edu/~pertierr/sample2.tif), but sample1 (http://expert.cc.purdue.edu/~pertierr/sample1.tif) has no chromatic abberration at all. It looks perfect.

Could this be due to your color corrections?

I'm sure your initial recording is perfect considering sample2 looks so great, but I figured this was worth mentioning.


EDIT: It just dawned on me that you are capturing the red, green, and blue channels seperately and then layering them in post. I'm guessing the "abberration" is probably being just a hair off on the alignment of one of the layers. This seems like a valid subject though, so I'll leave the whole post here.

Juan P. Pertierra
May 7th, 2004, 08:29 PM
what kind of chromatic aberration is it? if you're speaking of something present in the histogram, it wouldn't suprise me, because the frame was put through S-Spline pro for up-rezzing which could have some unexpected effects.

All I did on cap10 other than uprezzing was some level adjustment.

Nicholi Brossia
May 7th, 2004, 08:38 PM
I'll use sample2 as an example. I've opened the file up in Photoshop. Even at 100%, I notice a very thin green line around the base of the lampshade. If I zoom in to 200%, it shows about a 1 pixel "shift" of green to the bottom, and red to the top. After seeing that one part, its apparent throughout the rest of the image. I figured the RGB layers just aren't aligned right. Could this be correct?

As far as uprezzing, both cap10 (uprezzed) and sample2 show the same abberration effect. I guess whatever these two have in common, but different from sample1 will be the culprit.

Juan P. Pertierra
May 7th, 2004, 08:41 PM
Yup, that's alignment...try one of the other Photoshop PSD files that i have uploaded, and see what alignment you can come up with by moving the R,G,B layers...it's tricky! :)

Juan

Nicholi Brossia
May 7th, 2004, 08:48 PM
Yeah, that is tricky. Good thing you can program the computer to do all the precision detail work, because I know I couldn't :).

Isaac Brody
May 7th, 2004, 08:49 PM
Juan,

I noticed a few stray noise specks in Cap10_raw. I was adjusting the levels and they cropped up when I brightened the file. The specks are green and appear in the sky. Do you see them?

Juan P. Pertierra
May 7th, 2004, 08:50 PM
Yup! I haven't gotten the new cap yet, i've been working on finishing the software to put out a clip...

Juan