Wolverine-Hawkeye Telecine

[Stan Jelavic]

Created the 3 exposure version of regular HDR. It also saves all images into a single directory.
https://github.com/vintagefilmography/HDR-3-EXP

[Bruce Davis]

Hi Stan. in the "Hawkeye Operating Guide for UX178 Camera" PDF instructions the "/bin/Release/" folder should be used to run HDR1.exe.

On Github HDR, HDR-3-EXP, HDR-UX178, HDR-UX178-ONE-DIR, HDR-UX178-3-EXP, (I think that's is all of them) instructions "/bin/Debug/" folder should be used to run HDR.exe.

I know the instructions on Github are quite old and this would be the reason, my question, is there any difference between the .exe files between /Debug and /Release at the present, which should be used for normal HDR, HDR-3-EXP.

As instructed in the guide, for my special UX178 version I use /Release.

Regards - Bruce

[Stan Jelavic]

We always use the release version Bruce. The debug version is there for debugging of the code and contains additional information necessary for debugging and therefor it is slower.
I will update the readme files.
Thanks for pointing this out.
Stan

[Bruce Davis]

Hi Stan, me again, have to bother you regarding the HDR1.exe program (using the 3 exposure but assume the 2 exposure would be the same), you added the possibility to set a frame start number, tried to set it at 3000 plus and found it only allows a number up to 100.
Thanks - Bruce

P.S. one other thing I have noticed, if a folder name is too long or a folder is below multiple/several levels, HDR1.exe will not save any files. This is not a big deal if not easily fixable, just thought I would mention it (might be a Microsoft problem).

[Stan Jelavic]

Hi Bruce,
The starting number was an easy fix. The max was set to 100 by default. Changed to 10 million.
Updated the github.
The other one might be a Microsoft glitch. Have seen that many times in the past.
Will have a look at it later.

[Bruce Davis]

Thank you Stan, when you are able (no hurry) would you be able to fix the "HDR-UX178-ONE-DIR" numbering limitation also.
Regards - Bruce
https://github.com/vintagefilmography/HDR-UX178-ONE-DIR

[Stan Jelavic]

OK fixed:
https://github.com/vintagefilmography/HDR-UX178-ONE-DIR
and
https://github.com/vintagefilmography/HDR-3-EXP

[Bill Putt]

Hey folks. I'm still trying to get my Hawkeye to be useable. The glare/flare/light noise what ever it's called is just far to aggressive to be useable yet. I did get the light gate 3d file from Stan and tried that, but still didn't really fix the issue. I had a thought about putting a potentiometer in to turn the LED brightness down, but that did not really help. I also tried putting pieces of bad film on the LED bed which works if I spend a CRAP ton of time putting it in exactly the right position. and then if i used that method for 8mm i would miss all the bits between the holes. so i'm left with a few options before giving up on this. either try to put a vastly fiddly and complicated adjustable gate system above the led so i can make very tiny movements of gates on both side to get it lined up to block all the light but not block the picture. or i can see if replacing the camera helps. I got a really good deal on my DFM 72BUC02-ML and i'm wondering if this is just how this camera works or if maybe it's broken. Has anyone tried both cameras and noticed a difference in glare between the 2? i'm wondering if going to a DFM 37UX226-ML would improve the issue. Really disappointed in this entire endeavor because of this. I had such high hopes.

[Stan Jelavic]

Sorry to hear that you are having problems Bill. According to my info you have a 16mm lens that I sent you with the BUC02 camera that you got from somewhere else. But don't worry I am sure we can fix your problem.
Lets start with some basic sanity checks.
Are you using 20mm spacers?
Resolution 2048x1536?
Going higher resolution could cause flaring.
Here is my test with the BUC02 and 16mm lens.

This is with the mask installed. You can see the mask is partially covering the sprocket hole. And there is no lens flare.
Can you also send me all of your camera settings and a sample image.

[Bruce Davis]

Hi Stan, just sharing my findings, after spending some time testing HDR "3 stop" "3 exposure", have not tried 64 bit, saving the 3 exposures to tiff I find problematic, every now and then frames are dropped or not recorded to SSD, not sure if its caused by USB3 not being fast enough or computer?

Two exposure recording in tiff is fine no dropped frames, three exposure recording in JPG is also fine no dropped frames.

An onscreen comparison between tiff and jpg images does not reveal any noticeable difference, although there may be internal image differences. This may also be due to the limited colour spectrum of my S8 film .

I know we strive for the best possible result, but do you feel that for this application it is really worth bothering with tiff files?

Can the quality of the jpg files be adjusted in the HDR application as is possible in photoshop when exporting, obviously not looking for as many variable options as in photoshop, just curious.

Regards - Bruce

[Stan Jelavic]

Hi Bruce,
Yes this looks like the bandwidth bottleneck somewhere. It also could be the camera itself. If you still want to go with tiff images then the scan has to be slowed down.
The jpeg quality can be adjusted.
CurrentBuffer.SaveAsJpeg(imFullpath_lo, 100)

Currently set to 100%.

I also have not seen any noticeable difference between jpeg and tiff but still use the tiff format since it is available and I do not have that much of footage to worry about the scan speed.

[Bruce Davis]

Thanks Stan, had a look on the TIS website but could not find an answer, do you know where the actual final image is processed before saving to hard drive. For example if saved as JPG or TIFF is that image/frame created on the 37UX178 camera board before transmitting to the computer via usb3 or does the software on the computer handle the processing.
Regards - Bruce

[Stan Jelavic]

Hi Bruce, the images are created on the camera and sent via USB to the computer. The computer then saves the image.
WE can determine the cause of dropped frames by implementing the following dropped frame calls.
https://www.theimagingsource.com/sup...mationData.htm

That would tell you if it is a USB bandwidth issue or computer processing issue.
I will do the test code for you some time this week.

[Bruce Davis]

Thank you Stan, would appreciate being able to determine where the bottle neck is, please do not rush, whenever it is convenient for you, sorry to burden you with this.
Regards - Bruce

[Stan Jelavic]

NP Bruce. Probably towards the end of week. Regards.