Closed GoogleCodeExporter closed 9 years ago
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
Original comment by sehmaschine
on 14 Jun 2009 at 9:35
Original comment by sehmaschine
on 14 Jun 2009 at 9:36
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
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
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
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
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
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
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
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
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
Original comment by sehmaschine
on 11 Oct 2009 at 2:17
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
Original issue reported on code.google.com by
andybak
on 14 Jun 2009 at 9:15