hmmm....

Apparently images over a certain width/height don't get thumbnailed. They came off the camera at 3648 by 2736 and roughly 2.4 megs. No evocache folder, no thumbnails, no error messages. Resizing down to 355 wide (and some puny little file size of course) then uploading triggered an evocache folder and a thumbnail. So I took an image at 3648 wide and saved it with compression so that it was 1.9 megs: no thumbnail. I then resized one to 2048 wide and minimum compression so I got a 2.1 meg file size: thumbnail.

So the image width and height seems to be a limiting factor somehow for some reason.

Anyone know why? Anyone know what can be done about it?

From a quick glance at the core I can't see anything obvious that would cause that.

Longshot : Try increasing your memory limit in conf/_advanced.php and seeing if the max width/height changes

¥

// Try uncommmenting the following line:
// ini_set( 'memory_limit', '32M' );

Probably not it due to I'm not getting blank pages and my memory limit per phpinfo is at 32M. Plus I just installed wordpress and figured out how it's plain jane image handler works and it managed to make a smaller version of a full size file. So that kinda says my server is okay with making little ones out of big ones.

The only other memory thing I see in conf/advanced is

$upload_maxmaxkb = 10000;

Doesn't seem related?

Interesting observation by the way: when my back office setting limited me to 4096K, that limit applied to the TOTAL of what was getting uploaded via the "use advanced stuff so you can upload more than one file" feature. I increased the back office to 8192K so I could upload 3 images at one time ... and therefore never actually got near the $upload_maxmaxkb value of 10000. I wonder when this one kicks in?

oops. I am getting an error message when doing the "Make posts" thing. Didn't notice it before because I uploaded all the images, selected them all, clicked "make posts" then launched all the "publish now" links in new tabs.

Notice: Trying to get property of non-object in /path/inc/_core/model/dataobjects/_dataobjectcache.class.php on line 283

Line 283 is the last line of this little bit:

	function & instantiate( & $db_row )
	{
		// Get ID of the object we'ere preparing to instantiate...
		$obj_ID = $db_row->{$this->dbIDname};

EdB wrote:

Probably not it due to I'm not getting blank pages and my memory limit per phpinfo is at 32M.

Be interesting to see if 64M would cure it ;)

EdB wrote:

The only other memory thing I see in conf/advanced is

$upload_maxmaxkb = 10000;

Doesn't seem related?

From the brief look I had, image size ( file / width / height / whatever ) doesn't effect .evocache or thumbnail .... and I'm guessing that thumbnail is made via the <img src=""> bit, in which case you wouldn't see a php error ( just a failed image )

EdB wrote:

Interesting observation by the way: when my back office setting limited me to 4096K, that limit applied to the TOTAL of what was getting uploaded via the "use advanced stuff

If I ever get round to recoding files stuff, it uploads asynchronously ( urm, 1 post per file, not 1 post for all files ), so that limit would then represent reality ... based on the evo reality that's in force at any given moment

¥

Okay that's weird. 64M worked ... but wordpress did it with that setting commented out (phpinfo telling me it was 32M). Just to get detailed about it, 56M did not work but 60M worked. I then set it to 64M and left it there.

Anyway so now I got thumbnails. Oh and I manually created the .evocache folder but it doesn't seem to mind given that it made it's poorly named folders with it's poorly named thumbnail files.

So I clicked 'select all' and told it "Make posts" - with our "Make posts as drafts" hack installed. It told me it made 12 posts AND gave me the line 283 error again.

Notice: Trying to get property of non-object in /path/inc/_core/model/dataobjects/_dataobjectcache.class.php on line 283

So I deleted all the posts and tried again. Second time around it did not throw the error and all the drafts turned into posts without issue.

Mission accomplished - thanks!

It would seem odd that it bombs out quite that badly though, a 32M increase is a fair whack.

The notice is probably sparked off by something your hack is trying to do ( empty $Item or summat ? ) ... How many drafts should there have been ?

¥

12 drafts, one image each (as is the nature of the Make posts feature).

I built an unmodified installation and duplicated the initial problem, but didn't play in that sandbox for the duration. I'll go back to 32M and that installation later, and see what happens with making a single post from a single image. Then let you know what happens.

EdB wrote:

12 drafts, one image each (as is the nature of the Make posts feature).

Was the error after the 12th image ( ie/ erroring on a "13th" image or summat? ) ?

Still bugged that a 3.xMb image requires a 32Mb memory increase though

¥

Memory limit is the default value of 32M.

Using the quick upload feature, I uploaded a single image of 3648 by 2736 pixels at roughly 2.4 megs. The image uploaded successfully, but I did not get an evocache folder or a thumbnail. When I then did the Make posts thing with this single image it generated no error messages, but also did not actually create the images for either the post viewer or the actual blog post. (this is kinda given due to how it still doesn't have an evocache folder but hey details is details).

I then deleted the post and the image because I wanted to try the same thing with the following line uncommented out

ini_set( 'display_errors', 'on' );

For better or worse, the process repeated exactly the same: upload without error but also without evocache folder or thumbnail, posting happened without error but also without either of the resized images it should make.

So next I went to discover how much memory increase it needed to handle a single image. Knowing that 56 failed and 60 worked, this time I went from 56 to 58 and found that 56 fails and 58M works. TMI? Anyway I then set it back to 32M for the next phase of this experiment. Oh and commented out the "display_errors" bit again.

aw crap that wasn't supposed to go yet. doh!

PHP does a lousy job handling images. It needs to load the image into memory only to calculate it's sizes. That is before making a thumb. But 32M is way to much to explain it that way and blame 'only' PHP.

@Afwas: plus when it is set to 32M wordpress is capable of handling a single image uploaded when posting, which seems to be the only way to upload images in that application.

@¥åßßå: the error message must be due to your portion of my hack ;) Doing Make posts with 3 images simultaneously did not throw the error in the unmodified installation.

----------------------

I suppose I could set my camera to the next size down, but when I saw 2.4 megs and a 2gig memory card I figured no problem and let it do whatever size it chose to do. Now seeing this issue I'm inclined to tell it to make smaller pictures ... although I obviously have a solution at hand.

----------------------

Time to delete out the disposable installation and start playing with photoblog more. Like, when editing an images properties how come it doesn't show me the thumbnail? That'd make handling many images at the same time quite a bit easier eh? And how come the first thumbnail is shown last? That aligns with how blogs work (latest is the top or first) but doesn't align with how taking pictures work (latest is last or the end).

I wish it would rain hard so I can take pictures of a lake.

EdB wrote:

@Afwas: plus when it is set to 32M wordpress is capable of handling a single image uploaded when posting, which seems to be the only way to upload images in that application.

How about playing with the files class and seeing if that number changes? ( inc/files/model/_file.class.php approx 1718 ) :

		// Try to output the cached thumbnail:
		$err = $this->output_cached_thumb( $size_name, $mimetype );

		if( $err == '!Thumbnail not found in .evocache' )
		{	// The thumbnail wasn't already in the cache, try to generate and cache it now:
			$err = NULL;		// Short error code

			list( $err, $image ) = load_image( $this->get_full_path(), $mimetype );
			if( empty( $err ) )
			{
				list( $err, $image ) = generate_thumb( $image, $thumb_width, $thumb_height );
				if( empty( $err ) )
				{
					$err = $this->save_thumb_to_cache( $image, $size_name, $mimetype, $thumb_quality );
					if( empty( $err ) )
					{	// File was saved. Ouput that same file immediately:
						// This is probably better than recompressing the memory image..
						$err = $this->output_cached_thumb( $size_name, $mimetype );
						imagedestroy( $image );
					}
					else
					{	// File could not be saved.
						// fp> We might want to output dynamically...
						// $err = output_image( $dest_imh, $mimetype );
						imagedestroy( $image );
					}
				}
			}
		}

EdB wrote:

And how come the first thumbnail is shown last?

Try playing with this section of code ( inc/files/files.ctrl.php approx 483 )

// Sort Filelist
param( 'fm_order', 'string', NULL, true );
if( ! in_array( $fm_order, array( 'name', 'path', 'type', 'size', 'lastmod', 'perms', 'fsowner', 'fsgroup' ) ) )
{
//	$fm_order = NULL;
$fm_order = 'lastmod';
}
param( 'fm_orderasc', '', NULL, true );
if( empty( $fm_orderasc ) )
{
  $fm_orderasc = 'ASC';
}
$fm_Filelist->sort( $fm_order, $fm_orderasc );

¥

Regarding the change to _file.class.php: same thing - it took 57M to finally create an evocache folder and a thumbnail of a single 2.4 meg image. Hey here's a funny thing that happened: first I didn't increase the allowable size of uploaded material, so of course it rejected the upload. The funny part is that it takes the time to upload it first so it can decide if it is allowed to upload it or not. :roll:

The second code bit didn't work either. I ended up changing the order in the query that gets built in _mediaidx.disp.php. Eventually I'll refine it a bit more so that it shows the newest set of photos on top (for me a set of photos will be a category, and each new set will have a new category name), but the oldest thumb in any given set first. That type of structuring won't work for everyone, but for my uses of a photoblog it'll do.

Let me know if you want me to tinker on other stuff regarding the amount of memory required because this time I'll keep my "mostly stock" installation alive as a playground.

Hmmm ... guess that's gonna take a deeper look.

The upload thing is kinda an "any server language" *bug* ... they have to upload a file before they can see how big it is and tell it to sod off if it's to big ..... ish

I think I may have misunderstood your second requirement, I thought you meant the view in the filemanager ? ... of course, it'd help if I'd ever experienced mediaidx.disp.php ... I assume that's in the skins folder somewhere?

I'll have a play around the file.class.php and see if I can see where/why it's guzzling this memory ... might take me a tad though, so your playground may get a smidge dusty :p

¥

Yeah on the order thing I was thinking of the public side. mediaidx.whatever makes a table full of thumbnails from images posted in the photoblog. In fact just now I wonder how it knows which blog is a photoblog but that don't matter much at the moment.

No worries on the timing of things regarding memory usage troubleshooting. I'll keep it there and add ONLY my "you can't get my server info" hack to it. Plus whatever you think might be good to play with. hmmm... it dawns on me that maybe the actual image manipulation stuff isn't the memory hog. Like, suppose it is the memory that the rest of the core is using that results in the image resizing stuff to appear to need more?

Slightly related: I'm thinking there are generally two distinctly different types of photobloggers. One is the event-driven sets of photos, and the other is the category-driven individual photos. The first would feel more right if it acted like a traditional photo album - first shot first and so on. Currently that's not how it works ... and happens to be how I see me using a photoblog. The second would be quite comfortable with the mediaidx.thing as is because it aligns nicely with the basic idea of a blog. Oh well. Just thinking out loud I guess. I should start thinking on a realtors plugin. You have no idea how much money realtors will waste on "web services" that amount to "I make you a static web using a boring template and you pay me". Yeah ... I'd totally hit on that revenue stream ;)

Things that make me think it's a "core hog" ( just speakin' the img bit ) ... 32 meg increase just to process a ( comparatively ) tiny image would mean that the core would need : memory increase - ( size of image + image library overheads ) .... 32Mb huh?

Things that me think "not core" is ... in one incarnation, my gallery plugin "built" detail / thumb images of files in a given folder. I'm "pretty" sure that my code freed memory where it could, but it still tilted given a big enough image ( 5Mb+) or enough "smaller" images ( 3.xMb ) .... having said that, I just doubled mem to 64Mb ... didn't bother to see "where" it failed

slightly related ... there's a 3rd set of photo bloggers ... those that just want to shove a load of "didn't I take some cool pics?" images in a post ... preferably in the location of their choice in the post

I should so chase realtors ... assume they're summat similar to an estate agent? ... although I'd probably end up being sold a bloody house I don't want :p

¥