-
Posts
-
OK, ran some test, may have found a solution. Here’s what I did: I took an image (Morpho Butterfly) that was displaying 0 as largest size, and used Irfanview to modify the IPTC data (I’d used Irfanview to set the data, originally) to differentiate the new test image from the one already published– titled it Morpho Butterfly 72, since the original shows as rez 72dpi when I open it in Adobe Photoshop. Then, using Adobe Photoshop, I changed the dpi to 300, being careful to turn off resampling so that the picture resolution remained unchanged (no upsizing). The resulting image (which has the same number of pixels as the 72dpi image) I then edited in Irfanview to change the IPTC data titling it to Morpho Butterfly 300. My plan was to upload the two new images to see if any changes resulted in how Symbiostock handled the images.
First, however, I had change my upload folder that I’d bookmarked in my FTP program (I’ve not had luck with the software uploader in Symbiostock). Apparently that location changed between 2.55 and 2.8.2 somewhere along the line. The uploader page told me where to upload to, but I had to create the directory and folder– Symbiostock didn’t create it automatically.
I then used my FTP program to upload the two images, which Symbiostock found right away, and then processed them. The result was enlightening, and I hope the pattern holds true for my other images:
The Morpho Butterfly 72 image was mishandled by the image processor, which ignored the IPTC data I’d included. This had happened to me before with many of my other images. When published, the large size shows a size of 0 pixels.
The Morpho Butterfly 300 image was handled correctly by the image processor and included the IPTC data. When published, it correctly shows the large image size as 2120. An interesting thing is that even though I’d set the dpi to 300 for this image, it shows as 72 (screen rez) for the three smaller sizes, and 300 dpi (good print rez) for the large size.
If this pattern holds it means:
1. There is a solution to the problem
2. I’ve got a lot of work to do to alter the dpi on my other images, reupload, reprocess, and edit them.Thanks for all the help, especially from Christine, and here’s hoping. I’ll try to update this thread as things proceed.
Congrats, scenicoregon, for having solved this tough problem!
I find it a bit disturbing that the image processor can be derailed by iptc data. Which one did/do you use: GD or ImageMagick?
An interesting thing is that even though I’d set the dpi to 300 for this image, it shows as 72 (screen rez) for the three smaller sizes, and 300 dpi (good print rez) for the large size.
The dpi shown for published images is hardcoded (i.e. not pulled from iptc at all). Under a certain image size limit it is 72 dpi and above that limit it is 300 dpi. I am not sure, though, what the exact limit actually is…
OK, my initial tests seeming to indicate that the large size showing as 0 pixels was caused by the image being configured at 72dpi appear to have been confirmed. I took 40 images that previously had shown 0 pixels for size, used Irfanview to batch process them to change only the dpi setting from 72 to 300 (no resampling or upsizing or change of resolution), uploaded them and processed them, and presto! not a single one exhibited the previous problem! And, every single one showed all of the IPTC data, when before about a quarter of them would have lost all of that data in processing.
I should point out that many of the images that never exhibited the problem still are set at 72dpi, but that Symbiostock shows them at 300dpi for the large size if appropriate. I’ve still no idea why they processed and the others didn’t, but at least I now know how to get around the problem.
The image processor I was using was ImageMagick. It has always been a little troublesome for me– for example, when I ran this set of 40 the first time, only 31 processed. When I ran it again on the remainders, I got five or so error messages about oversized headers (no error messages the first run through), but they all processed. I ended up with one extra image, and discovered one that had processed twice, but one of those had no preview and only some of the IPTC data. I’ve learned that for me, it likes to be fed images in very small batches, and if some images are particularly hard for it to process for some reason, then even one at a time.
Christine- I haven’t checked yet to see if you emailed me, but at this point I’m feeling I have enough success overcoming this problem that I don’t need to send you images. Thanks for the offer, though.
Cascoly- Send my slides to India! All the way from the U.S., that scares the heck out of me! I’ve had agencies here on the same coast manage to lose my slides before, seems like an overseas trip is asking for trouble, but I’m glad it worked out well for you. Thanks for the tip, though.
OK, on to new issues, which I’m sure I’ll find!
Thank you for posting this follow-up. It might come in handy when one of us runs into similar troubles.
On a side note: It is known that we have to process images in smaller batches because of time and/or memory restrictions of the hosting server. In file php.ini you can up those restrictions within reasonable limits by setting following variables (my settings in brackets):
memory_limit (256M), upload_max_filesize (80M), max_execution_time (600), max_input_time (120)
I regularly process batches of 50 files, some of which might be hi-res panos with up to 100 MP, and very rarely have the image processor terminated.
I hope this will contribute for a much smoother ride uploading, now, that you’ve overcome this huge bump. Good luck!
@scenicoregon wrote:
Cascoly- Send my slides to India! All the way from the U.S., that scares the heck out of me! I’ve had agencies here on the same coast manage to lose my slides before, seems like an overseas trip is asking for trouble, but I’m glad it worked out well for you. Thanks for the tip, though.
well, first off, the US postal service doesn’t get to mess things up for very long! priority mail to india is quite reliable, and I’ve done it about 10 times now
In which directory do I find the php.ini file, or is that something I’d have to create, and if so, in which directory does it go– and got a template?
ThanksYour php.ini is usually in your public.html file
http://kerioakimaging.com - trying to reopen
http://nail-art-at.kerioak.com - Art and Nail Art
You must be logged in to reply to this topic.