Use JCrop for cropping.

[GoogleCodeExporter]

The 'edit' button could also allow some basic image manipulation by the user. 

Original issue reported on code.google.com by andybak on 14 Jun 2009 at 9:15

[GoogleCodeExporter]

we had that discussion many many times. with an earlier version of the 
filebrowser,
one could use picnik/snipshot for image manipulation.
but, none of our users ever did that - so we finally removed that feature.

if we start with implementing a cropping-functionality, we also need to rotate 
the
image, change width/height and so on. IMHO, the question is simply whether or 
not to
use picnik (since snipshots functionality is very limited).

I´m -1 on this feature, but comments and other opinions are welcome.

Original comment by sehmaschine on 14 Jun 2009 at 9:33

[GoogleCodeExporter]

Original comment by sehmaschine on 14 Jun 2009 at 9:35

• Changed state: Discussion

[GoogleCodeExporter]

Original comment by sehmaschine on 14 Jun 2009 at 9:36

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Can consider the use of HTML5, 
because it is a management interface in the background，
so that the administrator using a standard browser,
Can not be considered to support non-standard browser,
This also helps to promote the WEB standard。

not recommend the use of a picnik/snipshot。

Original comment by gnu...@gmail.com on 15 Jun 2009 at 12:33

[GoogleCodeExporter]

Any idea why no-one used piknik?
Not sure how the piknik integration works. Was any of their branding visible in 
the
interface? If so this would be a problem for many.

But why is piknik the only approach being considered when we have already got 
PIL on
the server side. Combining that with a client-side widget such as JCrop for 
actually
choosing the crop dimensions would be a self-contained solution.
And if we did need to support resize and/or rotation (if we really do need 
rotation)
then these would be a trivial addition to the interface.

Original comment by andybak on 15 Jun 2009 at 7:56

[GoogleCodeExporter]

about the picnik-issue: the feedback was that they preferred to use photoshop 
(or
something similar), because a) picnik is way too slow and b) they wanted to 
have more
control/possibilities.
for a personal blog, it might be ok to use picnik for image-modifications. for a
professional website, I personally don´t recommend it.

about doing custom image-editing using PIL: absolutely possible. if someone 
comes up
with a decent (!) tool to crop/resize/rotate images, I´m +1 on implementing 
that.
unfortunately, I´ve never seen something like that so far. with jcrop (for 
example)
it´s not possible to enter values for the new size ... I don´t know if 
that´s easy to
add, but currently it´s not there. one reason why people absolutely refused 
using
snipshot was, that they couldn´t enter values (for cropping/resizing images).

@gnugit: I don´t understand how your comment is related to this discussion. 
could you
be more specific?

Original comment by sehmaschine on 15 Jun 2009 at 8:11

[GoogleCodeExporter]

I personally would use Photoshop but I am looking for a solution for my 
clients. They
don't tend to have any images editing software that they know how to use so I 
need a
way for them to handle simple tasks.

Ideally the resizing would be done on the client to reduce upload time but this 
would
require the use of Yahoo BrowserPlus or some rumoured upcoming image APIs in 
Google
Gears.

gnugit seems to imply this could be done with HTML 5. I can imagine writing
Javascript background threads to manipulate binary files but that would be 
horrific
on large images. Is there a better way that's already supported in recent 
browsers?  

Original comment by andybak on 15 Jun 2009 at 8:18

[GoogleCodeExporter]

I might start working on a patch in a couple of weeks. Where do you see it 
fitting in
to the interface?

The 'edit' button is already used for renaming files which I think is a little
unusual. I don't know what the correct icon for 'rename' is but I don't think 
an edit
icon is intuitive.

Should we have a new button for image editing or could we consider reusing the 
edit
button and coming up with a different interface for renaming? 

Original comment by andybak on 15 Jun 2009 at 8:20

[GoogleCodeExporter]

I´d go with your suggestion and use the "edit"-button. we´ll find a different 
icon
for "rename". if you´re doing a patch, just use the edit-button twice - I´ll 
change
that afterwards.

I might be to harsh about this issue, but: if someone doesn´t have an 
image-editing
software, they shouldn´t do image-editing at all from my point of view 
(because they
probably don´t know what they´re doing). of course, I don´t know your
clients/requirements and online-image-editing might be useful in some special 
cases.

Original comment by sehmaschine on 15 Jun 2009 at 8:30

[GoogleCodeExporter]

Here's some typical use cases for non-technical users:

1. Removing white space around images that they have been asked to upload
2. Resizing huge images from digital cameras
3. cropping unwanted parts of an image.

None of these particularly needs any technical knowledge but expecting users to 
find,
download, install and work out how to use an image editor is rather an 
complicated
alternative. 

Maybe my users are different to yours but I've got a CMS used by people who know
Word, Excel and Outlook and not much else. They quite often don't have the 
rights  to
install software even if they wanted to.

Original comment by andybak on 15 Jun 2009 at 9:00

[GoogleCodeExporter]

to 1: yes, that´s definitely a usecase.
to 2: from my point of view, this should be done using IMAGE_GENERATOR - because
that´s the only way to ensure that all image-versions on your website have the 
same
size. inidividual resizing could lead to different image-sizes (which just 
can´t be
what you want). therefore, a resize-tool needs the possibility to predefine 
sizes.
this contradicts what I said before and I do revise my previous comment: 
resizing is
not essential ... if it´s implemented though, predefining sizes is important.
to 3: hmm. ok, I see your point (with your clients in mind).

some suggestions for the patch (if you want to work on that):
### to keep it simple, I would focus on the cropping behaviour 
(resizing/rotating
could be added later).
### cropping should only be possible for the original-image, not for 
image-versions
done with IMAGE_GENERATOR.
### if the original version is too big for the screen, it has to be scaled down 
somehow.

Original comment by sehmaschine on 15 Jun 2009 at 9:29

[GoogleCodeExporter]

one note on this issue: with FB3, all versions are generated on the fly - 
therefore,
cropping is only necessary for the original image ... thumbnails and versions 
will
automatically be updated.

Original comment by sehmaschine on 4 Aug 2009 at 7:20

[GoogleCodeExporter]

Original comment by sehmaschine on 11 Oct 2009 at 2:17

• Changed state: AwaitingPatch

[GoogleCodeExporter]

setting this to wontfix. if a patch is available, please reopen this ticket or 
add a
new one.

Original comment by sehmaschine on 12 Nov 2009 at 1:37

• Changed state: WontFix