pixelate transformation not working for me
I use the latest Angular 10 and the latest Cloudinary versions as of today. Here's a screenshot of my image.
Here's a link to a recording I made of our application. Instead of showing a pixelated image it shows the browser's default "bad image" picture. What am I doing wrong?
Hi, thanks for reaching out!
In order for me to better understand the described issue, could you kindly check for the "x-cld-error" header, and let me know of its value? In addition, could you try the simplified image tag below and let me know if the "bad image" is displayed?
It is actually no error coming back from Cloudinary. The no image means the image is still loading. I took at the image urls and saw something interesting.
Attaching a video:
The first 13 images in my card list does not contain e_pixelate on the url. I'm thought it had something to do with loading="lazy" and what it does with the viewport so I removed it, but it did not change the fact that the first 13 images never contains e_pixelate on the url.
So definitely some monkey business with your viewport code I am guessing here.
Are you referring to our lazy loading feature?
You can read more about it here: https://cloudinary.com/blog/how_to_get_killer_page_performance_with_angular_lazy_loading#lazy-load-cloudinary
Looking forward to your response,
I've consulted the originally described issue with the dev team, and we're still looking into it, however, we didn't manage to reproduce the behavior on our end yet. This means that the issue might be related to your specific environment/project.
In order for us to further investigate, could you kindly provide the below information?
- Could you confirm whether the issue persists when omitting the "class" attribute?
- Does the issue occur with different placeholder types? Can you try using the "blur" (default) type as well?
- Does the issue reproduces with all images, every time, or, does it happen intermittently?
- Could you try setting the "public-id" in a non-dynamic manner? (e.g - setting it to "sample")
- Could you try setting the "default-image" to "sample" as well?\
- Is there any live/staging site we could use in order to see the issue and try to debug it?
Any additional information would be greatly helpful.
Regarding your observation -
"The first 13 images in my card list does not contain e_pixelate on the url. I'm thought it had something to do with loading="lazy" and what it does with the viewport so I removed it, but it did not change the fact that the first 13 images never contains e_pixelate on the url."
In general, that's the designed behavior. When using lazy loading, requests for the pixelated images are sent on load, and requests for the actual images are sent when entering the viewport. It looks like the component/page was loaded into the relevant viewport, and that caused the requests for the actual (non-pixelated) images to be sent before. In that case, it still makes sense to send requests for both place holders and images, so the end-user can see the placeholder until the image loads.
When omitting the loading="lazy", both the pixelated ant actual images are being requested on loading time. That's because the pixelated images are downloaded much faster, and could be displayed until the actual images are downloaded.
Does that make sense?
Looking forward to your reply regarding the above followup questions.
I went through the steps you mentioned. Nothing changes the fact that the first 13 images do not have e_pixellate on it. Blur also did not change that. When I removed loading=lazy, 30 of the first images did not have e_pixellate on them.
I have made our traveliko.com staging environment available for you to look at. Unlike our production environment, I've removed our custom image loader code and I am using your cl-image tag with lazy loading and the pixelate placeholder. The homepage is a good place to see this in action:
Following your previous screen recording, I tried to work on the staging link provided by you, I noticed the search stalls when any keyword is typed. The loading wheel keeps spinning in the search area. No results are returned. Network tab shows one GET request to
Request URL: https://staging-www.traveliko.com/ngsw.json?ngsw-cache-bust=0.647851733230863
Is it possible to provide steps on this? or any additional information that can be useful.
I'd like to clarify a few things in order to make sure we're on the same page. When using lazy loading with a placeholder (e.g pixelate), requests for the actual images (i.e - not the placeholders) are being performed as soon as the images enter the viewport, or, a buffer of pixels around the viewport.
This means that URLs without e_pixelate are supposed to be sent as soon as the images enter this "buffered viewport". My assumption is that those 13 requests are made for images that are located within that space. Thus this behavior seems to be as designed.
In addition, notice, that each of the images with non-pixelated requests has another request (below the 13 requests) that does have the e_pixelate parameter. This serves the functionality of the "place-holders" - showing a lighter version of the image until the actual heavier version loads.
Does that make sense?
Please let me know if you have any additional questions.
Thank you for the clarification. What I am seeing when I remove loading=“lazy” is that 30 of the first images not having e_pixelate on the url. What I want is that every image is served up w the e_pixelate tag. Otherwise, the user sees this browser native placeholder of a missing image until the actual image loads. Isn’t that what the pixelate placeholder was designed for? To remove that user experience? Until your placeholder functionality came along, we had to make use of the imageOnLoad functionality w an extra div overlay and it was not a pretty solution.
Would love to know how to properly make use of the new placeholder so users first see the pixelated version until the real image finishes loading.
Thank you for your reply, and I apologize for the back and forth.
Of course, users should not see the browser's default placeholders (the broken image icon).
In order for me further investigate and trace the issues' origin, can you confirm that the staging environment is currently running?
How can I reproduce the issue with the staging environment? Do I need to register?Currently, I can only see this interface.
I just wanted to let you know that our dev team is currently investigating the issue, and I'll let you know about any insight we have regarding it.
In addition, we'll let you know if/when we need your staging environment to be running - for testing and reproduction purposes.
I think it is best to create a support ticket at firstname.lastname@example.org (or submit a request via our support center) and continue the correspondence there. If that is alright with you, kindly open a ticket and mention this forum thread as a reference (you can also mention my name). However, if you prefer continuing the thread here, that's alright as well.
I am having the same issue with @nuxt/cloudinary module. using the image component it seemed to me that the class applied on the Vue <cld-image> component was causing this. But now it just seems random after ive been testing it its happening intermittently . Can you advise on best practice here ?
Post is closed for comments.