Support forum for DG Tools

Thanks for the info, sparktank!

I've been so used to dealing with just AVC progressive streams, that going back to SD content on DVD (MPEG), I find myself brushing up on things I haven't needed to look up for some time.

Would it, by chance, be too much to ask for a cheatsheet for the info in the *.dgi Files?
The info the DGI files is more relevant than screenshotting the live index with DGdecNV.

Just minor things, like what the colormetry of 2 2 2 means in the file.
Probably just the common and expected (legal) formats allowed.

I keep text files of these, but mainly just for AVC as I tend to neglect anything that doesn't use AVC.

And when I upgrade my card to index HEVC, there'll be more cheatsheets for that as well.

I really can't remember where I keep the free documents on the format specifications.
I should be keeping shortcuts on the desktop in a folder, but I like my desktop super clean.

DGI file formats and semantics are described in the DGIndexNV user manual. Is there something missing?

I'd like a faster way to use video crop, such as it was before the last slipstream.

Could you please make DGIndexNV cropping to interact with template.avs and output the wanted values in DGSource()?

Please

Seems to me you should have brought this up while we were deciding what to do. You're basically asking me to just revert the changes we made.

admin wrote: ↑

Fri Dec 14, 2018 8:35 am

Seems to me you should have brought this up while we were deciding what to do. You're basically asking me to just revert the changes we made.

Sorry, I miss the board for a while and noticed the change when done.

I am not asking to change DGI again with CLIP line.

I am just asking to permit template.avs to receive parameters for ct, cb, cl, cr from DGIndexNV.

Thus doing, nothing would change if nothing is added in template.avs.

It's just a fast and easy way to have a ready AVS script to feed a x264 encoding.

OK, that seems reasonable. I'll see what I can do. We'll need to have __ct__ and similar variables in the template, etc. We can debate whether it should be available via CLI.

admin wrote: ↑

Fri Dec 14, 2018 11:01 am

OK, that seems reasonable. I'll see what I can do. We'll need to have __ct__ and similar variables in the template, etc.

Thanks. That would make life easier when not using a encoding GUI.

admin wrote: ↑

Fri Dec 14, 2018 11:01 am

We can debate whether it should be available via CLI.

IMHO it's a bit hard to clip a video without a GUI, unless you decide to sample some random frames and crop the best case of each of the four sides. Let's think about some IMAX BD, with 2.35 AR on some parts of the movie and then a 1.9 one in others.

Well, now that I am thinking, it could be nice to have an automatic sampling in the GUI too.

Don't push your luck.

Well, now that I am thinking, it could be nice to have an automatic sampling in the GUI too.

I just select three or four spots and compare the crop values

Hi Donald
.mp4 files may include the parameter "Rotation" (in degrees). After demuxing with DGdecNV this parameter gets lost, i.e. it is neither kept in the .dgi nor in the elementary video stream.
Would it be possible to include it at the end of the .dgi (similar to the resolution) ?
Mobile phone video clips can be taken in portrait or landscape (at 0, 90, 180, 270 degrees). Preserving the correct orientation is essential for re-encoding to avoid turned and flipped pictures (I think).

admin wrote: ↑

Fri Dec 14, 2018 2:24 pm

Don't push your luck.

gonca wrote: ↑

Fri Dec 14, 2018 3:29 pm

I just select three or four spots and compare the crop values

Me too. On really old restored movies, such as ones from Criterion, AR varies according to the found positives. It's really hard and time consuming but, hey, we are talking about masterpieces.

'Export to script' checkbox added to Cropping Tool in slipstream 164. Refer to the user manual for proper operation.

Sharc wrote: ↑

Sat Dec 15, 2018 4:47 am

Hi Donald
.mp4 files may include the parameter "Rotation" (in degrees). After demuxing with DGdecNV this parameter gets lost, i.e. it is neither kept in the .dgi nor in the elementary video stream.
Would it be possible to include it at the end of the .dgi (similar to the resolution) ?
Mobile phone video clips can be taken in portrait or landscape (at 0, 90, 180, 270 degrees). Preserving the correct orientation is essential for re-encoding to avoid turned and flipped pictures (I think).

You can't tell what the required rotation is just by looking at the video? I'm reluctant to add container specific data to the DGI file.

admin wrote: ↑

Mon Dec 17, 2018 11:36 am

Sharc wrote: ↑

Sat Dec 15, 2018 4:47 am

Hi Donald
.mp4 files may include the parameter "Rotation" (in degrees). After demuxing with DGdecNV this parameter gets lost, i.e. it is neither kept in the .dgi nor in the elementary video stream.
Would it be possible to include it at the end of the .dgi (similar to the resolution) ?
Mobile phone video clips can be taken in portrait or landscape (at 0, 90, 180, 270 degrees). Preserving the correct orientation is essential for re-encoding to avoid turned and flipped pictures (I think).

You can't tell what the required rotation is just by looking at the video? I'm reluctant to add container specific data to the DGI file.

Yes, I can always look at the video of course. However, when I want to automate the process it would be useful to have the the value automatically extracted.
I understand your reluctance though, so maybe I should better extract that value outside of DGindex; perhaps with MediaInfo or similar.

One little cosmetic: don't make the black borders appear again after closing the cropping window AND the script export is selected.

Guest 2 wrote: ↑

Tue Dec 18, 2018 8:39 am

One little cosmetic: don't make the black borders appear again after closing the cropping window AND the script export is selected.

Oops, I screwed up your post by hitting edit instead of quote. Sorry. Feel free to edit it back to the original.

Thanks for the new suggestion. I'll do it for next slipstream.

admin wrote: ↑

Tue Dec 18, 2018 10:41 am

Oops, I screwed up your post by hitting edit instead of quote. Sorry. Feel free to edit it back to the original.

There were only some congratulations for the good job you do every time.

Hint: add a "thank" button for posts we would like to thank. Dunno if technically possible for phpBB.

Hi. I haven't tested our latest release but may I ask how the cropping tool handle border % 2 != 0 ?
( Personally speaking, it should not be over-cropped? )

It's described in the user manuals, also discussed in threads here.

Bottom line: for determining Avisynth Crop() values, mod 2 is fine. For DGSource() cropping, currently nVidia supports mod 2 only for the right and bottom borders. If you try to select mod 2 for the top and left borders and export that to your script, you will get a warning popup. If you must have mod 2 on the top or left, then use Avisynth Crop().

I have another iteration on the cropping design and would appreciate your testing before I slipstream it. The changes are:

* Cropping tool now shows the mod values for the crop values.

* Cropping tool now has an OK button. Exit via OK to retain and use the configured cropping. Exit via the window's X button to discard any changes.

* The 'Export to script' checkbox is eliminated. You now control whether the values get exported by including or not including the __crop__ macro in your template. It's sensible to always include it because it will expand to nothing if cropping is not configured.

* The DGI file now includes a new line called DISP following the SIZ line. This gives the display area, which may differ from the coded size, e.g., when coded height 1088 should be displayed as 1080.

* The DGI file format version is bumped to 22.

* Note: if a stream has a display area smaller than the coded size (e.g., 1080 versus 1088) and cropping is not exported or manually included in DGSource(), then DGSource() will use the display area.

Here are the 64-bit binaries and docs:

http://rationalqm.us/misc/CropRedesign.zip

Did a quick test.
Went item by item on your list and (no surprise) it worked as described

Thanks for the testing, gonca!

admin wrote: ↑

Mon Nov 26, 2018 8:48 am

DGI file formats and semantics are described in the DGIndexNV user manual. Is there something missing?

Back to this:

I was thinking like a quick index page or something.
A table sheet where these values are quickly mentioned.
Say, if I were to make a PNG of such values for such codecs (avc/hevc).

For the most part, I don't have to look up much references to such things as most content I deal with is progressive.

But in the case of SD content from DVD, I dig around my PC for a cheat sheet with such info before I go gallivanting around with QTGMC.
I know TV productions can have hybrid formats, but I can't trust my own notes, especially when I don't archive them online anywhere.

A cheat sheet would handy, in addition to the full documentation.