Hello,

If the original image is 5000KB and the crop area in not touched, these two files are created in the files folder:
5000KB example.jpg
5000KB example.jpg.crop_display.jpg

If the crop area is re-sized even just a little, the imagefield crop works properly:
382KB example.jpg
5000KB example.jpg.crop_display.jpg

If the user likes the original picture as originally uploaded, I still would like the image to rescale. Is this possible?

Thanks!

Comments

dawehner’s picture

I can reproduce this too, sadly not in a generic way.

Bilmar’s picture

Hello,

I didn't realize this was happening but I came across this issue thread and I use this module a lot so tested it out.
I found in my sites/default/files folder that this has happened a lot before (!) but testing now I wasn't able to reproduce =(

I tried:
-Adding an image at node edit
-Without touching the cropping tool pressing Save
-Checked the sites/default/files folder for the .jpg and .jpg.crop_display.jpg images

Maybe this issue has been fixed in the latest dev (2010-Apr-26)?
Or its an issue that happens sometimes? Or an issue that happens on a specific case.
I hope this can be looked into.

Many thanks!

greggles’s picture

Perhaps it happens if the user doesn't click "upload" on the imagefield and instead just "Saves" the node?

YK85’s picture

Hi greggles,

The steps was browse, select image, upload (so the preview and crop area shows the image), save (without touching the crop area).

Thanks!

mrfelton’s picture

I think I have the same problem, only what happens i that I get left with a solid black image the size of the final crop. If I select a crop, it's ok, If I select no crop then I have this problem.

I can recreate this problem easily.

1) Upload an image
2) select a crop
3) save the node
4) edit the node
5) remove the crop (simply clicking within the crop area, but not dragging)
6) save the node

What you get left with is some random crop - it is not the crop that I made in step 2, and it is no no crop, which I would expect by removing the crop as in step 5. The reason the resulting image showed up as a solid black area in my case was because the image I uploaded had a lot of solid black in it, and this random crop was basically selecting an small area of sold black and scaling it up to fill the final crop size.

So, clearly there is something wrong with the handling in the case that no crop is selected.

stevenyeung’s picture

is there any workaround to resolve this issue before a patch is coming?
maybe adding a css style to force the image to resize?

subscribing~

Tony Sharpe’s picture

I'm also getting this - image is not cropped. My original and final image are square with the original 85 x 85 and the final supposed to be 70 x 70. I do exactly as in post #4. If I adjust the crop area slightly then it gets cropped OK.

chuckbar77’s picture

Priority: Normal » Major

bumping this to major - hoping it will get attention

If a user doesn't click the cropping box, the original image is saved and not a cropped image.

Please help fix this issue.

Regards

YK85’s picture

i'm still experiencing this as well with latest dev

Fidelix’s picture

This is happening to me too...

I'm not sure whats happening...

rfarm’s picture

same problem and looking for a solution

balintbrews’s picture

I have exprerienced the same issue, but I can not reproduce it correctly.
I think, the relevant lines are these: (in function imagefield_crop_widget_process())

<?php
  if ($field['widget']['resolution']) {
    list($w, $h) = explode('x', $field['widget']['resolution']);

    // ratio is zero when not enforced
    $ratio = $field['widget']['enforce_ratio'] * $w/$h;
  }
  else {
    // no output resolution requested
    $ratio = 0;
    $w = $h = 0;
  }

  // ...

  if (!empty($file) && 
      is_file($file['filepath']) &&
      (list($width, $height, $type, $image_attributes) = @getimagesize($file['filepath']))) {

    if ($field['widget']['enforce_ratio']) {
      $image_ratio = $width/$height;
      
      // ...

      // if the enforced ratio is different, force crop
      $defaults['changed'] = ($ratio != $image_ratio);
?>

And the last line is the key. When the problem occurs, the reason is, $ratio == $image_ratio, so the original image ratio equals the crop ratio. This is what I can reproduce easily, when I choose an image which has the same ratio as the configured resolution to crop. But it seems like that this condition will be true in other cases.

cburyta’s picture

I'll second that comment on the last line being the issue. I had the same issue, where only the crop_image would not be created. Changing the line to make sure $defaults['changed'] always equals true seemed to fix the problem I was having.

ih2502mk’s picture

I had an issue that can be related to ones described here.
I have a node with image of size let's say 1200x800px and it is cropped with box of next dimensions: x = 100px, y = 100px, width = 300px, height = 500px.
Then I edit this node and remove big image and upload a new small one 120x120px and DON'T TOUCH CROPBOX. After saving a node I will have image with dimensions: 300x500px (like old crop area) which will look like piece of new small image 20x20px and big black area.
The problem here is that hidden inputs that contain crop data are not updated properly after uploading a new image. And this problem is in javascript particularly in imagefield_crop.js.
Jcrop is called with setSelect option and Jcrop itself handles exceeding cropbox but it does not call onSelect callback, so hidden inputs are not repopulated with new proper cropbox dimensions. But onChange is called while Jcrop handles exceeding cropbox. Quick solution to this would be copypasting body of onSelect callback to the end of onChange callback.
So imagefield_crop.js starting from line 24 would look like:

        onChange: function(c) {
          var preview = widget.parent().find('.widget-preview');
          // skip newly added blank fields
          if (undefined == Drupal.settings.imagefield_crop[id].preview) {
            return;
          }
          var rx = Drupal.settings.imagefield_crop[id].preview.width / c.w;
          var ry = Drupal.settings.imagefield_crop[id].preview.height / c.h;
          $('.jcrop-preview', preview).css({
            width: Math.round(rx * Drupal.settings.imagefield_crop[id].preview.orig_width) + 'px',
            height: Math.round(ry * Drupal.settings.imagefield_crop[id].preview.orig_height) + 'px',
            marginLeft: '-' + Math.round(rx * c.x) + 'px',
            marginTop: '-' + Math.round(ry * c.y) + 'px'
          });
          $(".edit-image-crop-x", widget).val(c.x);
          $(".edit-image-crop-y", widget).val(c.y);
          if (c.w) $(".edit-image-crop-width", widget).val(c.w);
          if (c.h) $(".edit-image-crop-height", widget).val(c.h);
          $(".edit-image-crop-changed", widget).val(1);
        },
        onSelect: function(c) {
            $(".edit-image-crop-x", widget).val(c.x);
            $(".edit-image-crop-y", widget).val(c.y);
            if (c.w) $(".edit-image-crop-width", widget).val(c.w);
            if (c.h) $(".edit-image-crop-height", widget).val(c.h);
            $(".edit-image-crop-changed", widget).val(1);
        },
scothiam’s picture

#13 worked for the initial problem, but does not work for all images thereafter...

could someone verify solution #14? I'm testing locally, but would feel better rolling this out to production with some more feedback... or even better, an endorsed fix from the maintainers ;)
cheers,

niklasb’s picture

I had issues with the crop form not cropping, and applying both #13 + #14 worked for me. Didn't have the time to investigate further, all I can say is that it didn't work and when I applied the patches it did.

greggles’s picture

@niklasb: Thanks for that information. Could you provide the changes as a patch?

anrkaid’s picture

StatusFileSize
new2.26 KB

Patch from #13 and #14 attached

ttapada’s picture

patch worked perfectly for me, thanks.
(I've applied it manually, though, couldn't say if it would be properly applied if applied in the proper way...)

ttapada’s picture

Actually, the original posted problem (not resizing if crop area untouched), but it seems that crop doesn't work anymore...
Altough the preview shows me the result of cropping, the result is always the same as the full image but resized...

Can anyone confirm?

I'll try to revert the patch and see if it was the patch that broke cropping altogether.

EDIT: yes, it was... The patch seems to break cropping, as the result does not match the preview.

EDIT 2: ok, I've just determined that the problem was due to the fact that I have a hierarchical select on the node form and everytime and select something, the crop area is reset to the entire image - that's why the result was not what I expected.