Calling image_load() on image file entities is expensive since it has to make a call to getimagesize() for GD. We made a huge mistake in core by adding the height and width attributes for image files into the field schema itself, rather than adding that data into an {image_dimensions} table that could be easily joined onto the {file_managed} table for saving and then loading into a file entity via hook_file_load(). The moment we want to make file entities re-usable and reference-able, we currently have to re-call image_get_info() rather than being able to rely an reusable data.

Comments

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

Related issue in the Media and File entity projects: #1447790: image_load makes admin/content/media unusably slow

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

Original issue: #908282: Remove unnecessary I/O from theme_image()

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Issue tags: +sprint
yang_yi_cn’s picture

yang_yi_cn CreditAttribution: yang_yi_cn commented

#1345744: cropped image has incorrect metadata width and height in imagefield is related.

For those don't have time to look over, the issue summary is:

The imagefield_crop module crops the original image file and updates the file correctly.

However, in #file_value_callback it can only update the fid related data which is in the {file_managed} table, thus the width / height in the image field instance table would never be updated.

Causing problems whenever try to use the "Original image" display.

markconroy’s picture

markconroy CreditAttribution: markconroy commented

has this issue been sorted? It's quite frustrating to use image preset "small-image" set to scale to 120px, then update the preset to 133px (for example) because that fits better with the content region dimensions for a particular theme, but the image dimensions stay the same (with the result being a pixellated image).

In more detail:
http://drupal.org/node/1786488

Mark C.

familymangreg’s picture

familymangreg CreditAttribution: familymangreg commented

Hi all,

Would be pleased to know a work around or the status of a fix to this issue. Having a few days at the moment where I'm getting really frustrated with Drupal. On the forums so much investigating and reporting issues which seem to often fall back to a core update.

I'm having the problem with 7.15. Images are cropped to the correct size, but output as original they have the wrong (or original dimension) in the image tag when output.

Its annoying because I've used image and cropping on upload so much in the past and never had this issue.

Cheers,
:wq

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented

Regarding imagefield_crop shouldn't it just have extra hook implementations to update the table accordingly? Is there an API limitation as to why this isn't possible?

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
CreditAttribution: klonos commented

...I was (re)reading File management (File entity in core) and FMI roadmap (where this issue is listed as part of "Phase 2") and was wondering if there is a meta issue for this somewhere I'm missing. Can we please get a status update?

Thanx in advance.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Priority: Normal » Major
Issue summary: View changes
Issue tags: -sprint

I think we should promote this to major as it would affect core schema. Not having image dimensions attached to the file entities themselves causes so much more work and additional performance/resources for other modules that need that information, but not in a field-context.

mikeytown2’s picture

mikeytown2 CreditAttribution: mikeytown2 commented

Sorta related as this deals with file I/O on images: #2289493: image_get_info always populates file_size, even if already set.. Also the latest version of https://www.drupal.org/project/imageinfo_cache has an option to cache image_get_info so no file I/O is done; if the linked core patch has been applied.

cilefen’s picture

cilefen CreditAttribution: cilefen commented
Issue tags: +Performance
Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid as a volunteer commented
Issue tags: +D8Media

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm at Acquia commented

From a discussion thread on this issue.

@catch wrote:

This is closely linked to file entities vs. not. I'm not sure how it can be an entity property on files when most file types don't have dimensions though.

@effulgentsia wrote:

If/when we have bundleable file entities, height and width can be added as code-defined bundle fields to the bundles for which that makes sense. I don't know if we want to explore a (hacky) solution before then.

@Dave Reid wrote:

Well how file_entity handles it it goes into a generic key/value store. Images can store height/width/exif data, videos can store height/width/bitrate, etc.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

vijaycs85’s picture

vijaycs85
Location London, UK
CreditAttribution: vijaycs85 as a volunteer and at TATA Consultancy Services, Solathat for Pfizer, Inc. commented

In core, we have media source (see Drupal\media\Plugin\media\Source\Image) plugin per type with meta attributes. I believe the issues have been addressed almost close to forecast solutions in #14. Could we close this issue?

vijaycs85’s picture

vijaycs85
Location London, UK
CreditAttribution: vijaycs85 as a volunteer and at TATA Consultancy Services, Solathat for Pfizer, Inc. commented
Status: Active » Closed (outdated)

Closed? we can open back, if we really have to.