Hi team,
It appears that the file upload plugin strips the embedded ICC profile from images.
I guess that this is due to how the pupload library works, loading the image data into a variable and then saving it as a new file (I’m stretching the limits of my knowledge coming to this conclusion lol).
Is there any way to make it so that image files are uploaded as-is without any processing at all, with the original file embedded into the forum post?
Cheers
Steve
sorry, what is ICC profile??
Are you limiting the size or dimensions of the image? I am not sure it does any processing if it can just be uploaded as is…
Hi Mr Papa, thanks for your reply.
ICC profiles are embedded into image files to make sure the colours in an image look the same on my screen compared to if you viewed the same image on your screen.
sRGB is the standard profile for viewing online. You can see what profile (if any) an image file has embedded by viewing its exif data.
This is a handy website for checking the exif data to see what profile any given image has:
http://exif.regex.info/exif.cgi
Here’s a blog post that explains the importance of this better than I can:
http://regex.info/blog/photo-tech/color-spaces-page1
I have tested on my forum and all images I upload have their exif data and icc profile stripped.
When I upload the same file through the wordpress media uploader, the exif and icc remain in tact. If you’d like to see the difference first hand, you can enter these examples into the above exif viewer page:
Uploaded via wordpress: https://photomasteryclub.com/wp-content/uploads/2018/02/coalcliffskyswap.jpeg
Uploaded via SP file uploader: https://photomasteryclub.com/wp-content/sp-resources/forum-file-uploads/stevea/2018/02/coalcliffskyswap.jpeg
See the Basic Image Information section for each.
I’ve experienced a similar issue in the past when coding a php uploader (years ago, I’ve since forgotten most of what I knew about PHP). The issue was that when I loaded an image files data into a variable and then re-saved that data as a new image file, exif data and ICC profiles didn’t carry across to the new file. The solution was to read the exif and ICC data from the original file, and then manually (in the code) put that data back into the new file.
Or, just upload the file and any moving, renaming etc was done to the original file itself, rather than load it into PHP and save it again as a new file.
I’ve tested as many combinations of plugin settings as I can think of to make sure the image isn’t being processed or having anything done to it, but it’s still losing the exif and ICC. I even tried making JPEG an “other” file type to see if the uploader handled it differently, but it produces the same issue.
Wether you can potentially help or not will depend on whether its the pupload code that’s doing it, or if its the simple-press code thats doing it after pupload has uploaded the file in tact.
Thanks for looking into this for me, I appreciate it’s potentially a big thing to land on your desk!
Cheers
It’s an interesting question and I admit to not realising that plupload did strip the ICC data. Plus I assume that the WP form of the uploader can preserve it as it has been extensively rewritten and customised.
Our first job then is going to be some research… Let’s see what we can find.
And pupload has much newer versions available….. Maybe it might also take care of the occasional bootstrap vs jquery conflicts or conflicts with themes.
Yellow Swordfish said
is your website running ubnder html5? I.e., a doctype of simply ‘html’?
This is the first couple of lines in my page source:
<!doctype html>
<html class=”no-js” lang=”en-US” prefix=”og: http://ogp.me/ns#”>
<head>
we tend to stay up to date with plupload… but since we are reading to release 5.8 as a major release, we havent updated in last couple months… 5.8 does include the latest (well, the plugin version that goes with 5.8)… but the next point may be more critical…
the html5 doctype question was asked because plupload fixed this issue a few years ago, but it was only in html5 (not 4) and flash… flash has since been removed by us for security reasons… so if you have html5, it should already handle it…
as to earlier comment, we dont load the image into memory (variable as you called it)… we do just move/rename it… however, if the image has to be resized, rescaled or image quality dropped, then its handed over to the GD library to do what it does… I suspect it definitely reads it into memory in order to manipulate it…
so to verify, you have uploaded a very small image, one that you know is smaller in size (both dimensions and storage) and it lost it too?
@yellow-swordfish is planning to test himself but may be away for few days… Afraid I have no idea where this info is or how to read it – not a photo or graphics guy… 🙁
Yes, just to confirm, I’ve tested myself with images well within the pixel dimension and file size limits and they are affected in the same way.
Another reason I’m certain they’re being processed in some way is that the file size always changes after it’s uploaded.
Anyway, looking forward to hearing any updates in due course.
thanks again
It looks like the culprit is probably the php ‘GD’ library which handles any resizing that may be needed. This is not definite but seems likely from my reading to date.
You should be able to test this theory by removing the maximum width, height and filesize in the uploader options and uploading a fairly small image file with the ICC intact. I believe this should remove any GD processing of the core image. @mr-papa – can you confirm this?
Let us know if this behaves. The trouble is I am unsure whether the GD library has been changed to accommodate this in latest versions – it can be quite difficult sometimes to find definitive answers – but I am still searching.
yes, but OP claims to have done that… perhaps I am missing something, but all that should happen if the file needs no processing is a simple php move/copy function…
Hey guys, just checking in to see if you have any further insights into this issue.
I’ve tested intensively and can conclude that even when there are no restrictions on file size/dimensions etc, it is being “processed” and the EXIF info is being stripped. I’m pretty sure there’s also some compression happening too because the file size becomes smaller once uploaded.
Cheers
As I am not too knowledgeable about this can you tell me exactly what tools you are using to determine the change and loss of data so I can also run some tests?