I'd like to propose the notion of Hitfilm offering Palacono a lifetime license to all future versions for his efforts as an unpaid intern at their company, if they haven't done so already.
I mean, really, he's certainly devoted more than the cost of an upgrade to the betterment of the program in just the span of a few days, let alone each year. (I'm sure others fall into this category as well.)
I say this only if I was the one running the company, not as someone trying to stir things up or cause resentment. I just personally like to keep valued assets happy and it makes good business sense.
#32 sounds similar to an item I reported in HF4 that was fixed. The problem only happened in projects at (29.97, 59.94). i.e. Non even multiple of milliseconds in certain framerates so one has to take care in quantizing a keyframe. Create always did. A drag of a single KF at the time did not. Looks like this is another function that needs to take care of that.
New Project. 29.97. A simple comp with a plane in 3D plane mode. I put a keyframe at the start and a keyframe at 1;10. This is keyframe is a normal keyframe and it editable to change it setting and the prev/next keyframe navigation works. Select this one keyframe. Move it left/right one frame and right back to 1;10. It is now a sub-frame keyframe. Which is not editable. If I try to edit it, Hitfilm will create a new keyframe.
If I drag this one keyframe across the timeline I can see various spots that Hitfilm will consider the keyframe a sub-frame keyframe if dropped at that location.
There are work arounds. Don't ever move a keyframe once created. If you do move it and it does become a sub-frame (dimmed), then simply double click the keyframe to get the playhead there and "select" it. Delete the keyframe and re-create it, and don't ever move it.
@NormanPCN Oh, I'm always (apparently) finding old bugs that have been already spotted, or reported ages ago (by me or others; I mentioned #32 specifics at #18, but I didn't do a movie) and are just working their way up the queueueue, but are you saying it's fixed since your report of how you found your version, or #32 is fixed in HFP2017,or both are fixed in HFP2017? I thought I'd just knock out some minor HF4 stuff while there is a chance for them to possibly be included in any last updates to it before it goes EOL, but I'm sure the 3-4(ish?) coders out of 20 staff, devoted to Hitfilm are up to their eyes in HFP2017 reports, so it's all cool. But I also have a few that are more involved, which might be new, but which take longer to document and I'm inherently fairly lazy and I was actually trying to put a project together along the way, so...laterz. Workaround and other examples is/are well noted, cheers.
"but are you saying it's fixed since your report of how you found your version, or #32 is fixed in HFP2017,or both are fixed in HFP2017? "
What I reported was quickly fixed in a subsequent update in HF4. I commented because it looks like your report is a different instance of the same/similar situation as my report. That issue being a mathematical milliseconds frame quantizing thing. Only 25 and 50 fps come out ideally.
New Bug/feature: #33 Parenting Polar Pothole -------------------------------------It's easier to make the simpler Bug/Doh! videos rather than the proxy ones I mentioned previously, so here's one messing about with trying to semi-duplicate @inScapeDigital 's guest tutorial using stuff that's available to Hitfilm 4 Express users. There are a couple of useful Particle Effects in Express there that you can mess about with if you don't have the full Particle system installed as an add on - Bonfire and Debris - so I thought Bonfire might make a reasonable ring of fire. BTW, you could also do the full Shield effect exactly as in the tutorial if you just kept the plane size to 1080x1080, as you can't make anything higher in HF4E: 1920x1080 is max size. Or you can pull in an flat image (.BMP. PNG etc.) that's bigger and use that if you wanted.But something went a little weird when parenting a simple Layer with Polar Warp Effect and a Bonfire to a 2D Point. I also tried various combinations (not shown) of making the Point and/or the Layer(s) into 3D Planes that just broke it in a different way. 3D unrolled didn't work because you can't apply Effects, such as Polar Warp, to layers.In the end, embedding the layers in a comp and then parenting that to the point worked - as seems to be the solution to many things - but... this seems weirder than just 'order of operations' when all you are doing is parenting to a point that hasn't even moved yet and: Blammo! So is this a Bug or a Misunderstanding?
@Palacono Pretty sure this one is misunderstanding but not necessarily order of operations and the solution as you already know, is an embedded comp.
Polar Warp is a pretty serious warp and ends up wrapping back on itself. When you try to rotate a layer like that weird things happen because you're not just rotating a fixed layer, you're also changing the input geometry to Polar Warp at the same time generating a new and completely different series of warps than what you started with. Sometimes it's a good thing like it's a great way to make a Text corkscrew effect. Sometimes, like you found out, it isn't.
EDIT: I guess it is actually order of operations after all because a rotation transform does change the input geometry of Polar Warp so you need to have Polar Warp set in stone prior to rotation.
@Aladdin4d By why does it only flip out when I parent a perfectly working layer to a New point? What's the logic/Order of Operations/it just does reason (if you were to make a guess )?
@Palacono Transforms happen before effects so the rotation transform happens first changing the X and Y values being fed to Polar Warp which then warps the layer.
EDIT: I get the same results regardless of rotating the layer directly or parenting to a new point.
@Aladdin4d we overlapped. OK, I experimented some more. Sometimes I get carried away with trying to document what I find before I forget how to do it that I don't look far enough around it to see what the culprit might be, after all the devs will do that if they're interested. But, it's the Bonfire Effect. It's possibly to do with the fact it's 3D but can be put on a 2D plane, but, if I turn off the Polar Warp and parent the Bonfire to the point, the Bonfire changes screen position (no earthly idea why, the point hasn't even moved from 0,0), which means the Warp then shows a different result when I reapply it. I thought it was because of what happens when you Parent something with X,Y and Z scales at different values (producing wonky planes etc.) but they're still all at 100%, but I have adjusted width and height parameters etc. to get a long thin flame, so there might be some internal scaling factors that go loopy. Dunno, one for the devs to fix or dismiss as not worth worrying about as there is a workaround.
@Palacono Not sure about anything with Bonfire because I hadn't made that far yet I started with arcane symbols.......
Probably should add the symbols are a text layer with Polar Warp applied using a random arcane looking font.
@Aladdin4d Looks nice. Polar warp is useful like that and you could have the rings pulsing in and out using keyframes with it or something. I haven't look at the original closely enough to see if that's not canon. Here's the Bonkers Bonfire.
New Whine: #34 HP4 .MP4 file Render Quality-------------------------------------Not a Bug, just an observation/whine/moan/complaint.Usually the MP4 Export from Hitfilm seems fine, but I just found that with a blurry image the banding is very, very visible and looks nothing like the nice smooth version in the Viewer while Editing. I'm not sure at what point it gets like that, as HF4E only works in 8 bits per channel, not a 16 bit Float, but even so it still looks nice and smooth, with no banding until Export. Not sure if using HF4P (or HFP2017) would make that Export better because a .PNG image sequence looks nice and smooth - which seems to imply 8 bits is just fine - the .JPG images are slightly less good (3/4 quality?), but much better than the MP4 frame grab. It would be nice to be able to set the compression value on that .JPG to perhaps get it closer, while still being smaller - GIMP suggests the quality setting is 85% - especially given the time export difference (See below).There was no difference at all in a frame grabbed from an .MP4 export from a 16Mbps, Main, 4.0 file to a 250Mbps, High, 5.1 version from Hitfilm.I took a short .PNG Image sequence and imported that into Sony Movie Studio 12 and 13 (both also 8 bit) where it still looked smooth and exported it as single pass Sony 25Mbps and MainConcept Two Pass 50Mbps .MP4 files and a Cineform AVI set to both Medium and Film Scan2 Quality. No obvious difference between either of the latter and they were the closest to (but not as good as) the .JPG files in quality and with OKish banding.Next were the two Sony .MP4 files, with the Two pass higher bitrate one being marginally better, with Hitfilm bringing up the rear.I'm currently exporting the whole 5 minute clip as an uncompressed .AVI to export from SMS as a Cineform .AVI file.Uncompressed .AVI from Hitfilm looks just like the .PNG sequence in quality.I did try to Export it as a.PNG sequence, but once it got started (initially sat there for 4 minutes without exporting a single frame, so cancelled and tried again) - it was going to take over 2 hours, instead of the usual 8 minutes it takes as an .MP4 file to an SSD, the little over 10 minutes a .JPG image sequence took and the just over 9 minutes the .AVI file took. No idea why a .PNG sequence would take over 12x as long as the others. It did take noticeably longer than the .JPGs even on the short (20 frames) test clip.tldr; MP4 export quality is very bandy on blurry things, nothing seems to make it much better (even really high bitrates) other than exporting as .PNG files (really slowly) or .JPG (much faster and about 3/4 the quality) or Uncompressed AVI files. Sony Movie Studio Exports .MP4 files at a higher quality/less banding than Hitfilm and Cineform (from SMS) is a little better than that.Order of Quality from Best to Worst is: .PNG/AVI,.JPG, Cineform (Any), Sony 2-Pass, Sony 1-Pass, Hitfilm and that's the order of the images below. The JPGs are grabbed using Media Player Classic at 99% Quality, so virtually BMPs/PNGs.http://i854.photobucket.com/albums/ab106/pickaname2/image12.pnghttp://i854.photobucket.com/albums/ab106/pickaname2/image12.jpghttp://i854.photobucket.com/albums/ab106/pickaname2/Cineform-Frame.jpghttp://i854.photobucket.com/albums/ab106/pickaname2/Sony-2-Pass.jpghttp://i854.photobucket.com/albums/ab106/pickaname2/Sony-1-Pass.jpghttp://i854.photobucket.com/albums/ab106/pickaname2/Hitfilm-Mp4-Frame.jpg
"No idea why a .PNG sequence would take over 12x as long as the others."
The PNG compression algorithm is compute intensive and slow. The Hitfilm backend for PNG output seems to be single threaded. One PNG at a time. Every time I've rendered PNG sequences there are at least two physical cores just sitting there waiting to to be used. Image sequences are easy. Separate files. No need to worry about output serialization just in case image N+1 finishes before ImageN.
But a .JPG image sequence is still fast?
"But a .JPG image sequence is still fast? "
Entirely possible depending on what's used for JPG's vs what's used for PNG's.
JPG image compression is not as intensive/slow as PNG. If you can pump out an image fast then sequential output works fine. Hitfilm cannot output PNGs very fast. Most times in Hitfilm there are CPU resources going unused so why not go overlapped/async in the image sequence encoding. It can really help PNG which is slow, EXR as well, and may even help JPG some. Even a simple thread "pool" of only two threads, A/B, could be a huge benefit. Not really a general pool but ultra simple to implement with significant potential benefits.
Of if one is doing crazy effects work where it takes Hitfilm 10+ seconds just to compute a single frame, then the slowness of PNG, or any file encoding, becomes less of an issue.
In which case it would be nice to be able to whack that .JPG compression percentage up a bit more to get almost the same quality as .PNG at 10+ times the export speed.
Hitfilm JPG always does a 4:2:0 color subsample so there is that loss. I tried JPEGsnoop and it estimates the JPEG quality matrix at about 75% chroma and 75% luma. There is wide interpretation about how to translate the matrix to a simple %.
I gotta believe that the JPEG code that FxHome are using (Mainconcept?) supports 4:2:2 and even 4:4:4 chroma. and of course a quality matrix setting. Maybe FxHome has to provide the matrix but it is easy enough to generate those or have a lookup table.
DSLR/digicam JPEG quality would be nice. About 2:1 compression from RGB. 97ish(?) quality matrix and 4:2:2. I looked that stuff up once upon a time. IMO, It certainly is a much better unchangeable single setting than what HF has right now. HF is not trying to generate small web JPEGs.
Even if FxHome did not want to provide user quality support, it probably should default to 4:2:2 and not 4:2:0. 4:2:0 is about max compression. Image sequences should not be about high compression.
For a trivial quality slider, the lowest end need not bother with super compression, IMO. For example, the bottom end could be what they currently output.
@NormanPCN I think the JPEG library is actually the Qt library. Check out C:\Program Files\FXhome\HitFilm (insert your version)\imageformats
Okay, and explains the lack of DPX.
Qt does have a simple JPEG quality scale setting. Not sure about chroma subsampling options for output.
@NormanPCN you sent me off to Google as I thought JPEG was always 8-bit/channel 4:2:0 but I see around 2008 4:2:2 was added and in 2012 12-bit/channel was added. I learned things today!
@Triem23 "...but I see around 2008 4:2:2 was added..."
Whatever you were reading is wrong in this regard. I personally have cameras from 2003 that generated 422 JPEGs. The Canon D30 dates a few years earlier and has 422 JPEGs. Digital cameras (DSLR, digicams) have traditionally always been 422 with JPEG. Excluding phone cameras. I think they have always wimped to 420.
I believe 420, 422 and 444 have always been supported in JPEG.
Some more experimentation: The uncompressed AVI file from Hitfim is huge, but lovely and smooth looking in the blurry bits, which are there to fill in the gaps of a video taken in portrait mode by someone who can barely operate an iPhone, let alone aim it at the subjects. Hitfilm's stabilisation worked to keep the subjects central, while the frame moves around it wildly. Not ideal, but better than the vomit-inducing original video. Which the subjects would probably prefer, considering it's of their....wedding. (don't ask )Anyway, exporting from Sony Movie Studio as Cineform AVI (High) looks lovely....as does...2 Pass Main Concept 50Mbps .MP4 and....even 2-Pass 16Mbps .MP4. Banding is occasionally visible in individual frames on the last one, but much less and with more consistent colours, and not all the time, or even every frame, so almost invisible when it's not paused; unlike the Hitfilm version which is there for long stretches. Then, to be closer to what Hitfilm does: also exported a single Pass 16Mbps version, which looked about the same as the 2-Pass version and streets ahead of Hitfilm's output at lower bitrates. (increasing Hitfilm to 250Mbps made no difference) Hitfilm is getting the colours all wrong, so cream is creeping into white and red into purple and the banding on even a black to white gradient section looks like ripples in a pond.Very disappointing, as previously (or maybe that was back in HF3 days...?) I thought the output from Hitfilm was crisper than Sony's on a few shots I'd looked at ages ago. Perhaps it works better on specific things, but I'm surprised people haven't seen the banding artifacts I've found on smoke and glares etc. Maybe everyone else's videos are moving too fast to see it, but when pointing at one thing for more than a few seconds: it's very distracting.
@Palacono This is a strange one because HitFilm uses Main Concept for H.264 encoding.
This is (more) confusing now than ever. Convert v3 shows that an .AVI file exported from Hitfilm has a 0-255 colour range, while the .MP4 files have a 16-235 range (including the one the .AVI file was exported from) and look like it in Convert - less contrast - although both look like 0-255 when viewed in Media Player Classic or VLC, so I'm guessing those are both stretching the 16-235 files up to full range on playback.I thought I'd see what Hitfilm's Histogram had to show. I saved out a snippet of an .MP4 file - that's already been saved once from Hitfilm - as an AVI and a high bitrate .MP4 file, then compared the snippets to it.Everything displays as Full range on the Histogram... I guess; there are no numbers shown. Hitfilm could be showing some as 0-255, then stretching out a 16-235 display to the same size for others. Would be nice to know what it was doing. The AVI file's Histogram is identical to the original .MP4 it was exported from, so that's nice, although Convert V3 still shows them as different. Another bug in Convert V3, I guess. The .MP4 version lost some colour. So I exported that and reloaded it a number of times. Each time it got progressively worse, although the differences each time were smaller. After the 5th export the difference between that and the original was very visible on the video itself. Less saturation and less red.I have no clear idea what is going on with Hitfilm's colour space conversion on Export or Import, other than it degrades over time and MP4 files are a sub-par unknown quantity. Anyone else want to make a guess as to what's happening?
@Aladdin4d "This is a strange one because HitFilm uses Main Concept for H.264 encoding. "But does it? In SMS you have a choice of the the Sony version, which only allows one pass and a maximum bitrate of ~25Mbps and the Main Concept one that allows two passes and a max bitrate of 240Mbps. Hitfilm only allows a single pass and a maximum of 300Mbps, so is it yet another version?
@Palacono Yeah it does
AVI file exported from Hitfilm has a 0-255 colour range
.MP4 files have a 16-235 range
although both look like 0-255 when viewed in Media Player Classic or VLC, so I'm guessing those are both stretching the 16-235 files up to full range on playback.
Everything displays as Full range on the Histogram... I guess; there are no numbers shown. Hitfilm could be showing some as 0-255, then stretching out a 16-235 display to the same size for others. Would be nice to know what it was doing.
The AVI file's Histogram is identical to the original .MP4 it was exported from, so that's nice, although Convert V3 still shows them as different. Another bug in Convert V3, I guess.
The .MP4 version lost some colour. So I exported that and reloaded it a number of times.
Anyone else want to make a guess as to what's happening?
So basically .MP4 sucks both to edit with and when exporting the result. I've tried various tools to convert MP4 into AVI but they all seem to mess with the colour in unpredictable and undesirable ways. Even GoPro Studio messes it up when creating a simple AVI file from its own footage. If I'm loading in 16-235 I don't want something to stretch it to 0-255 then recompress it back to 16-235, which is what Convert V3 does in all modes other than ProRes 4k. Except in update 3.4 (I downloaded it to see if the Scopes bug was fixed, or there was some interactive control over Stabilise... it hasn't and there isn't) that separate option has now been removed, so there is only the option to mess things up, or go back to the previous version. Fabulous.If Hitfilm Exported compressed AVI files it might be good both for converting/staying in 0-255 colour space (as the Histogram showed it remained identical after conversion from MP4 to AVI) and have it create more editor friendly files to work with as well. The uncompressed files are too fat to be fast.
"If Hitfilm Exported compressed AVI files"
Ahem......The Windows version of Pro 2017 exports to Cineform compressed AVI.
Hmmm... well I'm not upgrading just for that. Have they fixed Quad Warp yet?