Google shutting Picnik down!2 users found helpful
Might be time to look at replacing Picnik integration in the file manager with a new, similar service (something like Pixlr, maybe? Think they have a decent API) or perhaps something lighter weight within the core itself (I think Jordanlev has done some work on an C5 cropping image editor in the past...haven't seen any development of it for a while though).
Just a heads up all!
Can this thread turn into a list of options? That'd really help us..
CEO - concrete5.org
http://www.picmagick.com/ (has since been open-sourced MIT, so might be able to be fully integrated)
http://www.drpic.com/ - wow, ads ads ads...
http://pixenate.com/ - not so pretty....
http://snipshot.com/ - nice callback agent
Simple to use and they seem to be interested in the Picnic folks. They ask on facebook what Picnic users would like them to change to practically give them a second home. Resizing and co. is as simple as in picnic.
Quote from FB:
Guys, thank you for all kind words! We will try to add maximum features from Picnik and even more. Follow us on Facebook, Google+ and Twitter (find links on our FB page) to get our updates. We'll do our best to make iPiccy the second home for your photos.
- all html, no flash, easy to use - would be great!
What I'm really excited about is that block builder's should be able to hook in this, allowing users to crop an image to a block's specifications.
It could be a simple resizer or option system like WordPress; small, medium, large oprion.
Most of the time, people only want to use it to resize the image.
Or we could add the option "Small" "Medium" "Large" like WordPress.
So the site admin can upload and save the original size image, and config the image size of your site, and when pasting onto the page, it could resize onto the right size.
Just an idea.
But perhaps offer several integration options that can be switched from the dashboard. That way it will be more future proof. I have some installations of c5 that were customised somewhat so I'm not looking forward to having to update those. Spewin!
I had a vague plan to finish it up some day and sell it in the marketplace, but I'm not sure if that will ever happen. I'll talk to Franz about it, maybe they'd be interested in putting it into the core system now that Picnik is going away.
I sound fanatic because I am, this is the sort of project that I get excited about! =D
I dunno... maybe people were using Picnik to drastically alter their photos? I've never once myself done that or ever had a client ask to do that though -- really it's only resizing and cropping that I think are needed in the web interface. I guess I could see some touch-up stuff like brightness and contrast, maybe red-eye reduction -- but certainly not pencils and paintbrushes and color swatches.
Stepping back a bit, it is obvious that there probably isn't one best solution for everyone's needs. Some users are professional photographers (or advanced amateurs or whatever), whereas others are completely non-savvy. Some people don't even have offline photo editors (or if they do they certainly don't know they exist nor how to use them)...
What I think would be really great is if the "edit" item in the popup menu when you click a file in the file manager fired some kind of event, and you could install addons that responded to that. So people could choose various different image editor options (e.g. a stupid simple resizer/cropper like I suggested, a super full-featured editor like you suggested, or various API integrations to the services mentioned above). Ideally the core system would come pre-installed with one, and the rest could be in the marketplace. Kind of like how you can plug in different payment and shipping providers to the eCommerce system.
Haha...in fact, I dread to think what my clients would produce if given access to a heavily featured image editor directly within the c5 interface! Filters all over the shop, ugly artifacts and, probably, a server meltdown; someone who can't get their head around not uploading a 15mb, 300 dpi, CMYK photo is only going to cause trouble when presented with too many options within a click or two! Know Picnik kindof allowed this, but then the overheads were Picnik's problem, not mine, and I never really introduced my clients to the 'edit' functionality because I didn't want to be stuck supporting them on the 3rd-party Picnik interface.
Any advanced editor add-ons could indeed be submitted to the marketplace in the usual fashion for addition is the need arises for a particular (well-behaved) client.
re: variable compression -- I just remembered that the compression is only variable globally in C5 via a config/site.php definition. I believe Kirk Roberts hacked the image helper at one point to allow the compression setting to be passed in, so this might be a good change to bring into the core along with all the other stuff we're talking about here.
Also, note that compression levels only apply to JPEGs, not PNG's (due to the nature of PNG's, not a C5 limitation).
I actually grabbed that modified cropping image helper when Kirk Roberts put it up...used it on a couple of sites, but then got lazy and have fallen back to the core version. Sitewide setting probably would do the trick, although the flexibility in the instant would be nice. As a compromise, perhaps an 'Image Settings' page in Dashboard > Settings would work -- at least this way the client can have some control over the quality setting in the editor and/or sitewide without having to edit config.php.
When I found concrete5, I actually came from the WordPress world. For me and my clients, Picnik has been really "too much" and I've never had a situation where the WordPress edit options weren't enough (like many others have said here).
I actually found that while the editing options in Picnik are quite good, it really adds an overhead e.g. in a situation where I'm teaching my clients to crop or resize the image. That's the usual case and although it is quite easy with Picnik as well, it could be even easier (because there's a quite long time you have to wait before Picnik starts).
Just added my thoughts into the list...
Something Very Simple and maybe even have them tied into helpers so you can provide those plugins option from the block/package.
I could see that as a great use for the thumbnail page list blocks where you would like a certain aspect ratio for each image, to prevent users from uploading images to tall/wide
Then Simple options like Resize, rotate, flip?.
Developing from this topic, there are a growing number of areas in C5 that have override/extension/plugin capabilities. At the moment there is a mix of re-invention and a sort of coding Chinese whispers on how such mechanisms are implemented.
I really would like to see a generic manager that can then be utilised as required by any area of C5 and addons that needs override/extension/plugin support (I accept that these are not all the same). It may also help clean up a lot of similar code in the core.
Probably some more out there as well.
And more specifically the PHP wrapper phMagick
http://www.francodacosta.com (GNU Licenced)
the following from his website,
phMagick is wrapper for ImageMagick written in php 5, and it's designed with to ease the developer job by wraping ImageMagick complexity in easy to use functions.
It allows you dynamically generate thumbnails and catching effects like drop shadows, watermark images, write text as an image, create a mirror or reflex effect to images all without opening photoshop just with Php and ImageMagick. The main reason for making phMagick is to avoid the inefficiency of GD and php memory limits
EDIT: Sorry that wasn't very productive.
I'm so excited that concrete5 is now looking to find an awesome new html5/js editor. I'll start looking.
In the core there would be:
Nothing else. Then people could do their own add-ons for more extended editors.
I actually made just a POC/testing HTML canvas project of my own interest with one person I know few years back and I can tell you will be facing quite a lot issues in it if you actually want to make something "production ready" of your own although it might not seem like that much of code:
That was just of our own interest to test the abilities of HTML canvas element and was just a "playing around" project.
Also, cross browser issues should be considered in something like this when maybe some SVG drawing library might be a better choice...
Rotate, Resize, Crop
I would like to see a basic image editor that allows you to crop, rotate and resize images. It should detect and use the best image processor available and use GD if no other is available.
Picnik was neat but Flash sucks and it was slow. I don't think very many people used any of the cool features. Probably why they closed.
The key features are:
1) A developer can define the footprint you're working towards. That makes it really easy for Mom to upload an image from her camera and get it sized to the header space without remember scary numbers.
2) Scale controls
3) Rotate controls
4) Movement controls
Generally you're scaling/rotating/moving to fit it INTO a certain footprint, which is why our flash image guy has the treatment it does of showing the light box with the dimmed outter area.
The ideal solution for the core would not require any additional 3rd party image libraries.
Not work with flash (And be mobile/ipad friendly at possible)
And be built in a way that it could be swapped out with something more powerful than it if desired.
I'm a big fan of not reinventing the wheel, although the obvious experience on this one has been its not awesome when the wheel is removed from your car mid-trip. I agree we're not talking rocket science here so I can imagine just writing something. If there was a nice MIT/LGPL library that made that a lot easier, I'd feel comfortable with that approach. It's unlikely we'll do a direct hook into a commercial 3rd party service like that in the core again.
It doesn't have rotation, but that's the easiest feature to add.
As for "be built in a way that can be swapped out"... this is something that needs to be changed in the core code... just make that "edit" link in the file manager popup menu call some kind of hook or event or something instead of being hard-coded to the picnick stuff. Andrew should bestow us with some guidance on this one.
I'm also way to busy the next two weeks, but will try to sneek an 30-60 a day on it until it clears up.
Anything to make it easier for the client. All they want to do is upload an image and see it on their site without having to edit images.
If we were able to set the image size to individual blocks, which then scales/crops any image to the width of that block, now this would be great!
Or even better, set the size in the dashboard area and assign blocks to use this setting. You could have a checkbox at the bottom of the content block to tell it to use it or not.
Would this be an option?
I unfortunately can't provide any help with this for a couple of weeks due to life happenings, but if someone was going to spend time on it this will save you a TON as I've worked out a lot of UI math.
It's a pretty elegant UI in my opinion -- basically the user only has to put in 1 or 2 numbers (in theory those are defaulted by the designer/developer so laypeople can ignore them), then they can set the frame of the image to be whatever they want and it will automatically figure out the best possible dimensions and crops to make that work.
The README is very extensive, and contains a thorough todo list as well. This should give a big head start if someone wants to take it and run with it. Wish I could be more involved, but will be out of commission for the next few weeks...
Images are still dangerous though. You can force the size an image is displayed at, but I've seen people take photos from their 10 megapixel camera and stick them right in to a 200x200 image space.
I actually need this for something I'm working on, I'll investigate how this might be done with jordanlev's solution and get back to ya.
I definitely endorse the simple function approach, however what Franz says about not reinventing the wheel seems important too…
I was just setting up a new account on mailchimp for a client and noticed that mailchimp had replaced Picnik with Aviary … it's not on my personal mailchimp account so looks like something they are rolling out slowly, but in my opinion this is a significant endorsement of Aviary.
Secondly, I was extremely impressed with the simplicity of the Aviary set-up. You seem to just be able to embed the widget – you are not wrenched away to another site in the way that picnic used to. There is a demo here:http://www.aviary.com/web
So, basically whilst I'd certainly be keen for an bespoke concrete5 simple editor time it won't be long before picnik is gone and Aviary looks like a very good (/better) replacement.
ps - aviary does look pretty cool, but I can see how avoiding another third-party service might be preferred.
pps- wonder what's going to happen with non-updated c5 installs and the Edit button. Big fat error?
As others have already alluded to up above, it ended up using the jCrop plugin, with a jQueryUI range slider to adjust the size. I had to build custom dashboard components for the real-estate package, so the screenshots that are attached aren't in the context of the file manager, but the same code could easily be dropped into the file manager.
The details of how it works:
1) First step is you, as the site manager/developer, define the thumbnail dimensions as "thumbnail templates". There is a link in the dashboard that pops up a modal, which allows you to predefine image width and height. Super simple; you just define a width, height, and give it an "image template" name.
2) From the property manager menu (which would translate to the File Search page), you click on the property (which has a file assigned to it), and hit "Setup Site Thumbnail." (In the file manager, it might say "Manage thumbnails".
3) A modal pops up, where you have 1) a drag handle to adjust the size of the image, and 2) a drop-down menu to choose which thumbnail size this should be cropped to. As you select a different thumbnail size, the crop dimensions will change.
4) When you hit save, the system resizes/crops the image, and stores it in the cache.
5) The ImageHelper class was extended, so that there is now a method for getTemplatedThumbnail(); where you pass in the same arguments as the getThumbnail() method. If the user has done the previous steps and setup a custom thumbnail for the template matching the dimensions passed in to getTemplatedThumbnail, then it'll return that thumbnail. In all likelihood, the user isn't going to go in and setup ALL the thumbnails for ALL the images - so if the thumbnail matching the dimesions passed in doesn't exist, it'll fall back to the getThumbnail method with $crop = true, then return the image with a best-guess crop.
6) Same thing above has been ported to the image block. If the image that is supposed to be output has a cropped template matching the dimensions passed into the Width and Height fields of the block, it'll return that image. Otherwise, it'll fall back and crop it. Also, the ImageBlock setup form now has dropdown list of all the template names, and if one is selected, it'll use the dimensions in that template.
Screenshots are attached. Hope that all makes sense!
The UI certainly isn't the most polished/sexy thing in the world, but its super intuitive and works a treat.
If anyone is interested and thinks this might be a good approach to the problem, I'll do some forking to the core file manager and put in a pull request on github and you guys can check it out.
A pity Google is closing Picnik :/
Not sure if that is still an option, but something to consider....the Aviary site really does not say anything about "free", though...but I did not sign up for a key so I don't know if they do a "requests per month" type of thing or not.
We've just released this addon to seamlessly replace Picnik with Aviary:
So, here's my solution, which is totally born out in the wild working w/ clients and emerging html5/css3 standards.
I think the answer is already here. I've built 2 adaptive websites now, and had to do some js to remove the image width & height from images placed via TinyMCE. So that would be the first step—a check box or something to tell TinyMCE wether or not to insert image width & height values.
Once that's taken care of, then the script that generates thumbnails could be used, along w/ the techniques used here:http://adaptive-images.com/
This would be incredibly useful, as it would allow site developers alot more ease in making a site adaptive—images being the big problem currently—using CSS Media Queries. This will equal out to 1 site fits all, a developers dream.
As an added bonus, I don't have to explain the ins & outs to clients about image sizing anymore. They could upload "Large" images from their cameras and smart phone—a good idea considering Retina Displays on the horizon—then you have some settings that the developer defines for thumbnail sizes of that image—ones that will fit the layout from smart phone to tablet to web to TV. Using that large image, c5 could make an image all those sizes and cache it. Then the proper image could be delivered based on screen size.
This would solve several problems in one. However, it wouldn't solve photo editing per say, just sizing and prepping for an adaptive web.
Hope this makes sense. I'd love to know others thoughts on this. While it may not be the photo editing solution—it's definately something that needs to be addressed in c5, b/c like it or not, the web is going mobile.
Hope this helps generate some ideas.! Holler if you have any questions.
new ipads and chuckling the other day
CEO - concrete5.org
Thanks Abs0lute for the intro to the discussion and reaching out as you did.
For what it is worth, here is my (long-winded) opinion:
I tend to agree with a majority here in that, in my experience, image cropping and resizing is the most in-demand requirement and the other needs are to be considered separate. I also agree that clients should be insulated away from this challenge as much as possible.
Given this, the approach I decided to take to crack this particular nut was to include the knowledge of image dimension constraints (i.e. site design) and perform a "best fit" automated crop. This empowers the site developer/designer to build this constraint into the c5 template logic.
A number of assumptions are made in this approach however. For instance, an uploaded image that has square dimensions, which needs to fit into a rectangular element within the design is centralised on the axis that needs cropping. Common sense you may think but remember this is taking that control away from the client, which depending on the scenario could be a good or bad thing. In my case, it was a good thing and the users have been grateful. Not once has there been the scenario where a non-central crop was needed but to be fair, this could be down to transparent communication with the clients about what the system would do for them so that they had the knowledge to hand to "feed" the system the right images.
The only other option I built into this solution (an extended ImageHelper that uses PHP's GD library) was whether an image should be pseudo zoomed. That is to say that if an image would be cropped to such a degree that the image doesn't fill the containing area in the other axis, the level of crop would be eased out so that the containing element would be guaranteed to be filled. In my opinion, this again is a decision that the designer/developer should make and not the end user, which is why it is a function parameter, which could of course be driven by a block's attribute - i.e. checkbox in block edit form.
Finally, and slightly separate, in my uses of this logic, the code that utilises this extended ImageHelper is context aware in that it knows of the consuming device constraints. I've utilised the DeviceAtlas service to identify the device and utilise knowledge of the device's screen resolution to provide the constraints for the ImageHelper logic.
This has worked pretty well for me and has taken care of those scenarios where clients upload that 10Gazillion pixel picture, which won't excessively negatively affect the page load time for visitors (image cached after crop).
The only part I'm not comfortable with is a general challenge around Responsive Web Design and images. The link between knowing the design constraints within the CSS and implementing that constraint within the c5 page type or block templates sits uncomfortably with me but it is an easy compromise when the alternative is to "educate" clients on their additional responsibilities when using a fuller editing solution.
The above approach allows you to generically target certain devices using the responsive web design concept. Knowing that a given logo or profile pic is to be say 25% of its parent (the parent being the body for example) and detecting the iPhone's retina display through Device Atlas allows you to constrain the width of that image served to 0.25x<X>, where <X> (640 in the iPhone 4 case) is the physical width in pixels of the detected device.
So in conclusion, I'm all for keeping it simple for users to the point where they shouldn't have to do anything!
Therefore, my request, would be to have such a 'best practice' approach evolve around an improved ImageHelper (from my strawman above - feel free to pick at - Jordanlev has already given great constructive critique) and give site developers the option to enable 'extended' image editing features through an API, which could be implemented by 3rd party in my opinion.
Happy to share further if it would be any use.
However, please note that adaptive images is not a complete solution to everyone's image editing needs -- even if mobile is becoming dominant, adaptive design is just one approach to building mobile sites, not the only approach. Yes, it's a popular one and one I think is great and concrete5 should support it, but it will not be the solution for everyone out there.
Kind of off-topic, but what I think would be great is if you could set max width and/or height dimensions on the AREA in your theme templates -- then that would somehow filter up to image controls in blocks so they'd know which dimensions to use as the "frame" in the new built-in image resizer thing.
Currently, the W3C is also considering adding bandwidth as an option to be used in media queries also. If it goes through, I think Responsive Design will be the rock solid choice for moving forward into a mobile web.
I agree that Responsive web design may not be what everyone needs—but it is certainly the holy grail for developers I know in that it offers the promise of 1 site for all screen sizes.
I'm sure some more robust image editing would be needed for those that rely on it though, but I think having responsive image capabilities will go a long long way in addressing what most clients need and actually use—without them even needing to know how to use it b/c it'll do it's job automatically!
Definitely agreed that we're talking about what is actually a broad set of Use Cases here.
For those who want more tools, or don't want to upgrade their site, you can use the aviary image editor which is in the marketplace. This is only something you'd have to do if you didn't want to upgrade, or if you want more functionality than what the built-in editor provides.
Finally, we'd love help in testing and improving the built-in editor, and would be happy to review pull requests in github related to it. Sounds like there's some great developer energy in this thread.
One last thing: we had a nice page that should have shown up for users of concrete5 before 5.5, should they try and edit images. We were with picnik to show this page post-closure. It looks like there are some kinks in that page, leading to a less than instructive experience post-closure. We're trying to rectify this. Thanks everybody!
Can you give me a yes/no on if you'd accept a pull request that modifies the Area class to accept image dimensions, which are then passed to the image editor (in the case that the block itself hasn't explicitly set width/height?).
My reasoning here is that when I'm building a site for a client, I know that the sidebar is 200px wide, with 10px of padding, so I know that any image added to that area (whether it's an image block or any other kind of block) should have a max width of 180px -- and if this could be passed to the new image editor instead of requiring the user to enter width/height into some boxes, that would make things that much easier.
EDIT: Final touches wasn't really accurate. I had a fair amount of interface stuff to do. This was right around 5.5.1 if I remember correctly.
SECOND EDIT: I can't remember if versioning was supported.
>Can you give me a yes/no on if you'd accept a pull request that modifies the Area class to accept image dimensions, which are then passed to the image editor (in the case that the block itself hasn't explicitly set width/height?).
>My reasoning here is that when I'm building a site for a client, I know that the sidebar is 200px wide, with 10px of padding, so I know that any image added to that area (whether it's an image block or any other kind of block) should have a max width of 180px -- and if this could be passed to the new image editor instead of requiring the user to enter width/height into some boxes, that would make things that much easier.
Would love this. This is a much better match for real world use.
Is the Area the right place for this? It feels too high up the chain if you ask me and a little too specific.
In my opinion, it feels like it should be something that we can set into a Block via the Area in much the same way as we can set custom templates for specific Blocks within a given Area.
More specifically, an abstract method to set some properties of a Block and therefore these properties are Area specific and influence the Block's rendering within that Area only. How a block interprets these properties is up to the implementation of that Block and even as simple as utilising these properties in a custom View template.
EDIT: example - $a->setBlockProperties($block,$propertiesArray);
For example, if I am able to set a couple of properties into any Image Block within a given Area (say a maxWidth and maxHeight value for example), I would then be content to write a custom View template for that block that utilises these properties. Equally, you could imagine further settings that may influence the nature of any automated modification such as the "zoom" feature I mentioned earlier or any other designer desired feature like grey-scale only images etc.
Therefore, could part of the solution be the passing of a generic properties map into Blocks via the Area?
Disclaimer: I'm no c5 expert so apologies if I've bypassed something that already exists or been oblivious to.
Would love to be able to pass the dimensions in and really like the Area option,
Setting at the block level would be good, but the problem then require the client to change the settings if they move the block? ie move the block from the sidebar at 200px to the header where the image is the full width of the page. I know its not difficult to do if it where a custom template but it would be nice to do it automatically. (Though maybe this could involve a similar $a->setCustomTemplate($block, "template");
For me an ideal solution would be nice to have the option cascade, so I could set the dimensions at the area level and then if defined at the block level it would override the areas setting.
I like Sean's inheritance and override extension to the idea even more.
My idea is basically what @TheRealSean mentioned -- that the theme designer could provide "fallback dimensions" in the area, but they could be overridden on a per-block basis.
As you can tell, I wasn't aware of that so thanks for the tip. I'm only a "weekend" c5'er so to speak, so my exposure to the broader code base is not too in-depth.
I still feel that a dimension related named method on the Area object feels too specific, regardless of its role as a fall-back. I'm in agreement with you over the need to get fall-back dimensions to the blocks that need it though.
Given that you say you can set Area specific property values and a Block can access them, I think the solution is mostly in place. A 'setDimensions' method on the Area feels too much like 'it fixes my problem today' and by name, it has a very finite scope. By contrast, the setting of properties via the Area is abstract enough to be applied across different Blocks for different Use Cases. i.e. Setting the fallback max dimensions for an Image Block through the Area properties but also perhaps setting a property that is read by a Video Block that auto-plays when it is in the main central content Area when by default it would not or passing a property that plays a video without the playback controls etc.
These things should typically be under a developer/site designer's control - creating a custom Block template achieves this and negates the need to build these options into a customised Block with such properties persisted to the database.
This scratches that itch and really nice to use.
Please award yourself 100 internet points. :)
I think thumbnail creation should be built into the core as discussed. Why does Wordpress have this feature in the filemanager yet concrete5 doesn't?! Is there too many variables involved to have this much needed thumbnail option?
Why would concrete5 have to rely on third party image cropping for thumbnails?
For me the ideal scenario would be to define thumbnail sizes and then in the filemanager have an option next to edit as - create thumbnail which gives the option of the predefined sizes. Then when you edit the thumbnail there in a crop window (the right size) like in the cropzoom demos.
I have also noticed that the whole image core image editing is a bit buggy anyway. The crop window shows the wrong size dimensions. When you click undo the window size goes weird and when you save the timer goes on forever. I had to make excuses for all of this to my client yesterday, but I don't know the real reasons.
This is the first site I have built on Concrete5 and I think it is excellent, it is just the image editing core which I think needs more attention.