On 2023-11-25 08:06, geoff wrote:
> On 25/11/2023 12:15 pm, Carlos E. R. wrote:
>> On 2023-11-24 23:27, david wrote:
>>> Using <news:ujr0ph$2f35s$1@dont-email.me>, Paul wrote:
>>>
>>>>> How do you make Windows automatically view THM files in file explorer?
>>>>> https://i.postimg.cc/wxCWFdQf/Clipboard01.jpg
>>>>
>>>> Copy the file to your PC, then change the extension to .jpg instead of
>>>> .thm thumbnail.
>>>
>>> Thanks everyone for renaming advice which I saw others had also
>>> suggested.
>>>
>>> It's messy because the crittercam creates an AVI of the exact same
>>> name as
>>> the thumbnail of the AVI (which is the THM file - which is a JPEG file)
>>> and also JPG files (of different names) so it would make it into a mess.
>>>
>>> But of course, for thousands of files, I could rename the file name
>>> also.
>>> But there must be a better way.
>>> move name.THM name_thumbnail.jpg
>>>
>>> But I was hoping for a graceful solution that showed them in the Windows
>>> file explorer as they were intended to be shown as (as AVI thumbnails).
>>
>> Open a bug with Microsoft :-D
>>
>> ...
>>
>
> Nothing to do with Microsoft.
>
> Simply associate .THM files with an application that can display them.

You haven't read the thread, have you? :-DD

>
> Start/Settings/Apps/Default Apps/ "Set a default for the file type of
> link type."
>
> ACDSee (for one) views THM file natively.
>
> geoff

--
Cheers,
Carlos E.R.

On 2023-11-25 04:54, Joel wrote:
> Paul <nospam@needed.invalid> wrote:
>> On 11/24/2023 9:08 PM, Char Jackson wrote:
>>>
>>> AVI? In 2023? That's disappointing. I thought we had left that dinosaur behind
>>> 20+ years ago.
>>
>> The format is a function of the hardware support.
>>
>> AVI is what you might do, if all you've got is a CPU core
>> to work with. A movie compressor logic block, would make it
>> possible to make other (more efficient) outputs.
>>
>> https://cloudinary.com/guides/video-formats/avi-format-should-you-still-use-avi
>>
>> "Some popular codecs used with AVI files include DivX, XviD, and MJPEG."
>
>
> Interesting point - obsolete codecs still have use on "obsolete"
> hardware, or for archived files. I've tended to refresh my approaches
> to accessing media, save for my music collection, but the support of
> legacy gear and media can be something to judge a modern system by.

And something that must not be done, is convert the old avi files to
something modern, because any conversion loses some quality. Unless what
is done is replace the container, and leave the data streams intact, but
to what purpose?

So yes, we need to keep supporting avi and more importantly, the codecs
used with it.

--
Cheers,
Carlos E.R.

On 2023-11-25 00:59, Alan Browne wrote:
> On 2023-11-24 18:52, Carlos E. R. wrote:
>> On 2023-11-25 00:48, Alan Browne wrote:
>>> On 2023-11-24 17:27, david wrote:
>>>> Using <news:ujr0ph$2f35s$1@dont-email.me>, Paul wrote:
>>>>
>>>>>> How do you make Windows automatically view THM files in file
>>>>>> explorer?
>>
>> ...
>>
>>>> Well, I could rename thousands of files but I was hoping that, since
>>>> AVI
>>>> theumbnail files are created by many crittercams, that it would be more
>>>> fluid to just ask Windows to display AVI THM files as thumbnail files.
>>>
>>> Jumping in w/o reading much of the thread ...
>>>
>>> Can't you simply tell Windows to open .thm with a photoviewer of choice?
>>
>> Sure, but he wants the filemanager to show the previews.
>
> Even in Windows a normal sized JPGs will be automatically shown as
> thumbnails in the folder viewer (whatever MS calls that this week).

Sure, but not .thm files, that's the issue.

>
> Apps that manage photos (or vids) should do pretty much the same w/o
> needing a "sidecar" photo (although such "cached" as a hidden file is
> not too obnoxious in order to speed things up).

Creating a preview of a video takes time, likely a few seconds per file.
The camera tries to help by saving the previews alongside the videos.

>
> Sorry I jumped in - I should have known better.  I'll run along now.
>

--
Cheers,
Carlos E.R.

On 2023-11-25 08:11, Carlos E. R. wrote:
> On 2023-11-25 00:59, Alan Browne wrote:
>> On 2023-11-24 18:52, Carlos E. R. wrote:
>>> On 2023-11-25 00:48, Alan Browne wrote:
>>>> On 2023-11-24 17:27, david wrote:
>>>>> Using <news:ujr0ph$2f35s$1@dont-email.me>, Paul wrote:
>>>>>
>>>>>>> How do you make Windows automatically view THM files in file
>>>>>>> explorer?
>>>
>>> ...
>>>
>>>>> Well, I could rename thousands of files but I was hoping that,
>>>>> since AVI
>>>>> theumbnail files are created by many crittercams, that it would be
>>>>> more
>>>>> fluid to just ask Windows to display AVI THM files as thumbnail files.
>>>>
>>>> Jumping in w/o reading much of the thread ...
>>>>
>>>> Can't you simply tell Windows to open .thm with a photoviewer of
>>>> choice?
>>>
>>> Sure, but he wants the filemanager to show the previews.
>>
>> Even in Windows a normal sized JPGs will be automatically shown as
>> thumbnails in the folder viewer (whatever MS calls that this week).
>
> Sure, but not .thm files, that's the issue.
>
>>
>> Apps that manage photos (or vids) should do pretty much the same w/o
>> needing a "sidecar" photo (although such "cached" as a hidden file is
>> not too obnoxious in order to speed things up).
>
> Creating a preview of a video takes time, likely a few seconds per file.
> The camera tries to help by saving the previews alongside the videos.

On this computer video previews (a frame) go at about 100 per second
judging by how fast the list fills out on screen. And that's reading
from an external, encrypted disk.

--
“Markets can remain irrational longer than your can remain solvent.”
- John Maynard Keynes.

On 11/25/2023 4:58 AM, Carlos E. R. wrote:
> On 2023-11-25 04:54, Joel wrote:
>> Paul <nospam@needed.invalid> wrote:
>>> On 11/24/2023 9:08 PM, Char Jackson wrote:
>>>>
>>>> AVI? In 2023? That's disappointing. I thought we had left that dinosaur behind
>>>> 20+ years ago.
>>>
>>> The format is a function of the hardware support.
>>>
>>> AVI is what you might do, if all you've got is a CPU core
>>> to work with. A movie compressor logic block, would make it
>>> possible to make other (more efficient) outputs.
>>>
>>> https://cloudinary.com/guides/video-formats/avi-format-should-you-still-use-avi
>>>
>>>    "Some popular codecs used with AVI files include DivX, XviD, and MJPEG."
>>
>>
>> Interesting point - obsolete codecs still have use on "obsolete"
>> hardware, or for archived files.  I've tended to refresh my approaches
>> to accessing media, save for my music collection, but the support of
>> legacy gear and media can be something to judge a modern system by.
>
> And something that must not be done, is convert the old avi files to something modern, because any conversion loses some quality. Unless what is done is replace the container, and leave the data streams intact, but to what purpose?
>
> So yes, we need to keep supporting avi and more importantly, the codecs used with it.
>

All you need, is a lossless conversion.

And as the person doing this, you have to do the research,
to see that this is true. For example, if your source material
is 4:4:4 and a "lossless" container happens to be 4:2:0,
then you need to understand whether that is "really lossless"
or not.

It's not a trivial matter.

That's why when I was converting 200GB source files into
more economical containers, I had to be very careful about
what I was doing. Sure, I can make a 7GB MP4 faster than
you can snap your fingers, out of one of those, but
technically the process is lossy, and you can't keep
doing that from one generation to another, without
some effect.

My video card can convert such a video file (single pass), at 11x real time.
A 60 minute video could be converted in 6 minutes. But the
problem is, the Q factor is wrong on the defaults NVidia
uses, and the actual output is not what it is supposed to be.
You'd be surprised how many "traps for the unwary" there
are, for this topic.

Paul

On 11/25/2023 9:31 AM, Alan Browne wrote:
> On 2023-11-25 08:11, Carlos E. R. wrote:
>> On 2023-11-25 00:59, Alan Browne wrote:
>>> On 2023-11-24 18:52, Carlos E. R. wrote:
>>>> On 2023-11-25 00:48, Alan Browne wrote:
>>>>> On 2023-11-24 17:27, david wrote:
>>>>>> Using <news:ujr0ph$2f35s$1@dont-email.me>, Paul wrote:
>>>>>>
>>>>>>>> How do you make Windows automatically view THM files in file explorer?
>>>>
>>>> ...
>>>>
>>>>>> Well, I could rename thousands of files but I was hoping that, since AVI
>>>>>> theumbnail files are created by many crittercams, that it would be more
>>>>>> fluid to just ask Windows to display AVI THM files as thumbnail files.
>>>>>
>>>>> Jumping in w/o reading much of the thread ...
>>>>>
>>>>> Can't you simply tell Windows to open .thm with a photoviewer of choice?
>>>>
>>>> Sure, but he wants the filemanager to show the previews.
>>>
>>> Even in Windows a normal sized JPGs will be automatically shown as thumbnails in the folder viewer (whatever MS calls that this week).
>>
>> Sure, but not .thm files, that's the issue.
>>
>>>
>>> Apps that manage photos (or vids) should do pretty much the same w/o needing a "sidecar" photo (although such "cached" as a hidden file is not too obnoxious in order to speed things up).
>>
>> Creating a preview of a video takes time, likely a few seconds per file. The camera tries to help by saving the previews alongside the videos.
>
> On this computer video previews (a frame) go at about 100 per second judging by how fast the list fills out on screen.  And that's reading from an external, encrypted disk.

Windows keeps a thumbnail cache.

"slow" formats benefit the most from this. PDF thumbnailing
is painfully slow. Caching of PDF thumbnails then, actually makes sense.
This is the use case, that justifies caching.

For JPEG and GIF, Windows uses some "turbojpeg" or such,
that it turns out, doing realtime conversion every time the
folder opens, is actually FASTER than the cache path.
Which I think is hilarious. You would think a cache path
would always be faster, than doing the work over again,
but someone tested, and it isn't.

For the OPs AVI, it should be faster if the AVI preview comes
from the system Thumbnail cache. When you thumbnail a video,
you don't take the first frame, and there is some sampling
heuristic to select an "interesting frame" for the purpose.
That would be part of what makes it potentially slow.

This is what I like about FFMPEG as an engine. If there's
something you want to do, someone has already done it. It
really is the Swiss Army Knife of video tools. That Videohelp
addon, could be using a command like this for the purpose.

https://superuser.com/questions/538112/meaningful-thumbnails-for-a-video-using-ffmpeg

"The filter "thumbnail" tries to find the most representative frames in the video:

ffmpeg -i input.mp4 -vf "thumbnail,scale=640:360" -frames:v 1 thumb.png
"

Paul

On 11/25/2023 2:06 AM, geoff wrote:

>
> Nothing to do with Microsoft.
>
> Simply associate .THM files with an application that can display them.
>
> Start/Settings/Apps/Default Apps/ "Set a default for the file type of link type."
>
> ACDSee (for one) views THM file natively.
>
> geoff

Nobody wants to see a 160:120 thumbnail stored in a 3KB or 5KB file.
That would be awful. They want the system thumbnailer, to make
a representation from the actual content. That would look nice,
relatively speaking. Then, you don't even need to copy *any* .THM
files to the system, since the system is going to "paint" the AVI
file icon with an "actual thumbnail".

In the following picture, shows a directory of identical JPEG files,
with Extra-Large, Large, and Medium thumbnails. The thumbnails were
made by File Explorer, using a built-in Thumbnail Provider. if you
have a favorite file type, for which you want generated-on-the-spot
thumbnails made, for easy selection, then you add a Thumbnail Provider
to the Windows system.

[Picture]

https://i.postimg.cc/C1gV5J4w/Windows-File-Thumbnail-Sizes.gif

The Small thumbnail representation, uses the bound application icon instead,
which is boring (all the files look the same then, because the irfanview
icon is used instead). If you have not configured this ("what opens a JPG"),
there is a "danger" the Windows Photo.App could open :-) Once you see
that scanning your system at high speed, you won't make the mistake of
opening that a second time :-/

Paul

On 2023-11-25 18:46, Paul wrote:
> On 11/25/2023 9:31 AM, Alan Browne wrote:
>> On 2023-11-25 08:11, Carlos E. R. wrote:
>>> On 2023-11-25 00:59, Alan Browne wrote:
>>>> On 2023-11-24 18:52, Carlos E. R. wrote:
>>>>> On 2023-11-25 00:48, Alan Browne wrote:
>>>>>> On 2023-11-24 17:27, david wrote:
>>>>>>> Using <news:ujr0ph$2f35s$1@dont-email.me>, Paul wrote:

>>>> Apps that manage photos (or vids) should do pretty much the same w/o needing a "sidecar" photo (although such "cached" as a hidden file is not too obnoxious in order to speed things up).
>>>
>>> Creating a preview of a video takes time, likely a few seconds per file. The camera tries to help by saving the previews alongside the videos.
>>
>> On this computer video previews (a frame) go at about 100 per second judging by how fast the list fills out on screen.  And that's reading from an external, encrypted disk.
>
> Windows keeps a thumbnail cache.
>
> "slow" formats benefit the most from this. PDF thumbnailing
> is painfully slow. Caching of PDF thumbnails then, actually makes sense.
> This is the use case, that justifies caching.
>
> For JPEG and GIF, Windows uses some "turbojpeg" or such,
> that it turns out, doing realtime conversion every time the
> folder opens, is actually FASTER than the cache path.
> Which I think is hilarious. You would think a cache path
> would always be faster, than doing the work over again,
> but someone tested, and it isn't.

Often, photos contain a preview inside, so the browser only has to open
the file, read the metadata, get the preview block, then display it. As
compared to open both photo and cache files, maybe load the metadata on
both, decide if the preview block in the cache pertains to the photo
file, and display it.

>
> For the OPs AVI, it should be faster if the AVI preview comes
> from the system Thumbnail cache. When you thumbnail a video,
> you don't take the first frame, and there is some sampling
> heuristic to select an "interesting frame" for the purpose.
> That would be part of what makes it potentially slow.

Absolutely.

....

--
Cheers,
Carlos E.R.

On 2023-11-25 18:09, Paul wrote:
> On 11/25/2023 4:58 AM, Carlos E. R. wrote:
>> On 2023-11-25 04:54, Joel wrote:
>>> Paul <nospam@needed.invalid> wrote:
>>>> On 11/24/2023 9:08 PM, Char Jackson wrote:
>>>>>
>>>>> AVI? In 2023? That's disappointing. I thought we had left that dinosaur behind
>>>>> 20+ years ago.
>>>>
>>>> The format is a function of the hardware support.
>>>>
>>>> AVI is what you might do, if all you've got is a CPU core
>>>> to work with. A movie compressor logic block, would make it
>>>> possible to make other (more efficient) outputs.
>>>>
>>>> https://cloudinary.com/guides/video-formats/avi-format-should-you-still-use-avi
>>>>
>>>>    "Some popular codecs used with AVI files include DivX, XviD, and MJPEG."
>>>
>>>
>>> Interesting point - obsolete codecs still have use on "obsolete"
>>> hardware, or for archived files.  I've tended to refresh my approaches
>>> to accessing media, save for my music collection, but the support of
>>> legacy gear and media can be something to judge a modern system by.
>>
>> And something that must not be done, is convert the old avi files to something modern, because any conversion loses some quality. Unless what is done is replace the container, and leave the data streams intact, but to what purpose?
>>
>> So yes, we need to keep supporting avi and more importantly, the codecs used with it.
>>
>
> All you need, is a lossless conversion.
>
> And as the person doing this, you have to do the research,
> to see that this is true. For example, if your source material
> is 4:4:4 and a "lossless" container happens to be 4:2:0,
> then you need to understand whether that is "really lossless"
> or not.
>
> It's not a trivial matter.
>
> That's why when I was converting 200GB source files into
> more economical containers, I had to be very careful about
> what I was doing. Sure, I can make a 7GB MP4 faster than
> you can snap your fingers, out of one of those, but
> technically the process is lossy, and you can't keep
> doing that from one generation to another, without
> some effect.
>
> My video card can convert such a video file (single pass), at 11x real time.
> A 60 minute video could be converted in 6 minutes. But the
> problem is, the Q factor is wrong on the defaults NVidia
> uses, and the actual output is not what it is supposed to be.
> You'd be surprised how many "traps for the unwary" there
> are, for this topic.
Thus, I prefer not to do it :-)

--
Cheers,
Carlos E.R.