Jump to content

Dan Hudgins

  • Content Count

  • Joined

  • Last visited

About Dan Hudgins

  • Rank

Profile Information

  • Gender
    Not Telling
  • Location
    San Francisco, CA USA

Contact Methods

  • Website URL
  1. I think you will find that the price for the KineMAG are not out of line with their quality factor. In general you may find that you will need a drive rated about 5x (or more?) the data rate being recorded, in Flash media their record rate is uneven because of a delay while the chips bank switch, although the camera has a buffer the drive needs to be fast enough to write faster than the average rate because the delay for bank switching of the flash chips in the drive causes the buffer to fill, so, the average write speed is not telling you much from the specs, it needs to be the worst case write speed probably. KineMAG use (so I was told) high quality FLASH chips that don't slow down much with repeated read-write cycles, other drives may work when new but slow down with use and eventually not work as well, and its no savings to have the shooting cut-out in the middle of an important shot because you tried to save a few bucks, that in the end will cost you more in lost time or even an irreplaceable once in a life time shot. In the S35 model you can dump to any speed SSD or HDD in the second drive slot, and re-use the KineMAG to save some money on the higher priced KineMAG s. I've suggested to them to add dump to USB port support in the Mini, like the way the S8p and S35 work with their dual SATA slots, so people can empty the KineMAG in the field using a USB to SATA adapter, or just dumping to a USB thumb drive, not everyone's cup of tea, but useful where you don't have a laptop along to dump the KineMAG for re-use while shooting in the field. As for the 96fps and 100fps modes, you can look at the reviews of the camera to see what maximum record time other users are getting with the KineMAG . The maximum record time on high speed modes may not be due to the SSD speed, but rather the SATA port speed itself, or other internal bottlenecks in the data path, you can contact Kinefinity.com and ask them what maximum record time they have achieved so far, and which model of KineMAG that was achieved with to compare to the results you are getting with some other brand of SSD. On the subject of clipped highlights, I forgot to mention that de-Bayer programs based on Adobe SDK or DCRAW etc. may clip all three color channels noticeably for shots made with low average exposure because of their internal AGC effects. Such programs may clip the top 5% of pixels (etc.), but those ARE the highlight detail that people pay more for in getting a camera with good dynamic range, so its nuts to use programs that clip of the upper pixels that are withing the ADC range on the sensor. My de-Bayer program can be setup not to clip anything, or to just clip the chroma and not the luma. You may be able to use the free program DNG_valadate.exe from Adobe , its in their DNG development zip file, to produce a gamma 1.0 conversion of DNG to TIF to check if your normal processing workflow is clipping anything in the highlights, if that does not work my de-Bayer program is also free and can also make a gamma 1.0 conversion from DNG to TIF using the engineering processing methods for checking those sorts of losses etc. In this case, programs like XNVIEW should probably not be used to check for losses of highlight detail as such programs may be clipping the upper highlights off and not give results that are representative of the upper limits of the recorded data in all three color channels. Please keep in mind that a raw recording camera is unlike a camera that records balanced RGB data in that the results you see are NOT what the camera recorded, but are dependent on how you convert the raw recorded data INTO balanced RGB files, and also the clip limits and gamut of the monitor or projector you are using for viewing the balanced RGB files your workflow produced from the raw recordings. In many cases what is being compared is not the cameras intrinsic qualities, but the way the various workflows interpreted th raw recordings, so very different results may be obtained using the SAME camera and different workflows (and or monitors and projectors) and de-Bayer and LUT settings within the same workflow.
  2. Quote: [Dan, i can only ask you for better turning of highlights handling. i saw cineform samples from s 35 model (asian woman in the forest against the sun) and they handle highlights in more delicate way, because uses protune cineform curve i believe.] There are some issues that people seem not to understand about how the monitoring to end result matching works in the KineRAW cameras. 1) You cannot apply grading directly to the Cineform recordings because there is no matrix applied to the raw Bayer data (you cannot cross mask spatially separated colors). If the 3D-LUT the camera makes are not applied, then the relative saturation of the red, green and blue will be wrong when you use a simple saturation increase in grading. This seems to be the source of many of the complaints people have, but in fact its their NOT matching the camera monitoring that is upsetting the color balance of relative saturation of various colors. 2) Most people using the DNG frames seem not to be using the 3D-LUT the camera makes for matching the raw data to the monitoring so the results do not match anything you saw in the camera, and since no matching matrix was applied you get the same problems as in case #1, but this time you are grading from unbalanced red, green, and blue saturation taken from linear 12bit sensor data. 3) In the case #1 the data is "LOG90" encoded Cineform data giving equal weight to each stop in the brightness range, that is a wrong starting point to look at on a Rec.709 or monitor gamma monitor, you get way too much code range in the shadows making the results show too much grain and leading to heavy under-exposure (not to mention no matrix having been applied so the colors are skewed.) 4) If you process the DNG frames without using the 3D-LUT that converts the linear sensor data to "LOG90" data then apply the second 3D-LUT that converts the LOG90 data (same as for Cineform recordings) your results will not match anything having to do with the in camera monitoring, how could it, there is not DNG header meta-data that can exactly match the in camera curves, that is why the camera generates 3D-LUT, and so your workflow needs to be set-up to ignore the XYZ to RGB DNG tag and only interpolate to linear Gamma 1.0 greenish results, those then pass through the two mating 3D-LUT (the linear to log one is constant, the monitoring curve one mates with only the shot in the shot folder it was taken from). 5) You are NOT working with a RGB recording, the DNG data is the SAME no matter what monitoring table is used, other than the exposure and analog gain applied to the sensor preamps that feed the ADC, after the ADC the signals are just recorded for the most part and no changes to the camera settings have ANY impact on the results, other than the making of the 3D-LUT that are put into each shot's folder. If you do not use those 3D-LUT, you are on your own and your results will be the same no matter which look group you use, Kine709, KineCOLOR, or KineLOG have no impact on the recorded data (other than their shortcuts that have the ISO setting force analog gain when you are NOT using the so called "expert" mode.) 6) Operation of the camera would be more understandable if they had buttons labeled: ANALOG GAIN, EI/ISO CURVE, K/LIGHT_TYPE in place of making the controls clear, they have combined those functions to "simplify" the camera for the Asian market, you have to request the "expert" mode, then on the S35 you need to use the ISO and F2 buttons to set the analog gain and EI/ISO curve independently, I have not use the Mini yet to see how they implemented it there, but you need to understand what is going on to figure out how the menus impact the 3D-LUT made vs. the burned in aspects impacting the recorded data. Their setting the analog gain above 1x for green does tend to make the highlight range shorter, it depends on where they make the origin point so that the EI/ISO number reads right for 18% gray cards, if you scale from black bias point or from code value 0 etc. 7) The curves I made do not clip anything, not the red, green, or blue channels because the three channels are balanced by using the analog gain. The only way to prevent clipping as shown in the cameras 90% zebras on the raw data is to reduce the exposure or use a Cir.Pola filter to cut reflections by a stop. No gains can be had by changing the curves, KineCOLOR is soft enough for normal uses if you set the exposure right and use EI/ISO 1280! without additional analog gain. 8) The amount of highlight range when analog gain for green is set to 1x depends on the EI/ISO curve used, the maximum highlight range is when you see 2560! displayed, higher speeds are not useful for 12bit data because there would not be enough data above the FPN and under 18% gray code value. At speed 1280! the full Cineon range is filled so you get the same range about as a 35mm film scan, at 2560! I added a small shoulder curve so that NO data would be clipped. At speeds under 1280! the sensor does not have enough highlight range to fill the "super white" Cineon data range above code value 685/1023 in DPX LOG files, you cannot compensate for that lack of highlight detail aside from controlling the contrast range of what you are pointing the camera at by using fill lighting to light the shadows so you can reduce the overall exposure to keep the highlights needed under sensor clip. 9) The KineCOLOR currently defaults to having the 3D-LUT output full range data, you cannot ingest those results into a Rec709 or maybe DCI P3 workflow without clipping both the highlights and shadows. In addition the internal signals in the camera's monitoring are full range, only the output range settings reduce that for having the 3D-LUT output sub-range ITU601 limits for Rec.709 use etc. If you shoot using KineCOLOR you can change the output range limits to ITU601 "HD limits" to avoid this issue which will then make the output of the 3D-LUT limited like the default state of Kine709 and so be able to ingest the output of the 3D-LUT (RGB) into Rec.709 workflows (if your DCI P3 workflow is also ITU601 limited, keep that in mind as well, that is do you expect the DPX frames to have a range of 64/1023 to 940/1023, because KineCOLOR has a range of 0/1023 to 1023/1023 by default with 18% midtone around 470/1023.) 10) Its not possable to have "softer" highlights other than what is there because the current looks do not clip the highlight data, you get everything the sensor puts out. If the highlights are clipped in the DNG data its the result of not using the 90% raw zebras when shooting. 11) I could lower the 90% white card point so that its closer to 470/1023 signal level in KineCOLOR, I suggested having a softer look group by Jihua did not want that as he thought too many choices would be confusing to people, the camera supports about 36 look groups, and only three are being used, so there should be room for more. You cannot however get 90% white TOO close to 18% gray in the EI/ISO curve because that puts a kink in the curve that does not look good on skin tones were light is modeling the highlights and shadows, its better to have a smooth a curve as possible and to adjust the exposure and lighting when shooting to have the light or dark side of the face aligned with the 18% gray reference tick mark on the histogram display (you see a gray and white vertical line on the histogram, those are the calibrated code levels for the ADC output when you have the exposure set right and are shooting a 18% gray and 90% white card, faces should have their peak between those lines, you do set the viewfinder zoom to 800% and point the camera at the actors face to use the camera as a spot meter to adjust the shutter and iris to get the face exposure in the correct range, if things are too much under 18% gray tick mark you will end up with dark shots showing heavy noise, EVEN THOUGH THEY DO NOT LOOK DARK when you display the Cineform LOG90 without the corresponding 3D-LUT because the "raw" Cineform recordings are NOT meant to be graded from directly as they lack the correct color matrix and have the shadows expanded way too much leading to chronic underexposure and excess grain noise as well as FPN showing up later when people grade the shots several stops above the rated EI/ISO at the time of shooting. I can't add highlight detail that is not within the sensor's range, the current curves don't clip anything, if there are clipping problems its probably from not mating the workflow to the output range of the 3D-LUT or the exposure was wrong or they have fiddled with something I don't know about. You also need to set the monitoring path monitor range limits to 16/255 and 235/255 probably, or the camera's LCD monitor may show clipping IN THE MONITOR because HD monitors are NOT full range, I don't know how the implemented the HDMI interface but it should already be applying ITU601 limits, not that all LCD monitors can display that range anyway... Additionally Kinefinity.com (sm) changed the camera's design AFTER I calibrated the look groups invalidating the color matrix settings and everything else. Their engineer Cheng seems to have fiddled with the analog settings by adding a translation table to try to match the previous white balance, but as far as I know they have not compensated for the saturation difference in the Bayer filter dyes between the 1st generation sensor I was using, and the current production sensor (or changes to the IR glass in the OLPF filter etc.). I will have to talk to Cheng to get him to remove the translation table so I can re-calibrate everything back to the native sensor output, hopefully he can do that, so people using the new revised look groups will probably need to upgrade the camera firmware to clear vestiges of the current issues. If Cheng is scaling the 12bit data to correct the white balance, I would hope not, that could introduce histogram gaps and clipped color channels, something not going on in the prototype S35 I used for doing the calibrations, hopefully I can get some straight answers if they really want me to untangle the current issues and get the Mini's working as intended...
  3. The KineRAW cameras take standard SATA 2.5" drives, the S35's second slot can hold a notebook hard drive, like 500GB or 1TB, that you can dump the SSD to when it get full to re-use it in the field. The main issue is that the SSD be fast enough to record all the modes to, the KineMAG are qualified not to drop frames when recording, if you use other brands of disks then they may not work all the time or may get slower with use, the KineMAG are high quality drives that have been tested through repeated record and erase cycles. I have been using their prototype 60GB drive for more than a year and as far as I know it has not dropped any frames yet even recording [email protected] in their S8 prototype and shooting 220fps in their S8 prototype, as well as shooting both Cineform and DNG [email protected] at the same time in the S35 model. But you might find some other brands of SSD that work, they kept in mind that as time goes on other brands that are fast enough will fall in price and so there will be more options, but for now, if you want them to assure you that the camera will record without glitches their disks are provided as tested and known to work right.
  4. I got an email from Jihua yesterday and he says they have a Mini ready to send me now to re-calibrate the color balance with, I originally calibrated the color using the S35 prototype #3 and then they made some changes to the sensor and or OLPF that invalidated the color calibrations. Hopefully I will be able to re-calibrate the look groups to resolve complaints about the color balance. Anyone who has purchased a S35 or Mini should send me sample frames as TIF or BMP files showing what they find unplesant in the color balance so I can see what kind of lighting was used, please tell me the workflow you used to get from DNG to TIF or BMP so I can know what part of the camera was involved as the conversion to Cineform or conversion from DNG in various workflows can give different looking results because of peculiarities unique to each program that is involved with each workflow option. My email is: tempnulbox (at) yahoo (dot) com My in box can only accept about 25MB so you need to send each sample image frame TIF or BMP in a separate email. I may ask you what settings you had the camera using, such as K and Light type, output range override, monitor limits, look group, and analog gain override. You should note that only the analog gain settings get burned into the recorded data, aside from that the RAW data recorded in the DNG files reflects the sensor ADC output for the most part. Where the color problems come from is the program converting the recorded RAW data to match the monitoring LUT to get results that look like what you saw on the camera's monitor when you were shooting. There are 3D-LUT made to go with the Cineform and be used by the Cineform codec, if you don't load those right you will not get matching results. The DNG workflow is more complex as there is a way to use the 3D-LUT the camera generates for each shot, but only some workflows support that, otherwise the DNG header matrix values are used and those may cause off color results depending on the program that is converting the DNG files. In my free de-Bayer program I ignore all the DNG header values and use files derived from the camera's monitoring tables, but that only works when the camera is fully calibrated something that was upset when they revised the camera, in that case my software allows for ignoring all meta-data and calibrations and re-calibrating each shot from the recorded RAW data, so any color issues don't need to be an issue if the workflow used can allow overriding everything and being manually calibrated to the recorded RAW data (in that case the camera settings don't matter much as well). Hopefully after re-calibration the color issues will be less noticeable, but in order for people to be happy with the results you should contact me directly so I can send you some experimental LK5 and LT5 files to check out an comment on, maybe, so I get some feedback, having you complain to Jihua and him to relay such vague complaints back to me does not help me understand the exact signal processing path you used to get messed up looking results and since there are many possible workflows, each person's workflow will give different issues to deal with, so I need to know exactly what happened to try to reverse compensate to avoid it in future shots. People should understand that the look of the camera's monitoring is OPEN, anyone can use my free programs to control the internal workings of the KineRAW cameras, they read two files called *.LK5 and EQUAL.LT5, those make internal adjustments to the camera's sensor and monitoring path and 3D-LUT generation when you set the K and ISO menus along with the analog gain override (as well as EI ISO curve in "expert" mode being active). Those settings for gain and curve as well as matrix and saturation are all user programmable, although it takes some skill and knowledge to program the camera's internals correctly to get usable results. The camera can shoot at native sensor balance, but the way the current three look groups work is to set the analog gain in the sensor's preamps to get neutral white balanced data, that has the advantage of giving a full 12 bits usable for all three colors, unlike cameras that record unbalanced data then clip one or two bits off the red and or blue to get white balance giving maybe only 10 to 11 bits of used data for the red and or blue, with the equal RGB signals in the KineRAW cameras you get 12bits all the time when the camera settings match the light on the subject. That way of operating can result in fewer histogram gaps and smoother image tones. So my points are: 1) The camera setup LUT are open and can be generated by anyone and installed into the camera to influence the monitoring and results. 2) You do not need to depend on Kinefinity.com (sm) to provide you with more camera "looks" you can make your own if you have the skills required. 3) You can share any LK5 or LT5 files you make with other KineRAW camera owners or users, as far as I know the S35 and Mini firmware both support the same LK5 and LT5 files so ones made with one camera will work the same in the other camera. 4) If they do send me a Mini I can try to make some extra look groups in addition to revised Kine709, KineCOLOR, and KineLOG so that you have more choices. You should tell me what changes you are interested in. 5) Various workflows may not match the camera's monitoring and show clipped or off color results in spite of the data actually being recorded, there is no way to prevent users from messing up the conversion of DNG to RGB as that is outside the control of the camera or the camera's maker or myself.
  5. There are many factors that impact the end results when shooting a film, and important things to concider are the ergonomics of use and getting shots in focus fast enough during real shooting.  How the cameras focus aids work and their ease of use is an important point and one that overrides any price difference within what is afordable.   The aliasing issues with the 5D3 are serious enough from what I have seen processing test frames, it it varies with f/ stop used, that I would not concider the 5D3 usable, as with the BM 2.5K camera, and maybe Digital Bolex, without a suplementry OLPF filter.   The KineRAW (tm) cameras' sub-PL mount lets you use lower cost S35 and A35 real cinema menses designed for non-reflex 35mm film cameras, something that is not really an option on the 5D3 because of the mount placement and reflex mirror.   Price is less important than if the camera is usable for the kind of filmmaking you want to do and if the camera gets in the way of you expressing yourself.   Chroma moire is better delt with by having a good OLPF filter in the camera to start with, that way you don't get a supprize later when the anti-OLPF sharpen is applied because you were in focus at prime f/ stop and using good lenses that focus sharp to start with.  When all is done, the cost of the camera is a tiny part of a films production budget.  And its false econimy to cut corners that will impact the end results that make your reputation by having aliasing and moire in your footage.   You cannot compare cameras shooting CinemaDNG and say this or that was the result of the camera, other than making linear TIF with a program like DNG_validate.exe since the anti-OLPF sharpen and de-noise neeed for each camera's footage needs to be optimized to the camera settings at the time of shooting, the f/ stop and lens focus quality and many other factors.
  6. One additional point that I can see as a real issue is focus aids, the KineRAW (tm) have 800% zoom that makes for sure focus, in addition to 100% and 200% as well as full view, without those features being fast and easy to use with region of interest, and being able to increase the monitoring contrast without impacting the recording, it can be hard to be sure of your focus, so check out the focus aids and how easy they are to use on other cameras.   For my own projects I want these things:   1) A good OLPF so there is control of aliasing and chroma moire   2) Focus aids that are useful for being sure of focus   3) Being able to use mount adapters for real cinema glass in the various mounts we have from our 35mm cameras   4) True RAW DNG that are uncompressed that fit into my free de-Bayer program that gives full manual control over the color balance   In addition to that the KineRAW (tm) cameras have an open monitoring LUT system you can develop your own looks for to use in the camera and those files are user loadable and will show up in the cameras menus, you do not need to depent on anyelses idea of how your footage should look.  The LK5 controls the EI ISO curves and can work with native sensor balance, useing optical filters like a CC50M, or full analog gain for white balance.  The LT5 file currently works as EQUAL.LT5 but they could revise it to work for unbalanced LK5 as well, you can edit the EQUAL.LT5 in any text editor to get any ratio of red, green and blue analog gain, normally though you calibrate the K and light type to equal ADC CV for a netural subject, you give those values a label, and then load it onto a USB thumb drive, put that into the camera it says "nnn user files loaded!" then you take the USB drive out and re-boot the camera, at that point your custom white balance and or additional LK5 look groups show up in the camera's menus just like the factory presets.  Why complain about not liking the way the highlight rolloff is setup, just add your own curves at will...
  7. With regard to the media costs, it may be possable in the Mini to have the SSD dump to the USB port, its a Linux computer in the camera as far as I know, so its just a change in file path maybe, I have suggested that to them.  In the larger S35 you can insert a notebook SSD into the second slot to dump or back-up the SSD for re-use.  That way you don't need to pack around a notebook computer to empty the SSD and shoot more.  You can use any compatable SSD you like, its just a matter of it being fast enough no to drop frames as I understand things, the KineMAG (tm) are qualified to work.  With the 60GB ones I have been testing, I did the first testing with their prototypes, in both the KineRAW-S35 (tm) and higher bandwidth KineRAW-S8p (tm) I have not noticed any dropped frames shooting for over a year now.   Its even possable to shoot to an HDD if the shots are short, when the buffer over-runs the camera breaks out of the shot.  I use a 500GB HDD that I keep with me so that when the SSDs fill up, I can dump in them the camera  and shoot some more.
  8. All Kinefinity.com (sm) needs to do to stay in for the long run is to price their products above actual costs and sell enough to make it worth the bother, they are a division of a successful telescope camera company, so they parent company should stay around as far as I know. They have good prospects for the Asian market, as well as for people that like their image quality.  As far as I can tell they are positive on developing new and aditional products and do not relay on large volume orders.  BM seems to need volume orders to meet its price tragets from my impression.  From what I have seen on the internet BM is spending money on advertising, wereas Kinefinity.com (sm) is not, so in the end, who's bottom line will look better?  Better to not through volumes money out if you can get a smaller but steady flow in?
  9. It should be, in tests with the KineRAW-S35 (tm) I found speeds up to 5120 (1280! x4 gain) to be usable after de-noise on shots were the camera is static, people at NAB liked the results show at the KineRAW (tm) booth.  Its possable maybe to use speeds up to 20480 with heavy de-noise or if you are going to DCP where noise can be higher than BluRay, but speeds above that would probably best be limited to SD or DVD.  The maximum speed is (2560! x64 = 163840) but that is best limited to documentery or SD news.  For normal shooting 1280 works well with fast lenses, you can pull up the shadows if needed in grading to get higher effective speeds.  Using 2560! x1 gives the most highlight range for high contrast subjects, about 5 stops above 90% white subject.
  10. S35 depends on if you look at projection apture which is what you see on the screen or camera apture which you never saw on the screen.
  11. How much jell-o does BM Pocket have?  I asked if they would support 2048x858 in the BM Pocket and they ignored me, its not a 2.39:1 cinema camera even though that is less bandwidth than 1920x1080, so where is the Cinema Part?  At least Digital Bolex and KineRAW (tm) support 2048x1080...
  12. I added support for the 5D3 and Magic Lantern RAW DNG conversion and have looked at test frames shot in the Canon.  I have also added support for the BlackMagic 2.5K and have seen their data.  Processing all three cameras in my free de-Bayer program I can see the impact of the OLPF or lack there of on all three cameras results, and I would prefer the KineRAW (tm)'s results for my own projects based on what I have seen myself so far.  If Canon would improve their OLPF for use in movie mode or Magic Lantern would support un-binned modes in the Canon sensor, then its OLPF might work better, but I would prefer not to have serious aliasing and moire problems you cannot remove chroma moire using software in any way that ends up beter than having a working OLPF to start with.  The lack of a good OLPF in BlackMagic's 2.5K camera is a serious issue for me, I would need to add one for my own use, but the extra glass thickness adds problems with wide stops so its beter to get a camera engineered to work right to start with, maybe.  You should not pass judgment based on things you see converted to H.264 on the internet, rather you sould rent each camera and do your own testing under the conditions you will be shooting under with the lenses you intend to use to see which camera's ergonomics and aliasing, moire and noise in the DNG RAW data levels works for you, as there are tradeoffs with Bayer type cameras and the results or DNG processing will vary widely depending on if the Adobe SDK is used or not or if you convert to Cineform (tm) or use another processing option.
  13. How you process the DNG will impact the results, as does the exposure, lens, f/ stop and de-noise applied...
  14. You should do careful testing of the 5D3 when anti-OLPF sharpen is applied for aliasing and moire when good sharp lenses are at prime stol and accurately focused.  Likewise with the BlackMagic 2.5K camera and its lack of an OLPF filter.  The OLPF filter in the KineRAW-S35 (tm) prototype I tested seems to give the needed results using real cinema 35mm lenses in the 2048x1080 mode for cinematography.    Its not just a matter of price of the camera, if you are making a movie you want the MOVIE to have some value, so the tools you use impact the look and feel of the end result, and how well you can do the cinematography, if you have a KineRAW (tm) its similar to using a movie camera so does not maybe get in the way of your working like you would with a film movie camera, and the OLPF is designed for cinemitography with sharp cinema lenses, so you want to avoid being penny wise and pound foolish in selecting a camera based on cost, you are making a movie and will have much larger costs involved so you want to get the images that will help you make the time and money well spent overall...
  15.   You cannot judge the camera's RAW exposure from graded images on a monitor because the monitor may not comform to ITU601 limits or the images may not have been processed to retain the cameras output range within the monitors limits, in particular if you are viewing on an LCD or HD monitor.  The data values can be measured direct from a linear TIF made from the DNG to see if anything was clipped in the camera's exposure, then its just a matter of processing and grading the DNG's data to retain what was in the recordings to see it on the screen.   The camera makes 3D-LUT for monitor matching that relate to the look selected, but there is an output range selection of the look group selected.  The camera is supplied with KineLOG which gives Cineon (tm) standard film log output, in that case super white data above 90% white subject would be over code value 685/1023 so unless you grade that back down to be in the visable range you would not see the highlights captured by the camera, that is normal for all DPX type film log files that have not had softclip applied.  KineCOLOR defaults to full range output so cannot be loaded into Rec.709 workflows or shown on an ITU601 limited monitor without having range reduction applied, that can be done with the range limits override menu to select one of the HD/ITU601 limits options (with midtone at 46% or 40.7%).  Kine709 sets range limits for the 3D-LUT to default to ITU601 by default, but if you do not use the 3D-LUT made by the camera as part of the grading, or you use DNG processing software that has AGC, the software you are using may clip the recorded data and cause loss of lightlights.   These are serious issues, and using some software my degrade the results possable because of the way the software clips the data that the camera records, or does not prep the data ranges for the monitor or projector used.   You can email me if you want to have me check your DNG to see if they were overexposed, of you can use DNG_validate.exe and IRFANVIEW (tm) to read the highlights and see if they come out over 90%.  If you did not see zebras when shooting and you had them set to 90% raw levels, then the highlights were probably recorded where there were no zebras.  You can also set the waveform monitor to raw levels rather than post to see what the sensor ADC CV were at the time of shooting (the waveform monitor can work during playback in the camera).
  • Create New...