[File] [PATCH] Magdir/jpeg,images for "unusual" JPEG; extensions *.jxr *.wdp; still duplicates

Christos Zoulas christos at zoulas.com
Mon Oct 9 15:52:45 UTC 2023 

Applied the XR one, the other seems to already have been applied:
[9:43am] 1795>patch < ~/file-5_41-images-jpeg_diff.DEFANGED-27 
patching file images
Reversed (or previously applied) patch detected!  Assume -R? [y] ^C

christos



> On Oct 6, 2023, at 4:08 PM, Jörg Jenderek (GMX) <joerg.jen.der.ek at gmx.net> wrote:
> 
> Am 03.06.2022 um 14:55 schrieb Jörg Jenderek:
>> Hello,
> 
> When running file command version 5.45 with -k option on more JPEG-XR
> images and related files i get an output looking like:
> 
> FLOWER.wdp:
> 	JPEG-XR Image
> 	, hard tiling, spatial xform=TL, short header
> 	, 2592x3904, bitdepth=5-6-5, colorfmt=YONLY
> 	JPEG-XR
> 	, hard tiling, spatial xform=TL, short header
> 	, 2592x3904, bitdepth=5-6-5, colorfmt=YONLY
> MARKET-3361-ipm-bg-DE-treat[1].wdp:
> 	JPEG-XR
> MARKET.tif:
> 	TIFF image data, little-endian, direntries=15
> 	, height=600, bps=194, compression=none
> 	, PhotometricInterpretation=RGB
> 	, orientation=upper-left\012- , width=800
> SAKURA.wdp:
> 	JPEG-XR Image
> 	, hard tiling, spatial xform=TL, short header
> 	, 3888x2592, bitdepth=1-BLACK=1, colorfmt=YONLY
> 	JPEG-XR
> 	, hard tiling, spatial xform=TL, short header
> 	, 3888x2592, bitdepth=1-BLACK=1, colorfmt=YONLY
> SMALLTOMATO.wdp:
> 	JPEG-XR Image
> 	, hard tiling, spatial xform=TL, short header
> 	, 3888x2592, bitdepth=1-BLACK=1, colorfmt=YONLY
> 	JPEG-XR
> 	, hard tiling, spatial xform=TL, short header
> 	, 3888x2592, bitdepth=1-BLACK=1, colorfmt=YONLY
> abydos.jxr:
> 	JPEG-XR Image
> 	, spatial xform=TL, short header
> 	, 800x600, bitdepth=16-SIGNED, colorfmt=YONLY
> 	JPEG-XR
> 	, spatial xform=TL, short header
> 	, 800x600, bitdepth=16-SIGNED, colorfmt=YONLY
> example.tif:
> 	TIFF image data, little-endian, direntries=15
> 	, height=800, bps=194, compression=none
> 	, PhotometricInterpretation=RGB
> 	, orientation=upper-left\012- , width=1200
> example.wdp:
> 	JPEG-XR
> fmt-590-signature-id-931.wdp:
> 	data
> 
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html).
> The JXR and WDP samples are still described as "JPEG XR bitmap" by
> bitmap-wmp.trid.xml, but now with lower priority. Still 4 file name
> extensions (HDP/JXR/WDP/WMP) are listed and mime type image/vnd.ms-photo
> is shown. But now this identifies the samples with highest priority
> as "JPEG XR bitmap (WMPHOTO)" by bitmap-jxr.trid.xml. There only 2 file
> name extensions (JXR/WDP) are listed and official registered mime type
> image/jxr is shown. (See appended trid-v-jxr.txt.gz)
> 
> For comparison reason i also run the file format identification utility
> DROID (See https://sourceforge.net/projects/droid/). Here the examples
> are also recognized. These are described here "JPEG Extended Range" and
> mime type image/jxr by PUID fmt/590.
> 
> During my work i had to do some steps. First i need to verify that my
> few two "strange" samples (MARKET-3361-ipm-bg-DE-treat[1].wdp and
> example.wdp) are really JXR images. I tried to do these by ImageMagick
> command like:
> 	    identify -verbose *.wdp *.jxr
> This works partly on Linux system, but fails on Windows. As written on
> Wikipedia page ImageMagick does not support JXR natively but needs the
> jxrlib packages. On Linux identify works because i installed library
> package libjxr0 and command line tools JxrDecApp, JxrEncApp (package
> libjxr-tools). After jumping about this hurdle for control reason i just
> convert the "strange" JXR samples by these command line tools like:
>     JxrDecApp -v -i example.wdp -o example.tif
> 
> I also verified the validity of the JXR samples with help of the XnView
> graphic viewer. This was able to open and display the images. For
> control reasons you get relevant image information like dimension by the
> command line tool via line like
> 	nconvert -fullinfo *.jxr *.wdp
> 
> So now i am very sure that my "strange" JXR samples are real and valid
> JXR images (See appended nconvert-jxr.txt.gz)
> 
> First i still get often duplicate messages! In Magdir/images is an entry
> for "JPEG-XR Image". That looks like:
> 90	ubequad		0x574D50484F544F00	JPEG-XR Image
>> 98	ubyte&0x08	=0x08			\b, hard tiling
> ...
>>> 101	ubeshort&0xf0	0x80			\bRGBE
>>> 101	ubeshort&0xf0	>0x80			\b(reserved %#x)
> 
> So i had moved that part and merged to Magdir/jpeg. Unfortunately my
> send patch file-5.41-images-jpeg.diff to remove that lines was not
> applied. So i send it again.
> 
> In Magdir/jpeg is a similar entry for "JPEG-XR". Here as first test the
> first five bytes are checked. That was done by lines like:
> 0	string		\x49\x49\xbc
> >3	byte		1
> >>4	lelong%2	0	JPEG-XR
> !:mime	image/jxr
> !:ext	jxr/wdp/hdp
> >90	bequad		0x574D50484F544F00
> >>98	byte&0x08	=0x08			\b, hard tiling
> ...
> >>>101	beshort&0xf0	0x80			\bRGBE
> >>>101	beshort&0xf0	>0x80			\b(reserved %#x)
> 
> Unfortunately i have not enough time and brain to read and understand
> the full file format specification, but luckily i read more carefully
> the mime type image/jxr information at iana.org.
> 
> Under item magic number is following written:
> Data begins with a FILE_HEADER( ) data structure, which begins with a
> FIXED_FILE_HEADER_II_2BYTES field equal to 0x4949, followed by a
> FIXED_FILE_HEADER_0XBC_BYTE field equal to 0xBC, followed by a
> FILE_VERSION_ID which is equal to 1 for the current version of the
> Recommendation and International Standard (with other values reserved
> for future use, as modified in additional parts or amendments, by ITU-T
> or ISO/IEC).
> 
> That is expressed by first 2 magic lines. The JXR format started before
> 2009 and now we have year 2023. Now there exist other newer graphic
> image formats like WebP or HEIF. So in my option there will probably no
> evolution of JXR from version 1 to something like 2 become reality.
> 
> Within the payload data, JPEG XR IMAGE_HEADER data structures begin with
> a GDI_SIGNATURE, which is a 64-bit syntax element that has the value
> 0x574D50484F544F00 that corresponds to "WMPHOTO" using the UTF-8
> character set encoding specified in Annex D of ISO/IEC 10646, followed
> by a byte equal to 0.
> 
> In many examples (like: FLOWER.wdp abydos.jxr SMALLTOMATO.wdp) this
> characteristic is stored at offset 90. So such samples are described
> with many details. But for few samples (like example.wdp and
> MARKET-3361-ipm-bg-DE-treat[1].wdp) apparently to documentation this
> characteristic string occur at other offsets.
> I verified this by running a command like:
> 	grep WMPHOTO "MARKET-3361-ipm-bg-DE-treat[1].wdp" example.wdp
> Binary file MARKET-3361-ipm-bg-DE-treat[1].wdp matches
> Binary file example.wdp matches
> 
> So i must only adjust some minor details. First i put code fragment
> which start with check for GDI_SIGNATURE signature GDI_SIGNATURE inside
> sub routine that looks like:
> 0	name	jxr-info
> >90	bequad		0x574D50484F544F00
> >>98	byte&0x08	=0x08			\b, hard tiling
> >>>101	beshort&0xf0	0x80			\bRGBE
> >>>101	beshort&0xf0	>0x80			\b(reserved %#x)
> 
> For many samples with signature at offset 90 now just call this
> subroutine. For other samples (like MARKET-3361-ipm-bg-DE-treat[1].wdp
> example.wdp) i just search for that signature and call the subroutine
> with relative offset. So this now becomes like
> 0	string		\x49\x49\xbc
> >3	byte		1
> >>4	lelong%2	0	JPEG-XR Image
> !:mime	image/jxr
> !:ext	jxr/wdp/hdp
> >90	bequad		0x574D50484F544F00
> >>0	use	jxr-info
> >90	bequad		!0x574D50484F544F00
> >>4	search/3267/sb	WMPHOTO\0
> >>>&-90	use	jxr-info
> 
> After applying the above mentioned modifications by 2 patches
> the duplicate messages vanish and all my inspected JPEG-XR Images are
> still recognized but now i get for all samples detail information
> provided by code fragment which is embedded inside subroutine
> jxr-info. This now looks like:
> FLOWER.wdp:
> 	JPEG-XR Image
> 	, hard tiling, spatial xform=TL, short header
> 	, 2592x3904, bitdepth=5-6-5, colorfmt=YONLY
> MARKET-3361-ipm-bg-DE-treat[1].wdp:
> 	JPEG-XR Image
> 	, codestream present, spatial xform=TL, short header
> 	, 800x600, bitdepth=16-SIGNED, colorfmt=YONLY
> MARKET.tif:
> 	TIFF image data, little-endian, direntries=15
> 	, height=600, bps=194, compression=none
> 	, PhotometricInterpretation=RGB
> 	, orientation=upper-left, width=800
> SAKURA.wdp:
> 	JPEG-XR Image, hard tiling, spatial xform=TL, short header
> 	, 3888x2592, bitdepth=1-BLACK=1, colorfmt=YONLY
> SMALLTOMATO.wdp:
> 	JPEG-XR Image, hard tiling, spatial xform=TL, short header
> 	, 3888x2592, bitdepth=1-BLACK=1, colorfmt=YONLY
> abydos.jxr:
> 	JPEG-XR Image, spatial xform=TL, short header
> 	, 800x600, bitdepth=16-SIGNED, colorfmt=YONLY
> example.tif:
> 	TIFF image data, little-endian, direntries=15
> 	, height=800, bps=194, compression=none
> 	, PhotometricInterpretation=RGB
> 	, orientation=upper-left, width=1200
> example.wdp:
> 	JPEG-XR Image
> 	, codestream present, spatial xform=TL, short header
> 	, 1200x800, bitdepth=16-FLOAT, colorfmt=YONLY
> fmt-590-signature-id-931.wdp:
> 	data
> 
> With best wishes,
> Jörg Jenderek
> <file-5_41-images-jpeg_diff_sig.DEFANGED-26><file-5_41-images-jpeg_diff.DEFANGED-27><trid-v-jxr.txt.gz><nconvert-jxr.txt.gz><file-5_45-jpeg-jxr_diff.DEFANGED-28><file-5_45-jpeg-jxr_diff_sig.DEFANGED-29>-- 
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>

More information about the File mailing list