Total Commander

I have several JPGs which have a leading CR/LF at the file beginning, before the JPG header. These file are displayed correctly in graphics programs and also in XnView/IrfanView, but not with TC Lister.
Example file for testing can be found here.

Could Lister please be more tolerant and also pass these files to the used graphics viewer?

[Edit: updated title]

Lister doesn't handle handle JPEG itself. So what mechanism do you use for displaying JPEG files?

2Lefteous
I suppose you mean the author?

In Lister options I have set XnView/IrfanView to handle "graphics other than BMP", which works with other JPGs.
I just press F3 to load the lister with the file - and get it displayed as binary. Switching to "Image/Multimedia" with key 4 or Options menu doesn't change anything, it's still displayed as binary.
Calling XnView/IrfanView directly with the filename will display it.


[Edit] Quick View (Ctrl-Q) doesn't display these files as image either. [/Edit]

2StatusQuo

I suppose you mean the author?

Yes the author of this thread

In Lister options I have set XnView/IrfanView to handle "graphics other than BMP", which works with other JPGs.
I just press F3 to load the lister with the file - and get it displayed as binary. Switching to "Image/Multimedia" with key 4 or Options menu doesn't change anything, it's still displayed as binary.
Calling XnView/IrfanView directly with the filename will display it.

I can confirm that it doesn't work when using XnView.

Using the the Lister plug-in SGViewer your test image is displayed fine.

Lefteous wrote:Using the the Lister plug-in SGViewer your test image is displayed fine.

Thanks, but not confirmed here - also after installing SGViewer 1.9.1 it's still displayed as binary.
I have put SGViewer to the top of the plugins, even removed all other lister plugins from the INI and restarted TC - no success.

If viewing a similar named file and then using the next/previous functions of SGView (the green buttons, not the ones in TC's menu), then on the faulty file it displays "[ERROR] test_leading-crlf.jpg" - while XnView would display it, if the file would be passed through to it.

So

Lister doesn't handle handle JPEG itself

, but maybe Lister checks, if the file is really a JPEG, before calling the external viewer?

Using SGViewer plugin 1.9.1 works fine for me.
It displays the test with F3 and also in Quickview.

Also Irfanview works fine with it.

Lister plugin Imagine 1.0.0.0 beta 4 ignores the file.
Lister plugin ImgView 1.0 crashes.
Lister plugin SGViewer 1.9.1 ignores the file.

When all image plugins are disabled:
XnView 1.90.3 and IrfanView 4.0 ignores the file when configured as internal viewers in Lister.

Both XnView and IrfanView can show the file when used as external viewers.

Using Imagine as standalone tells that the file format is not supported.

Microsoft Picture and Fax Viewer cannot show the picture either.

I can not make SGViewer work with that file - I have tried in TC 7rc4 and rc5.5 even with a fresh ini-file (with SGViewer as the only installed plugin).

If viewing a similar named file and then using the next/previous functions of SGView (the green buttons, not the ones in TC's menu), then on the faulty file it displays "[ERROR] test_leading-crlf.jpg"

Confirmed!

while XnView would display it, if the file would be passed through to it.

Not confirmed - I can NOT make XNView (nor IrfanView) show the file, not even working my way to it using the N(ext) key.

I only use Irfan View 4.0 and Imagine 0.9.7.0.
Lister plugin Imagine ignores the file.
Plugin disabled :
IV as internal viewer fails, as external shows the file.
Why would there be a leading-crlf in the first place, I wondered. It doesn't seem to make sense.
This is easy to correct in the meantime.
Convert the file to a uncompressed format like BMP. Save that file back to JPEG, with very high quality,
to limit the losses, and the crlf is gone.

petermad wrote:When all image plugins are disabled:
XnView 1.90.3 and IrfanView 4.0 ignores the file when configured as internal viewers in Lister.

Both XnView and IrfanView can show the file when used external viewers.

Confirmed - I didn't remember to configure XnView as the default external viewer, this way it now works here, too (standard key = Alt-F3).
Thanks for testing all this!

while XnView would display it, if the file would be passed through to it.

Not confirmed - I can NOT make XNView (nor IrfanView) show the file, not even working my way to it using the N(ext) key.

Exactly, that's my point. If you call XnView on the command line (d:\path\xnview.exe file.jpg), it will display the file. Unfortunately it does not in TC's Lister.
So I assume Lister does NOT even (try to) call XnView, otherwise the file should get displayed, shouldn't it?

Sam_Zen wrote:Why would there be a leading-crlf in the first place, I wondered. It doesn't seem to make sense.

Agree, maybe it was some kind of software (old mail program, download manager etc.) did this. Unfortunately they look this way now.

This is easy to correct in the meantime.
Convert the file to a uncompressed format like BMP. Save that file back to JPEG, with very high quality,
to limit the losses, and the crlf is gone.

Some text editors will also do (i.e. TextPad: rename to *.txt and remove the first line). But hundreds of files are this way, in a collection of thousands. Additionally I'd like to keep the file dates, so this correction will be a lot of manual work - unneccessary work, because (some) viewers allow viewing them unchanged - it they get the file.

Horst.Epp wrote:Using SGViewer plugin 1.9.1 works fine for me.
It displays the test with F3 and also in Quickview.

Also Irfanview works fine with it.

Strange, what do I do wrong, then?
After XnView/IrfanView both failed on the test file in internal lister, I've set up SGViewer as first lister plugin. It displays "normal" JPGs, but not this test jpg (and the others in same style) - the newest SGViewer version 1.9.1 even displays an [ERROR] (as mentioned above).

So I assume Lister does NOT even (try to) call XnView

Well, maybe XnView/IrfanView are not called (when used as internal viewers) - but it seems that the plugin ImgView is called and tries to read the file, since it comes up with an error message and crashes.

petermad wrote:

So I assume Lister does NOT even (try to) call XnView

Well, maybe XnView/IrfanView are not called (when used as internal viewers) - but it seems that the plugin ImgView is called and tries to read the file, since it comes up with an error message and crashes.

So viewers available as TC plugins (like ImgView) seem not to be able to display this problematic files.
XnView/IrfanView would be able to, but are only available as EXE, not as TC plugin - and as those they are not called by TC.

For testing purpose I've replaced the entry for XnView (in internal Lister's options) with another program (i.e. calc.exe) and removed all lister plugin entries.
Result: With a normal JPG calc.exe is started, on the test-JPG (with added CR/LF at the beginning) it is not.

StatusQuo wrote:For testing purpose I've replaced the entry for XnView (in internal Lister's options) with another program (i.e. calc.exe) and removed all lister plugin entries.
Result: With a normal JPG calc.exe is started, on the test-JPG (with added CR/LF at the beginning) it is not.

This is because TC analysizes the Header of the file and sees that its NOT an JPEG

Very right. And TC analyzes first because it's another protocol.
The proof of this can be seen in the representation. If it's shown with a plugin like Imagine, the full implementation
is shown, with all the edit-possibilities.
If, as internal viewer, IV is used, then the app is not available. Only the reading is transferred to the lister window.