We absolutely need:

piwigo_images.width
piwigo_images.height

They are used for
- computing the derivative size
- choose an appropriate smaller derivative or the original. The algo is still incompletely implemented but suppose that you have an orginal situated somewhere between medium and large:

if we need rotation or watermarking then
  large will be large (but no scaling); xlarge and xxlarge will map to large
else
  large, xlarge and xxlarge will map to the original (SAME_AS_SRC in the code)

Concerning the .filesize, yes we can keep it ...

And by the way because I hate too many xxx-database.php, would you mind adding:

'ALTER TABLE '.USER_INFOS_TABLE.' DROP COLUMN maxwidth, DROP COLUMN maxheight'
'ALTER TABLE '.IMAGES_TABLE.' ADD COLUMN coi varchar(4) DEFAULT NULL COMMENT \'center of interest\' AFTER width'

plg wrote:

We have to discuss about the default values for dimensions on sizes. In my opinion they are too small.

what about
small 288 x 288
medium 504 x 504
large 864 x 648 or 936 x 648
xlarge 1224 x 864
xxlarge 1536 x 1080
(note always multiple of 72)

plg wrote:

And maybe that with larger dimensions, your algorithm needs an update also.

Which algo you are talking about ? The one above ? What update ?

ImageStdParams::make_default();
$types = ImageStdParams::get_defined_type_map();

$size = array($conf['upload_form_thumb_maxwidth'], $conf['upload_form_thumb_maxheight'])
$thumb = new DerivativeParams(
  new SizingParams( $size, $conf['upload_form_thumb_crop'] ? 1 : 0, $conf['upload_form_thumb_crop'] ? $size : null)
  );
$thumb->quality = $conf['upload_form_thumb_quality'];
$types[IMG_THUMB] = $thumb;
// same for websize -> large
// todo (painful) make sure ideal size of thumb/large is between square-small/medium-xlarge
ImageStdParams::set_and_save( $types );

follow_orienation cannot be put here - it's going to be complicated see my post [Forum, post 126678 by rvelices in topic 18570] Multiple-size

I would like to commit things I have added today but I would also like to have a clean upgrade on follow_orientation, so I'll first commit the new parameters original_resize* and I'll see later about removal of obsolete parameters.

I'm working on the upgrade script. The one that moves the 2.3 HD into 2.4 original. As long as Piwigo doesn't perform any "copy" but only "move", the script runs pretty fast: 500ms for 10k HD photos.

To avoid any problem during upgrade, I will provide the operation "remove pwg_high and thumbnail directories" in a separate plugin. This operation can be long, depending on the disk performances. I don't want to take the risk to fail an upgrade for a non blocking operation (keeping the "thumbnail" directories in "upload" is not a problem)

In addition to moving (overwritting) files, the script updates the images.width, images.height and images.filesize based on images.high_width, images.high_height and images.high_filesize (which are removed).

$upgrade_description = 'derivatives: new organization of "upload" and "galleries" directories';

$query = '
SELECT
    id,
    path,
    tn_ext,
    has_high,
    high_filesize,
    high_width,
    high_height
  FROM '.IMAGES_TABLE.'
;';
$result = pwg_query($query);
$starttime = get_moment();

$updates = array();

while ($row = pwg_db_fetch_assoc($result))
{
  if ('true' == $row['has_high'])
  {
    $high_path = dirname($row['path']).'/pwg_high/'.basename($row['path']);
    rename($high_path, $row['path']);

    array_push(
      $updates,
      array(
        'id' => $row['id'],
        'width' => $row['high_width'],
        'height' => $row['high_height'],
        'filesize' => $row['high_filesize'],
        )
      );
  }
}

$endtime = get_moment();
$elapsed = ($endtime - $starttime);
echo sprintf('%.3fs to move HD', $elapsed);

if (count($updates) > 0)
{
  mass_updates(
    IMAGES_TABLE,
    array(
      'primary' => array('id'),
      'update' => array('width', 'height', 'filesize'),
      ),
    $updates
    );
}

Remaining operations are :

* removing columns images.high_width, images.high_height, images.high_filesize, images.tn_ext, images.has_high, user_infos.maxwidth, user_infos.maxheight
* converting 2.3 thumbnails/websize settings into 2.4 derivatives settings
* update upgrade task 113 to convert config params upload_form_hd* into original_resize*
* removing configuration parameters upload_form* (14 parameters)

[Bugtracker] ticket 2632

* 122-database.php organizes "galleries" and "upload" folders
* 123-database.php converts Piwigo 2.3 resize settings into Piwigo 2.4 derivatives settings
* 124-database.php cleans the database (configuration settings and table columns)

flop25 wrote:

there might be a problem about cropping : the size for thumbnails were successfully imported but thumbnails become cropped

Do you have a backup of your database? can you perform a:

select param, value from piwigo_config where param like 'upload_form%';