I've got quite a few problematic JPG images containing invalid JPG markers making them unloadable in DOpus and other applications.
Listers (thumbnail mode) perfectly display an image preview, as does the Viewer Pane (Shell Thumbnail). However double clicking the same image file in the lister pane to view in full screen mode displays a blank bluish screen with the following message: Unable to load 'filename.jpg' as a picture.
(Am I correct that image loadings and previews are not handled the exact same everywhere in the file manager?).
In full screen view DOpus does cleverly skip unloadable images files and automatically jumps to the next loadable image when cycling through them eliminating the blank screens with an error message.
It does make finding all unloadable images quite challenge, so I was wondering:
Is there an easy way in DOpus to search for/list all problematic/unloadable JPG image files (with invalid JPG markers) within a folder?
I tried converting and resaving some of these problem files with DOpus's Convert Images tool (Convert... + Save As) but dit not succeed as I got this error: An error occurred converting 'filename.jpg': Unable to load picture
I did manage to do a batch convert/replace of these files with FastStone Image Viewer (which are now perfectly displayed in DOpus full screen view) but was hoping to do this within DOpus
Why in the case of WEBP DOpus Viewer relies on filename extension? I can rename something.png file to something.jpg and Viewer loads the file without problem. Something.webp is loaded without problem too, but if it is renamed to something.jpg there is problem as described in first post.
I use some apps in Android than create files with jpg extension, but these are webp images
Not possible to display these images with Opus viewer ? Distinguish them in lister (script, evaluator...) ?
In my case to create a difficult test file for DOpus Viewer.
The same for something.jp2, something.pcx, something.jxl if renamed to something.png.
JPEG 2000, PCX, JPEG JXL, WebP - all are handled in DOpus by plugins. Some of the plugins are created by GP Software, some by YOU, some by other author.
Identifying files by content is a bit slower, so we tend to only do it for some formats.
Also avoids having to work out how to accurately identify files by content, which isn't always obvious or documented for some formats.
It can also depend on the library that decodes the files, since some of those require correct extensions, although that's probably not a factor with libwebp.
Maybe the WebP plugin should be improved in this respect, given Chrome's complete inability to use the correct file extension when saving images (even JPEGs, which is insists on saving as .JFIF if no extension is specified by the server, despite JFIF never being a valid extension for JPEG files in the history of the universe).
Would be nice if Chrome fixed its own bugs to avoid creating these messes in the first place, but we know Google don't do that or pay any attention to feedback, so I'm dreaming when I say that.
Generating a thumbnail of some picture file means either a reading of embedded thumbnail or reading the entire file (and decoding, scaling in next steps). Something more computationally intensive than relying on filename extension. Relying on filename extension (or on MIME type) is sufficient to determining a generic thumbnail.
A picture viewer (not only DOpus Viewer) by nature of its application does more than identifying of file type. I would not expect from a picture viewer that it will try to display MP3 file assuming that the file is PNG basing on the file's filename extension. The same for trying to decode WebP, PCX, JPEG files as though it would be PNG basing on the file's filename extension. It is not appropriate approach IMO. Good thing is that a viewer doing so does not crash.
Those aren't the only times files have to be identified.
Almost everything on Windows works by file extensions. If you want a different application association for WebP and JPEG files, good luck doing that by file content in Windows, since it's going to choose which program to send them to based on nothing but the extension, even if the programs themselves analyze file content once the file reaches them.
It's nice to have files recognised by content (and we do that for older/important formats like JPEG), but extensions should still be correct, and it adds overhead to check contents for lots of different types.
I agree, but (bluntly speaking) IrfanView does not have a problem of displaying JPEG 2000 or WebP file if the file has PNG extension. If so, it is because it decodes it as JPEG 2000 or WebP respectively.
Your words:
Apparently it applies to all plugins used by DOpus Picture Viewer.
If it is immanent peculiarity of the program that it uses that or another plugin basing of file extension, something like MultiView for Amiga relying completely on datatypes system and there is nothing to improve without breaking the immanency, then OK.
JPEG is old in a good sense, because it has substance.
And if you ask me, it is still in its infancy.
You have actually JPEG 9 in Opus, and we are now preparing a groundbreaking new release JPEG 10 to keep it alive and kicking...
