responsiveimagescg / wp-tevko-responsive-images Goto Github PK

I just tried this plugin and got the following error:

Warning: Division by zero in /www/htdocs/blog/wp-content/plugins/ricg-responsive-images/wp-tevko-responsive-images.php on line 49

PHP version: 5.3.28
Wordpress: 4.1
Plugin: 2.0.1

And I´m using the Visual Composer plugin to edit content.
I think that the plugin by itself has to support responsive images but I think there should be an error.

I hope that all WP developers are including more responsive images in the future!

I currently have the unfortunate task of having to work with a purchased Wordpress theme that uses Visual Composer (or Composter as I call it...) and was hoping to use this picturefill plugin to help reduce the mess.

But it doesn't appear to work as I assume that VC must be using its own media uploader or something.

Can you possibly confirm this?

The latest version 2.0.2 is giving me an error when i tried updating it, i deleted it and i'm getting the same error now when downloading.

Warning: Invalid argument supplied for foreach() in /path/to/site/wp-admin/includes/class-wp-upgrader.php on line 974
The package could not be installed. No valid plugins were found.

Hello,
The plugin seems to work fine on every browser but Chrome.
Basically, the src of the img keep being the full-size image instead of changing according to the window size, which is pretty problematic. The width attribute doesn't seem to show up either. Seems like a JS issue ( or maybe Picturefill 2.3 ?) , but I can't find a callback to test the issue.

Thanks in advance.
Jet

When custom image sizes exist that have been hard cropped, i.e., they have different aspect ratios than the original, those sizes shouldn't be used as srcset options.

In case the w descriptor is used the sizes attribute is a required attribute. By adding a srcset without making sure, that there is a corresponding sizes attribute declared, will yield into the following results:

a) the markup is invalid
b) let the browser will choose a wrong image candidate. (in most cases a too big one)

see also: #15

Currently, because this plugin requires PHP to use, it cannot be used in the WordPress editor. Example:

<img src="myimg.png" <?php echo tevkori_get_src_sizes( 11, 'tevkoriMedium-img' ); ?> />

This won't work in the WP editor. Adding a shortcode reference for tevkori_get_src_sizes will allow it to be used in the editor as well. Example:

<img src="myimg.png" [tevkori_get_src_sizes id="11" size="'tevkoriMedium-img"] />

Thanks!

I've done some testing with single article: http://sequencebreak.ru/apotheon/ Images are displayed correctly, and according to Safari inspection correctly small images are loaded on mobile: http://take.ms/8fbiX
However, Pagespeed Insights still reports that 2 images can be greatly reduces by scaling and optimising: https://developers.google.com/speed/pagespeed/insights/?url=sequencebreak.ru%2Fapotheon%2F. Since they're optimised really (I use EWWW) I think scaling is what PI suggests. Funny enough it doesn't notice unscaled featured image inserted via CSS background btw.
Is there any reasonable way to avoid this Insights penalty (it affects PageRank, yada, yada)?

Details:
https://make.wordpress.org/core/handbook/inline-documentation-standards/php-documentation-standards/#docblock-formatting

Hello, thanks very much for your work on this plugin.

I have some custom image sizes defined as well as Wordpress defaults. Only the Wordpress default thumbnail has a hard crop and I am only working with featured images at the moment.

Some image sizes (with a soft crop) were not being put in the srcset which appeared to be because of the comparison of the aspect ratios in the php (which looks like it is only supposed to remove hard cropped images?).

For one image $ratio is 1.34 but for the Wordpress medium and large image sizes for that image $crop_ratio is 1.33 and they were being unset from $default_sizes. I altered the code to work out the aspect ratios to:

$ratio = floor( ( $width / $height ) * 10 );
foreach ( $default_sizes as $key => $image_size ) {
    $crop_ratio = floor( ( $image_size['width'] / $image_size['height'] ) * 10 );

That seems to solve the problem for me and now the $ratio and $crop_ratio for my images match apart from the thumbnail which has a hard crop and gets unset. Is this how it is supposed to work?

The editor_max_image_size filter is only removed when an image is uploaded. Updating an image in the editor causes the srcset attribute to be recalculated via javascript, but the w descriptor can sometimes be incorrect because the editor_max_image_size filter still exists in this case. I suggest removing this filter entirely at the start of the plugin. @helenhousandi would this be a bad thing to do?

Add QUnit tests for unit testing wp-tevko-responsive-images.js. Will probably require some refactoring of the the logic in this code to make it testable.

The W3 TotalCache plugin has an option to serve assets from a CDN. When that option is enabled, TC rewrites the src attribute of images but not any of the sources passed to the srcset attribute. We should do some research into how TC is filtering the src and see if we can apply the same filtering to the list of source candidates.

See related: https://wordpress.org/support/topic/cdn-support-3?replies=2#post-6872756

Right now we're only include a 1x banner at 772x250px. I've remade the banner with a 2x version: https://cloudup.com/c0T5BT9q6Ix

Hi, I love this plugin for Wordpress, kudos to the team!

I'm curious if this plugin can apply the same rules to background images? Or images added via the functions.php file instead of via the admin editor? If so, how would I do so?

Thanks in advance!

https://wordpress.org/support/topic/jetpack-photon-compatibility

When in WP_DEBUG mode I get the following error:

Notice: Use of undefined constant tevkori_filter_post_thumbnail_html - assumed 'tevkori_filter_post_thumbnail_html' in /sites/domain.tld/www/dev/wp-content/plugins/ricg-responsive-images/wp-tevko-responsive-images.php on line 97

changing line 97 in wp-tevko-responsive-images.php from

add_filter( 'post_thumbnail_html', tevkori_filter_post_thumbnail_html, 0, 5);

to

add_filter( 'post_thumbnail_html', 'tevkori_filter_post_thumbnail_html', 0, 5);

seems to fix the warning... is this correct?

We ought to be able to set a default sizes attribute without having to insert it into every image manually. That way the default sizes string could be pulled in dynamically for all images without having to edit any posts/pages/etc.

However, that quickly falls apart once you have images for different purposes. Images in the content area will probably need a different sizes attribute than post thumbnails.

To solve that issue, we could define image groups in the WordPress admin, rather than image sizes alone. Image groups would consist of at least 2 image sizes, and a sizes string. For example:

1. Image Size 1 is 4:3, set to a hard crop at 320px by 240px, takes up 100% of the viewport width on mobile.
2. Image Size 2 is 3:2, set to a hard crop at 540px by 360px, takes up 50% of the viewport width at a browser width of 1080px.

So, a hypothetical sizes attribute for this image group would be sizes="(max-width: 320px) 100vw, 50vw" or sizes="(min-width: 1080px) 50vw, 100vw", depending on your priorities.

Would you be open to include an option to lazy load images? Basically it would require these changes:

• add class="lazyload"
• change src to data-src
• set data-sizes="auto"
• include https://github.com/aFarkas/lazysizes script
• option to switch picturefill for https://github.com/afarkas/respimage (not sure whether this is needed)

ping @aFarkas

The post data sizes object doesn't contain all image sizes, it only contains the sizes that are available in the editor. Sizes that are added with add_image_size, but not made available in the editor with image_size_names_choose won't end up in the srcset.

The only way I can think of to fix this is to use AJAX so you can use the same PHP functions to create the srcset.

Note: When looking into this be aware of a bug in WordPress core. When switching to "custom size" in the editor you have to set a size with the same aspect ratio of the original image. However, the src url won't be updated. So if you have a 300x200 image, inserted it as a 150x150 cropped thumbnail, and then switch in the editor to 150x100 custom size, you get 150x150 (distorted) image displayed at size 150x100. That is if you wouldn't use srcset of course.

Hi,
I was forwarded over here from the Slack #feature-respimg channel as the recommended place to suggest feature proposals regarding the responsive image plugin.
So far i was using responsive images with the Advanced Custom Fields plugins image object functionality and the Picturefill plugin (version 1.x). The designs I use contain x1.5 and x2 retina images as well as different sets of images with varying aspect ratios on differing break points. Which means i have normally e.g. about three to four sets with a number of widths for each at certain breakpoints. One set alone would hold e.g. about eight versions per image in sum. A few sizes are available in every set. But even without those I normally still end up with 15 to 30 images in my projects in the end. Instead of being able to adjust the content image creation to the exact amount of sizes needed for a particular images you end up with too many unnecessary image versions as well as tenth of unneeded megabytes in sum.
In the following I split the text into two parts. At first the present state is described, followed by the suggested solution afterwards. I have to add that I kept the underlying constraint in consideration that things should be kept simple for the end user while it should be still possible for developers to configure and tweak on a per theme basis via the functions.php file. I hope I’ve headed towards the happy medium.

Present State

At the moment I’ve normally used the following steps. First I’ve unsetted the default wp sizes

function df_remove_default_image_sizes( $sizes ) {
    unset( $sizes['thumbnail']);
    unset( $sizes['medium']);
    unset( $sizes['large']);
    return $sizes;
}
add_filter( 'intermediate_image_sizes_advanced', 'df_remove_default_image_sizes' );

In the next step all necessary image sizes are added (I’ve listed only one example per resolution).

add_image_size('is268', 268, 9999);
add_image_size('is268_x15', 402, 9999);
add_image_size('is268_x2', 536, 9999);

Depending on the layout you might end up with 15 to 30 versions per image over all, sometimes even more. But for example a content image in a narrow sidebar never reaches broader widths. Therefor only a fraction of the created images versions would be necessary.

Proposed Future State

The Constraints

As I said before the constraints are the following:

• Don't swamp the enduser with too many options
• Leave the developers enough hooks and configuration options to adjust things to their needs
• The configuration should be on a per theme basis in the functions.php and not via the global user interface.

The Problem

• There are different content images with differing aspect ratios in differing breakpoint scenarios ( feature images, narrow images in sidebars etc.)
• Possible that you end up with three to four or even more different types/sets of images.
• As described in the „present state“ section you end up with tenth of different images per image to cover all sets and scenarios.
• But basically the sidebar example would only need e.g. six.

The Proposed Solution

• In the WP Admin interface the enduser is able to adjust the extents of the three default media sizes. (Probably enough in a lot of use cases in combination with the img src method.)
• I would entitle it the default „image set“
• In the functions.php it should be possible to modify that default image set too:
  • Remove or modify the existing sizes from the admin interface
  • Add more sizes
  • Add actions that retina images should be generated for the particular image set. Which means if e.g. x2 is set, WordPress would automatically generate twice the width and height of the set sizes. No extra configuration and calculation needed from the developer side (x1.5 and x3 would be analogous if set)
  • Note: I am unsure if it would make sense to reflect the functions.php settings of the default image set directly into the media preferences inside the admin interface or leave it there as is at the moment.
• Aside the default image set you would be able to create and name more image sets
  • Inside each set you would be able to set widths and heights like in the default set
  • The retina settings get adopted for each image set from the default parent image set.
• As soon as there are more image sets aside the default one, the image edit inside the media center should show up a select field showing the list of available image sets. So you are able to reassign an image to a certain image set.
  • Per default new uploaded images are assigned to the default image set and the sizes of the default image set are created
  • If you change the image set from default to e.g. the one named sidebar, when hitting ok, the old sizes are deleted and the sizes of the selected image set are created.

That is just the rough outline. I haven't gone into detail. Just wanted to outline the current flaw of image creation in WordPress in regard of responsive images. The present state might be ok for a site with 5 or 10 images. But as soon as you have a more complex site with many images over the time the amount of unnecessary images never used would rise exponentially as well as the need for disk space. You might prevent that situation with an approach like the proposed image sets. Any thoughts? ;) Cheers Ralf

nacin [4:37 PM]
@tevko: I think part of the problem with custom image sizes is they are without regard for what the user actually wants/needs. They're just arbitrary values.

nacin [4:37 PM]
We can, as a first pass, use all image sizes already there, on a per-image basis.

After installing and activating this plugin I found the following:

http vs. https settings weren't being respected, so an image would get src="https://whatever.jpg" but then sourceset="http://whatever.jpg", which gives off scary warnings in browsers.

Also, featured images that used, say, the_post_thumbnail('large') would output featured-image-920x450-920x450.jpg instead of just featured-image-920x450.jpg

Wouldn't it make sense to remove the src attribute to prevent browsers from loading images twice?

The plugin isn't working on my new site, which uses WordPress 3.9.2 and Canvas/Woo Themes. Would it be hard to support older versions of WordPress? Should we try? If we did, would we be encouraging people to run older, insecure versions of WordPress?

The change log sez 2.2.2 but the actually repo is 2.2.0.

Hey,
if you download install the plugin from this source:
https://wordpress.org/plugins/ricg-responsive-images/
...the file picturefill.min.js is missing in the js directory, so it can't be loaded (the scipt source added to the webpage by the plugin points to js/picturefill.min.js) and the plugin won't work if you use a browser that needs it for responsive images.
Best,
Jonathan

test plugin behavior when dealing with an image that has been cropped via the media editor

I believe there are two potentials for false positives.

one potential issue (I believe someone mentioned it already) is if a person/plugin were to disable intermediate_image_sizes.

The second potential issue is if the image uploaded isn't as large as the super image size you've defined. wp_get_attachment_src will return the closest if the exact size isn't found.

Both of these issues could be avoided by first checking your mappings against wp_get_attachment_metadata sizes. Merge those arrays and do your loop based on those sizes. This would remove the need for $sizeAlreadyCalled and the additional conditional checks within your loop.

There might be an added benefit with this as you could use additional added intermediate sizes defined by plugin developers, if you wanted to include them.

I roughly rewrote the get_src_sizes function (not complete source):

function tevkori_get_src_sizes( $id, $size ) {
    $arr = array();
    $src = wp_get_attachment_image_src( $id, $size );
    $image = wp_get_attachment_metadata( $id );

    // choose sizes based on the users needs.
    $width = !empty($src['width']) && $src['width'] < $image['width'] ? $src['width'] : $image['width'];

    // default sizes
    $sizes = array(320, 640, 960, 1280);

    // TODO: make sizes filterable, then sort to ensure they didn't choose sizes randomly.
    asort($sizes);

    // First, remove sizes we don't need to check for
    foreach ($sizes as $key => $value) {
        if( $value > $width ) {
            unset($sizes[$key]);
        }
    }

    // No sizes? Checkout early
    if(!$sizes)
        return false;

    // Loop through each size we know should exist
    foreach($sizes as $key => $size) {      
        // Reference the size directly by it's pixel dimension
        $image_src = wp_get_attachment_image_src( $id, $size );

        $arr[] = $image_src[0] . ' ' . $image_src[1] .'w';
    }

    return 'srcset="' . implode( ', ', $arr ) . '"';
}

Currently the tevkori_get_src_sizes function return the srcset value surrounded with srcset="" attribute.

This makes it hard for developer to work with the actual generated srcset value.

After some thought, I have a proposal for how we might be able to incorporate the sizes attribute as it was meant to function in relation to the w descriptor in srcset. At present, the plugin does not set any sizes attribute on images because, by doing so, we would be giving the browser information about the intended layout width of the image relative to the page—information we do not have, and information which only the theme author (or someone implementing a theme) would know for certain.

However, as has been expressed in #15, #21, #29, and elsewhere, not setting a sizes attribute currently tells browsers (or PictureFill) that the image will be displayed at 100% of the viewport, which will often mislead to the browser into choosing an image from the source set list that is much larger than what is actually needed. Particularly when the image is actually being displayed at a much smaller layout width than the full viewport width (e.g., tablets, laptop/desktop screens, etc.).

For content images, we may not know the actual width of the image in a layout, but we might be able to assume that the maximum width of the image is the width of the original image selected (i.e., the one referenced by the src attribute) and build a sizes list accordingly. For example, if the original image that was chosen is 600px wide, we might be able to safely tell the browser that the image should never be larger than 600px wide. Or to put it in terms of a sizes attribute list, it would look like this:

sizes="(min-width: 600px) 600px, 100vw"

To extend this example, let's say we upload a 3000px wide image and WordPress makes the standard soft crops: medium 300px and large 1024px. Now let's assume we've chosen to embed the medium size image in our post. Currently, the plugin would embed that image with the following markup (omitting a sizes attribute):

<img class="size-medium" 
    src="http://mysite.com/wp-content/uploads/2015/1/sample-image-300x230.jpg" 
    srcset="http://mysite.com/wp-content/uploads/2015/1/sample-image-300x230.jpg 300w,
        http://mysite.com/wp-content/uploads/2015/1/sample-image-300x230.jpg -1024x768.jpg 1024w,
        http://mysite.com/wp-content/uploads/2015/1/sample-image-300x230.jpg 3000w"
    alt="6882791353_7d4a982544_o" width="300" height="230" 
/>

If I were viewing this image on a non-retina (1x pixel density) tablet with a viewport width of 1024px, the browser would assume that the image should be 100% of the screen and choose to load the large, 1024px image, when in fact, it should have chosen the 300px version. On a larger retina screen, we very well might get served the 3000px image when the 1024px version would be much more than adequate.

By adding a sizes attribute such that the first source size in the source size list matches (min-width: {{chosen-size}}) {{chosen-size}}, 100vw the markup from above would now be:

<img class="size-medium" 
    src="http://mysite.com/wp-content/uploads/2015/1/sample-image-300x230.jpg" 
    sizes="(min-width: 300px) 300px, 100vw"
    srcset="http://mysite.com/wp-content/uploads/2015/1/sample-image-300x230.jpg 300w,
        http://mysite.com/wp-content/uploads/2015/1/sample-image-300x230.jpg -1024x768.jpg 1024w,
        http://mysite.com/wp-content/uploads/2015/1/sample-image-300x230.jpg 3000w"
    alt="6882791353_7d4a982544_o" width="300" height="230" 
/>

In our above examples, the tablet would choose the 300px wide image and the retina screen would choose the 1024px wide image, a considerable bandwidth savings in both cases.

Given that the RICG has as recently as 10 days ago changed the proposed spec such that a srcset list using w descriptors without a corresponding sizes attribute would not assume a source size of 100vw but instead do nothing, as @aFarkas rightly pointed out in #29 (comment), we may end up needing to deal with the sizes attribute in a more explicit way no matter what.

I think this may be a sensible approach, but I'd love to get feedback before trudging down this path in case there be dragons of which I'm unaware. Thanks!

Usage Example

$sources = tevkori_get_srcset_array( 11, 'medium' );

$srcset = array();
foreach( $srcset as $source ) {
if ( false === strpos(' 900w', $source) {
$srcset[] = $source;
}

}

should read
if ( false === strpos(' 900w', $source) ) {

Currently picturefill is added to the bottom of the page. It would be much better to add the script in the head.

From my viewpoint there are two best practice possibilities to add picturefill to a document:

1. conditionally before any blocking stylesheets and javascripts

<script>
(function(d) {
    if(!window.HTMLPictureElement){
        var p = d.createElement('script');
        p.src = 'picturefill.js';
        var s = d.getElementsByTagName('script')[0]; s.parentNode.insertBefore(p, s);
    }
})(document);
</script>
<!--
your stylesheets...
<link href="" />
-->

1. Include somewhere in the head after stylesheets using the async attribute

<!--
your stylesheets...
<link href="" />
-->
<script src="picturefill.js" async=""></script>

While both things are possible with wordpress, there is no official API to do this. I'm not sure, wether it is a good "wordpress" practice to add scripts without using the official APIs (in case there is a better embed techique for the special script).

In case you want / should / must use the wordpress functions to add new scripts, please add picturefill simply to the head:

wp_enqueue_script( 'picturefill', plugins_url( 'js/picturefill.js', __FILE__ ), array(), '2.2.0', false);

Awesome plugin guys. Really great stuff. I was wondering if there are any plans for some type of bulk method to add the responsive capabilities of this plugin to previously added images. I know this can be done one by one but if anyone knows of some type of workaround to apply to all past images that would be great! I have another project with 500+ previously added images that I would like to use this plugin with.

Any thoughts?

For example, with the following sizes set:

set_post_thumbnail_size(120, 100);
add_image_size('thumb-m', 180, 150);
add_image_size('thumb-l', 240, 200);
add_image_size('thumb-xl', 390, 325);

Passing 'thumb-l' as 'theLargestImageSizeNeeded' returns a list containing all image sizes, with the thumbnail size in twice.

I'm expecting only the following sizes: thumbnail, thumb-m, thumb-l - is that not correct?

Dropping this here for my own benefit. I would like to add unit tests to the plugin, if even only on a development branch. Something like http://wp-cli.org/commands/scaffold/plugin-tests/.

Hi,

at first: Thanks for your work on this plugin, it`s great! :)

I tried it on my blog and it works very fine. But when the viewport is wider than an uploaded full width image (for exapmle 1200px) then the plugin loads this image and the theme scales it down.

You can see it here (for example the featured image for the "the_posts_pagination"-post): http://brinkmannblog.de/

I hope it was understandable :)

Florian

Since WordPress supports plugin icons now, we should consider adding one. I've exported the RICG logo as an svg we can use: https://cloudup.com/cZ1XPc1_qAm

(Note: the cloudup preview looks gross, but the icon itself doesn't.)

I get lots of false positives, i.e. sizes are unset because the image ratio doesn't match exactly. I don't know if this is because I use ImageMagick to resize the images - but at least half the pics have 1 or 2 px difference.

I changed the soft crop check to this to deal with this situation:

if( abs( $image_size['height'] - $soft_height ) > 2 ) {

This is analog to the 'rounding bug update': 4314d38

Reported in the WordPress.org support forum: https://wordpress.org/support/topic/safari-loads-biggest-available-size?replies=4

I'm having trouble to get this plugin working on Safari (Mac OS and iOS latest versions). The browser displays the correct size, but the biggest available size (the original uploaded file pic.jpg) will be downloaded also (as seen in the timeline). The cache is clear. Chrome, FF are working perfectly.

Follow up comment:

I've figured out the same problem at the official picturefill demo sites.

Possible solution: As Safari doesn't fully support the srcset Attribute yet, it falls back to src. So Safari always downloads the "fallback" version (in this case the full resolution image) and the appropriate image.

Any feedback is welcome!

Also I suggest to omit the fallback src attribute, as described by scott jehl http://www.filamentgroup.com/lab/to-picturefill.html

Should we consider removing the src attribute or is there a better workaround since Scott wrote that article?

... tutorials, examples, and some sort of support line, should be linked to the readme file

From nacin:

I think a barebones plugin could be an action on wp_print_footer_scripts (for polyfill), a filter on img_caption_shortcode (to handle images with captions), and simple regex on the_content filter (for images without captions). This would be in lieu of doing anything in the database, and would allow it to automagically work for all previous images.

This is more of a suggestion than anything else: when we're discussing different pieces of the plugin, it's pretty easy to get confused when we use generic phrases to describe something more specific. For instance, use of the word "sizes" can have two connotations here:

1. The sizes attribute
2. WordPress image sizes

To that end, it might be worth setting up a small glossary of terms to help everybody stay on the same page, otherwise it takes a bit more time to decipher what exactly is being discussed.

Another small item is just making sure that the code and comments are clearly understandable. For example, line 79 of the main file is commented as extend image tag to include sizes attribute, when it probably ought to say srcset attribute.

Making our code clear, our comments clear, and our word choice clear will help anyone else who comes along to contribute get up to speed without relying overmuch on reading comprehension.

We're on 2.2.0 beta now. Do we want to go ahead and move to 2.3.0 beta and hotfix/upgrade towards PF stable as needed or do we stick to stable releases only going forward?

I think it would only improve the performance of the site. Especially during a case where the browser thinks an image needs full resolution at 100vw, when it really only needs a fraction of that. @Wilto

When a theme developer is using the function to get a srcset attribute, they need to use the following markup <img src="pathToImage" <?php echo tevkori_get_srcset_string( TheIdOfYourImage, theLargestImageSizeNeeded ); ?> />

That second parameter doesn't make sense in this case because it's only the media uploader that needs sizing information. The developer is then lead to believe that the second parameter will return a srcset attribute containing only the image sizes at/under what is specified in the second parameter.

The plugin should be modified so that if the second parameter is left blank, a full srcset attribute is still returned. Then, the docs should be updated.

The author in the main plugin PHP file is an arbitrary string, but contributors listed in the readme are parsed as WordPress.org usernames. We should fix them. The ones I know are:

• Tim Evko: tevko
• Mat Marquis: wilto
• Chris Coyier: chriscoyier
• Kelly Dwan: ryelle
• Andrew Nacin: nacin
• George Stephanis: georgestephanis
• Helen Hou-Sandí: helen
• The Wordpress Core Team: wordpressdotorg

Hello, love this plugin. Has simplified my life immensely.

I've noticed that using tevkori_get_srcset_string() always returns a full set of sizes, even when I supply it with a valid name for an available image size to limit the srcset output to be under a particular size. Any thoughts on what might be causing this issue, or is this expected behavior?

Here are the relevant functions I use to generate my image tags. (Note that the initial src for the image comes from a function call to Types, my custom post type/custom field management plugin.)

//helper function to retrieve an image's post ID from its src
function get_attachment_id_from_src($image_src) {
    global $wpdb;
    $query = "SELECT ID FROM {$wpdb->posts} WHERE guid='$image_src'";
    $id = $wpdb->get_var($query);
    return $id;
}

//function that I invoke to embed a responsive image in my templates
function tim_rourke_types_responsive( $post_id, $customfieldname, $size, $class = '' ) {
    $imgSrc = types_render_field( $customfieldname, array( 'id' => $post_id, 'output' => 'raw' ) );
    $imgID = get_attachment_id_from_src( $imgSrc );
    $srcSetString = tevkori_get_srcset_string( $imgID, $size );
    $alt = get_post_meta($imgID, '_wp_attachment_image_alt', true);
    return '<img class="' . $class . '" src="' . $imgSrc . '" ' . $srcSetString . ' alt="' . $alt . '" />';
}

So if I call the function with the following parameters, and the 'medium' image size is set to 640px wide:

echo tim_rourke_types_responsive( get_the_ID(), 'website-mobile-image', 'medium', 'website__image-mobile' );

This is the resulting srcset string I see, WAY more than I bargained for:

<img class="website__image-desktop" src="http://timrourke.tim/wp-content/uploads/2015/03/GOAL-screenshot-home-desktop.jpg" srcset="http://timrourke.tim/wp-content/uploads/2015/03/GOAL-screenshot-home-desktop-320x770.jpg 320w, http://timrourke.tim/wp-content/uploads/2015/03/GOAL-screenshot-home-desktop-640x1540.jpg 640w, http://timrourke.tim/wp-content/uploads/2015/03/GOAL-screenshot-home-desktop-1024x2463.jpg 1024w, http://timrourke.tim/wp-content/uploads/2015/03/GOAL-screenshot-home-desktop-1280x3079.jpg 1280w, http://timrourke.tim/wp-content/uploads/2015/03/GOAL-screenshot-home-desktop-1600x3849.jpg 1600w, http://timrourke.tim/wp-content/uploads/2015/03/GOAL-screenshot-home-desktop-2000x4811.jpg 2000w, http://timrourke.tim/wp-content/uploads/2015/03/GOAL-screenshot-home-desktop.jpg 2716w" alt="GOAL Project - screenshot of home page in desktop view">

Thanks for your thoughts!