Upload fails with (some) JPG images

[bpgs]

Recently I've updated from 0.8.17 to 0.8.19. Then I tried to upload a .jpg file, e.g. this example file. The result was this message

Can't write file 'media/images/dscf3902-testbild.jpg'

In other cases, i.e. other Webpsace with Yellow 0.8.19 asswell, I got the notice

error Can't parse file 'system/extensions/image.php'!

in the logfile. I have the impression that the origin of this behavior is
public function detectImageInformation($fileName, $fileType = "")
in core.php. In case of the mentioned file it gives back with:1281 and height:1. That is not correct, it has 1920x1080. The issue occurs with fotos from my 3 different types of Fujifilm cameras and 2 different types of older Samsung Galaxy phones. It occurs not with photos from my HTC phones and files made with Photoshop, GIMP and Paint.net.
exiftool or Jeffrey's Image Metadata Viewer show for the Fujifilm and Galaxy files

Exif Byte Order:Little-endian (Intel, II)

and for the others

Exif Byte Order:Big-endian (Motorola, MM)

Perhaps that's the reason of the different reactions. To reproduce the issue please use the example file linked above. I'd appreciate it if my contribution helps to improve Yellow.

[schulle4u]

I can confirm the error using the provided image file. To complete the report, here is the appropriate message from apache error log (anonymiced paths and IP addresses).

[Sat Apr 09 16:11:19.825534 2022] [proxy_fcgi:error] [pid 457250:tid 140162858981120] [client [...]:8582] AH01071: Got error 'PHP message: PHP Warning:  imagecreatetruecolor(): Invalid image dimensions in /home/[...]/www/website/system/extensions/image.php on line 150PHP message: PHP Warning:  imagealphablending() expects parameter 1 to be resource, bool given in /home/[...]/www/website/system/extensions/image.php on line 151PHP message: PHP Warning:  imagesavealpha() expects parameter 1 to be resource, bool given in /home/[...]/www/website/system/extensions/image.php on line 152PHP message: PHP Warning:  imagecopyresampled() expects parameter 1 to be resource, bool given in /home/[...]/www/website/system/extensions/image.php on line 164', referer: https://website/edit/

[GiovanniSalmeri]

If the problem is in the detection of the image dimensions, some time ago I wrote a simple Lua procedure that works well with the file shared in Dropbox:

	elseif sig:match('^\255\216') then -- JPEG
		--[[
			The strategy is
			1. Loop through the markers and their lengths
			2. When a SOF marker is found, read the dimensions
		]]
		img_type = 'jpeg'
		file:seek('set', 2)
		while true do
			local start, marker, len = ('B B >I2'):unpack(file:read(4))
			assert(start == 255)
			if marker == 192 or marker == 194 then
				height, width = ('x >I2 I2'):unpack(file:read(5)) -- x = n of bits of the colour values
				break
			end
			file:seek('cur', len-2)
		end

Now I do not remember the details, but when I have some time I can compare this logic with the one in core.php:3283.

[GiovanniSalmeri]

Translated in PHP, it seems to work, but unfortunately it lacks the logic for getting the orientation of the image:

    $fileHandle = fopen("k-RJJLRQ.jpeg", "rb");
    $fileType = "jpg";

    if ($fileType=="jpg") {
        fseek($fileHandle, 2);
        while (true) {
            $values = unpack("Cstart/Cmarker/nlen", fread($fileHandle, 4));
            if ($values["marker"]==192 || $values["marker"]==194) {
                $dimensions = unpack("nheight/nwidth", fread($fileHandle, 5), 1);
                break;
            }
            fseek($fileHandle, $values["len"]-2, SEEK_CUR);
        }
        $width = $dimensions["width"];
        $height = $dimensions["height"];
        $type = $fileType;
    }

    var_dump([$width, $height]);

UPDATE: actually the orientation is in the EXIF portion, so the function getImageOrientationFromBuffer can be left untouched. Is it useful if I try to rewrite the portion of detectImageInformation which deals with JPG? Unfortunately I do not remember 😞 how I arrived to code this algorythm in Lua, so I do not know if it is really better than the one presently used.

[GiovanniSalmeri]

Just for the record and a bit OT: this is the Lua fragment for getting the dimensions of a TIFF image (I remember that I studied the TIFF specs in order to write it). Translating it in PHP is easy. If someone in ten years' time will need this, they will find it in this thread!

	elseif sig:match('^II%\42\0') or sig:match('^MM\0%\42') then -- TIFF
		--[[
			The strategy is:
			1. Set endianness
			2. At offset 4 read the address of the first block
			3. Read the number of tags
			4. Loop through the tags (each one 12 bytes)
			5. Look for types 0x0100 and 0x0101 and relative datatype
			6. When one is found, read at offset 8 in the relative datatype
		]]
		img_type = 'tiff'
		file:seek('set', 4)
		local e = sig:match('^II%\42\0') and '<' or '>' -- Luaism! It's a ternary operator
		file:seek('set', (e..'L'):unpack(file:read(4))) -- first block
		for tag = 1, (e..'I2'):unpack(file:read(2)) do -- number of tags
			local tag_type, data_type, d = (e..'I2 I2 xxxx c4'):unpack(file:read(12))
			local t = data_type == 3 and 'H' or 'L' -- short: 3, long: 4
			if tag_type == 0x0100 then
				width = (e..t):unpack(d)
			elseif tag_type == 0x0101 then
				height = (e..t):unpack(d)
			end
			if width and height then break end
		end
	end

[schulle4u]

Thanks everyone for investigating the problem. An update to the image detection code has just been published and is available in latest Core extension. The old code detected a DHT marker as SOF marker (start of frame), only SOF markers contain image dimensions.

Please give it a try and let us know should you still have problems.

[bpgs]

I've tested some of the .jpg files that caused the issue described obove. They were all uploaded correctly now.