XYplorer Beta Club

in latest version

OK, thanks.

I tried the new beta version, and it does not display thumbnails of some of JPG file (photo from the phone).
In a copy dialog thumbnails work great: File for experiments:

Indeed! Interesting case...

Here is what makes that image different from most JPEGs around.

Every JPEG file consists of a bunch of segments, one after another. These segments start with 2 byte marker (of which first byte is always FF), followed by 2-byte value (which gives us size of these 2 bytes plus size of data to follow), followed by data (if size > 2).

Some segments don't contain size and data, just the 2-byte marker. This is the case for FF D8 (always first segment of an image), FF D9 (always the last segment of an image) and also for so-called restart markers, which I won't get into here.

Here is how the provided JPEG looks like:
FF D8 (start of image)
FF E1 (APP1 segment, contains Exif) 59 0B (size of exif data to follow, plus 2) 45 78 ... B4 47 FF D9 (exif data)
FF D9 (unknown APP5 segment) 01 FE (size of data, plus 2) FB BA .. 00 00 (data)

now we have something interesting:
FF FF FF E0 --> FF E0 is a start of an APP0 segment, but what are those FFs before that?

Those are so called fill bytes. Any marker segment may be preceded by one or more FF bytes. Or, quoting directly from JPEG specification (page 35, http://www.w3.org/Graphics/JPEG/itu-t81.pdf):

Any marker may optionally be preceded by any number of fill bytes, which are bytes assigned code X’FF’.

So XY algorithm likely treats FF FF as a segment marker (wrong) and FF E0 as size (also wrong). The correct way is to skip all FF bytes until we get something other than FF FF (in our case FF E0).

If you remove those two FF bytes, image is then correctly displayed.

isn't displaying icon for items that don't have thumbnails better than this message?

yusef88 wrote:isn't displaying icon for items that don't have thumbnails better than this message?

Sure! That was a bug. It's fixed now. You might need to redo your cache to get rid of it.

xman wrote:Here is what makes that image different from most JPEGs around.

Every JPEG file consists of a bunch of segments, one after another. These segments start with 2 byte marker (of which first byte is always FF), followed by 2-byte value (which gives us size of these 2 bytes plus size of data to follow), followed by data (if size > 2).

Some segments don't contain size and data, just the 2-byte marker. This is the case for FF D8 (always first segment of an image), FF D9 (always the last segment of an image) and also for so-called restart markers, which I won't get into here.

Here is how the provided JPEG looks like:
FF D8 (start of image)
FF E1 (APP1 segment, contains Exif) 59 0B (size of exif data to follow, plus 2) 45 78 ... B4 47 FF D9 (exif data)
FF D9 (unknown APP5 segment) 01 FE (size of data, plus 2) FB BA .. 00 00 (data)

now we have something interesting:
FF FF FF E0 --> FF E0 is a start of an APP0 segment, but what are those FFs before that?

Those are so called fill bytes. Any marker segment may be preceded by one or more FF bytes. Or, quoting directly from JPEG specification (page 35, http://www.w3.org/Graphics/JPEG/itu-t81.pdf):

Any marker may optionally be preceded by any number of fill bytes, which are bytes assigned code X’FF’.

So XY algorithm likely treats FF FF as a segment marker (wrong) and FF E0 as size (also wrong). The correct way is to skip all FF bytes until we get something other than FF FF (in our case FF E0).

If you remove those two FF bytes, image is then correctly displayed.

Thanks, man! I will pimp my logic...

EDIT: Bingo, it works!

thans for fixing icons bug and here is another one after click mouse hover preview i got this mess

Indeed! Fix comes, thanks!

I have tried the new beta and it does not correctly display thumbnails of some of JPG files (photo from the camera) in "High Speed" mode mode: In the "Fast" mode everything correctly: File for experiments: https://www.dropbox.com/s/59ee7kfo3ssdv ... 7.zip?dl=1
--------------------------------------
And yet. Now the "High Speed" mode XYplorer mode creates the thumbnails from all big file it isn't effective. For the speed of display it is necessary to look for in the file and to show the built-in thumbnails (on my picture this preview with black strips).
It is a little explanation:

For most JPEG images created by phones or digital cameras, the thumbnail image (if present) is stored in the APP1 marker (FFE1). Inside this marker segment is a TIFF file containing the EXIF information for the main image and the optional thumbnail image stored as a JPEG compressed image. The TIFF file usually contains two "pages" where the first page is the EXIF info and the second page is the thumbnail stored in the "old" TIFF type 6 format. Type 6 format is when a JPEG file is just stored as-is inside of a TIFF wrapper.
The wikipedia page on JFIF at http://en.wikipedia.org/wiki/JPEG_File_ ... nge_Format gives a good description of the JPEG Header(the header contains the thumbnail as an uncompressed raster image).

The request to add support of the built-in thumbnails for the TIFF files. As far as I know, now only Adobe Bridge works with the built-in thumbnails of TIFF, it is good if XYplorer too learns to show the built-in thumbnails for the TIFF files.

I cannot reproduce the auto-rotate issue with your sample file. Works alright here in each of the quality modes.

Strange. So I launched the latest latest XYplorer BETA v15.80.0209 with the command ::fresh
There is an error:

Which Windows?

admin wrote:Which Windows?

OS: Windows 7 Home Basic (Service Pack 1), 32-bit (6.1)
User Role: Admin
Themes: No