The image quality for each possible value for the image_size parameter is set by the $thumbnail_sizes array in conf/_advanced.php (line 68).
For example, the line for the 'fit-640x480' value looks like this:

'fit-640x480' => array( 'fit', 640, 480, 90 ),

The first value in the array (fit) is the type of the thumbnail to generate, the second (640) is the width, the third (480) is the height and the last value (90) is the image quality in percent.

Tblue wrote:

The image quality for each possible value for the image_size parameter is set by the $thumbnail_sizes array in conf/_advanced.php (line 68).

Only in b2evo 3.x

@martha

What b2evo version do you use?
Did you apply the hack you linked to?

hi sam2kb,

I'm running 3.2.0-beta for this (new) site--both to scope the shape of the future (without screwing up my other sites), and with the thought that folks testing it would be helpful.

The link I gave discusses multiple possible hacks. I'm more-or-less OK with the canned SIZES given, so I didn't try them.

Here in a minute I'll try Tblue's suggestion for hacking conf/_advanced.php ... didn't realize yesterday that ALL the re-sized sizes were considered "thumbnails."

THIS time, I'm going to keep a careful record of EVERYTHING I hack outside the skins folder. But, gosh, I'd sort of hoped to achieve appropriate control without so much of that....

Quick question: if one's photos are uploaded exactly in one of the "canned" sizes, is the compression percentage nevertheless applied?

I'm running 3.2.0-beta

You should stick with Tblue's method and edit sizes in _advnced.php

I think if image size <= thumbnail size, no compression/resizing is done. You can try to make a test post just to make sure, I might be wrong.

OK, I have tried Tblue's hack of conf/_advanced.php, first using 100 for quality, then trying 20. The difference between 90 (default) and 20 should be obvious (it was just two days ago that I reduced these images to 400x600 for uploading and played with jpg quality on these images). I can't tell any difference. Tentative conclusion: this has already been applied for photos already blogged, and is not changed by changing conf/_advanced.php.

Looked at View Source in my browser. I see "evocache"; I do not see a quality after fit-640x480, but I guess that's just the name it gave the reduced-size image:

<div class="bImages"><div class="image_block"><a href="http://helioglyphs.com/blogs/media/blogs/argylestreet/willowpollen.jpg"><img src="http://helioglyphs.com/blogs/media/blogs/argylestreet/./.evocache/willowpollen.jpg/fit-640x480.jpg" alt="" title="" /></a></div></div>

Blog settings>advanced>caching is off, however; Global settings>general>caching is off. (And both have been off for entire (3-day) development of this blog.) And, yes, I manually emptied my browser cache.

So it looks like the size-and-quality change is applied once, then stored in "evocache"--and I won't know what my hack did till I either blog a new picture or somehow flush evocache.

I do not see a quality after fit-640x480

There's no 3rd param in filenames in your case, you won't see the difference.

Try to delete .evocache directory from /media/your_blog/ via FTP

OK, that worked. Deleted image name folder from two of my five images under /media/myblog/.evocache. Result--with quality set down to 20 for testing: blocky, smeary, just like you'd expect. Which means that conf/_advanced.php hack is working, I just need to go change it again to a quality I want, then delete image folders from evocache.

(We've also learned that the file name given to the resized image does not include the quality parameter in a way that shows up in--what would you call it--the generated code of View Source.)

But, oh!, for a way to do it without all the hacking! This issue is maybe trivial for people wanting to blog pictures of their friends or vacation, but I'm putting up a site parts of which will eventually try to sell photographic prints ... so the QUALITY needs to impress, while unauthorized re-use is limited by uploaded size... Or, a serious photoblog skin brings new issues.

Anyway: thanks sam2kb and Tblue--looks like I've got THIS issue satisfactorily resolved (if not ideally, in terms of no-hack process).

No problem ;)

Ooops, I spoke too soon!

In media/myblog/.evocache, I deleted the folders I found (which I couldn't open with the ftp connection), one named for each image. I EXPECTED they would be regenerated when b2evo had to do the re-sizing dance again. But media/myblog/.evocache remains empty--and the images load more slowly.... That wasn't what I wanted, I hoped to replace the old cached images with new ones!

I tried turning on caching in Blog Settings and Global Settings and then paging through the blog online, hoping that would cause it to re-generate these files. It speeded up presentation time, but media/myblog/.evocache was still empty. (Have turned caching OFF again in these two places, as I need to know what I am doing.) These two admin switches don't seem to control media/.../.evocache.

???

I tried turning on caching in Blog Settings and Global Settings

These settings have nothing to with .evocache folders

and the images load more slowly

Only for the first time you access them, because image thumbnails are generated

That wasn't what I wanted, I hoped to replace the old cached images with new ones!

If you see the resized images it means that .evocache dirs and thumbnails were successfully generated, and you can check it in your browser:

yoursite.com/media/blogname/image.jpg
yoursite.com/media/blogname/.evocache/image.jpg/fit-AAAxBBB.jpg

or

yoursite.com/media/blogname/very/long/path/image.jpg
yoursite.com/media/blogname/very/long/path/.evocache/image.jpg/fit-AAAxBBB.jpg

Can you post a link to your site?

Well, I think they have regenerated. When I posted my "Ooops" message, I had seen the (slower but good) results in the blog and then visited media/myblog/.evocache with my ftp client (fetch) and they weren't showing there yet, don't know why.

They show up now.

Haven't got a front page for this yet, or my blog urls sorted out, but http://www.helioglyphs.com/blogs/blog4.php will get you there.

Thanks for all your help. I once again think this is working OK.

martha wrote:

(We've also learned that the file name given to the resized image does not include the quality parameter in a way that shows up in--what would you call it--the generated code of View Source.).

Not played with 3.beta, but 3.cvs uses quality as part of .evocache filename and the cached version of any size should be rebuilt whenever there's no cached version.

you can also make the sizes/quality an admin "skin setting" ;)

With a smidge of dicking around in your skin you can also have custom size/quality, and have those cached

¥

"¥åßßå" wrote:

you can also make the sizes/quality an admin "skin setting" ;)

Well, OK: how?

I don't know if this works in 3.beta as I only have 3.cvs installed, but, crack open skins/custom/_skin.class.php and make teh following changes :

	/**
   * Get definitions for editable params
   *
	 * @see Plugin::GetDefaultSettings()
	 * @param local params like 'for_editing' => true
	 */
	function get_param_definitions( $params )
	{
		global $thumbnail_sizes;
		$available_sizes = array();
		foreach( $thumbnail_sizes as $name => $values )
		{
			$available_sizes[$name] = $name;
		}
		$r = array_merge( array(
				'image_size' => array(
					'label' => T_('Image size'),
					'note' => T_('How big should images be?'),
					'defaultvalue' => 'fit-400x320',
					'type' => 'select',
					'options' => $available_sizes,
				),
				'head_bg_color' => array(
					'label' => T_('Header Background Color'),
					'note' => T_('E-g: #ff0000 for red'),
					'defaultvalue' => '#78a',
					'valid_pattern' => array( 'pattern'=>'¤^(#([a-f0-9]{3}){1,2})?$¤i',
																		'error'=>T_('Invalid color code.') ),
				),

Then crack open /skins/custom/_item_block.inc.php and make the following change :

if( !defined('EVO_MAIN_INIT') ) die( 'Please, do not access this page directly.' );

global $Item;

// Default params:
$params = array_merge( array(
		'feature_block'   => false,
		'content_mode'    => 'auto',		// 'auto' will auto select depending on $disp-detail
		'item_class'      => 'bPost',
		'image_size'	    => 'fit-400x320',
	), $params );

	$params['image_size'] = $Skin->get_setting('image_size');
?>

Now, meander into admin and change your skin to the custom skin. If you wander over to admin > blog settings > [blog] > skin settings ... you should see a dropdown of all the available sizes, choose the one that suits and press save

I'm currently working on a way to have custom image sizes in a skin but it's being a bit of a bitch

¥

Hmm, looks like I may wait to see what you folks put together for 3.*-stable....

I made changes suggested. With my blog and most of admin displaying correctly, BEFORE changing from my modified Photoblog skin to Custom skin, blog settings >skin gets a string of error messages instead of display of skins to choose:

Notice: Undefined variable: params in /home2/wordturn/public_html/helioglyphs/blogs/skins/custom/_skin.class.php on line 23

Warning: array_merge() [function.array-merge]: Argument #2 is not an array in /home2/wordturn/public_html/helioglyphs/blogs/skins/custom/_skin.class.php on line 23

Notice: Undefined variable: Skin in /home2/wordturn/public_html/helioglyphs/blogs/skins/custom/_skin.class.php on line 25

Fatal error: Call to a member function get_setting() on a non-object in /home2/wordturn/public_html/helioglyphs/blogs/skins/custom/_skin.class.php on line 25

So, I'm changing files in custom back to what they were....

Being able to do this would be handy but not essential to my enterprise just now. I'd rather you spend your efforts getting it to work for the next release than troubleshoot my results, as I really do think it would be useful for many. Thanks for your generous help on this, however!

mlt

Ahhh, sorry, looks like $Skin may be a 3.cvs thing ... it'll be in 3.rc1 though. The rest of the errors are generated for a similar reason.

With a tad of luck rc1 should be released soon ;)

¥