There are at least some people who use journal styles and the custom journal JS code to have medium landscapes and large portraits. For people with large monitors, it's odd to have a the portraits be so much smaller than the landscapes.
i don't really care what the defaults are, but I'd love to be able to specify sizes explicitly in order to get a 800px high image link. Note that this has no effect at all on existing styles, it just means I can still get a 800px high image.
Thanks! Really, that's great, exactly the functionality I hoped for. Now, here is a suggestion. Why not cache these once you render them? I think that one request is very likely to mean you'll get more.
not a feature I would of thought possible... performance is way better than expected. I fixed my Journal Large hack (because we have old and new Large Portrait sizes now) by setting the size I want, instead of what you have stored. It works fast, even at 10 pics per page. I don't know where the overhead is going, but it works.
not a feature I would of thought possible... performance is way better than expected. I fixed my Journal Large hack (because we have old and new Large Portrait sizes now) by setting the size I want, instead of what you have stored. It works fast, even at 10 pics per page. I don't know where the overhead is going, but it works.
Yeah, if you early adopters could post links to places where you're using this functionality, that'll help me understand how it's used and how we can tune it to work both better and faster.
Yeah, if you early adopters could post links to places where you're using this functionality, that'll help me understand how it's used and how we can tune it to work both better and faster.
Thanks,
Don
Well my custom Journal Large is now resizing my old Large Portraits to the new Large portrait size (600 tall). This page has several portrait pics, all resized to "600 tall" on the fly.
function upsize_image(img, prefix, suffix, img_num, target) {
var caption = document.getElementById('caption'+img_num);
if (caption && upsize_re.test(caption.innerHTML)) {
target = RegExp.$1;
}
target = target.substr(0,1).toUpperCase();
img.src = prefix + "800x600" + suffix;
// if Image has at least one dimension large enough
if(img.width == small_max_width) { // landscape image
img.height = Math.round(2 * img.height);
img.width = Math.round(2 * img.width);
}
if(img.height == small_max_height) { // New portrait image
img.height = Math.round(2 * img.height);
img.width = Math.round(2 * img.width);
}
Thanks! Really, that's great, exactly the functionality I hoped for. Now, here is a suggestion. Why not cache these once you render them? I think that one request is very likely to mean you'll get more.
That's a really great feature delivered in no time!
One thing from a non-programmers standpoint: wouldn't it be better to serve the size I want without regard to the image orientation. Let's say I enter 800x600, but my image is in portrait orientation which currently would deliver a 450x600 image.
I would like SM to ignore the order in which I entered the pixel dimensions, because it should be obvious what I wanted, and deliver a 600x800 sized portrait. This would eraze the need for fancy javascript code checking the image orientation.
Or is there any reason from a programmers standpoint why that would be bad?
Concerning the caching: My IE already caches the custom requested sizes - they're showing up in my cache as '123456789-600x800.jpg'. Haven't checked it on FF though.
Don will correct me if I'm wrong, but I believe that it scales the image so that the maximum of the two dimensions fits. So if you just want to get 800 on the longest side, use 800x800. As he said in his blog, you will never change the aspect ratio of the image delivered. What you do have to do is set the dimensions in the image property for an inline link.
The caching I was thinking about is on the server side. Suppose I make a very popular web page with a custom sized image. Suppose thousands of different people visit it. (I should be so lucky.) From what I understand, the image will have to be rendered thousands of times. But the server could hold onto the rendered custom sized image for a while after each request, avoiding having to rerrender each time.
I'm going to see if I can incorporate this particular feature into the JournalMedium script to allow a lot more flexibility as to image sizes.
Hey, Don, do you have a good sense as to when it's the right thing to ask for a custom size vs just using the image properties in the browser to resize one of the standard sizes?
That's a really great feature delivered in no time!
One thing from a non-programmers standpoint: wouldn't it be better to serve the size I want without regard to the image orientation. Let's say I enter 800x600, but my image is in portrait orientation which currently would deliver a 450x600 image.
I would like SM to ignore the order in which I entered the pixel dimensions, because it should be obvious what I wanted, and deliver a 600x800 sized portrait. This would eraze the need for fancy javascript code checking the image orientation.
Or is there any reason from a programmers standpoint why that would be bad?
Concerning the caching: My IE already caches the custom requested sizes - they're showing up in my cache as '123456789-600x800.jpg'. Haven't checked it on FF though.
Don will correct me if I'm wrong, but I believe that it scales the image so that the maximum of the two dimensions fits. So if you just want to get 800 on the longest side, use 800x800. As he said in his blog, you will never change the aspect ratio of the image delivered. What you do have to do is set the dimensions in the image property for an inline link.
That was my point - it's not working that way:
The same portrait image with 600x800 and 800x600 requested. See?
Yeah, server side caching could save some processing power when the word about this feature spreads.
Don will correct me if I'm wrong, but I believe that it scales the image so that the maximum of the two dimensions fits. So if you just want to get 800 on the longest side, use 800x800. As he said in his blog, you will never change the aspect ratio of the image delivered. What you do have to do is set the dimensions in the image property for an inline link.
The caching I was thinking about is on the server side. Suppose I make a very popular web page with a custom sized image. Suppose thousands of different people visit it. (I should be so lucky.) From what I understand, the image will have to be rendered thousands of times. But the server could hold onto the rendered custom sized image for a while after each request, avoiding having to rerrender each time.
I'm going to see if I can incorporate this particular feature into the JournalMedium script to allow a lot more flexibility as to image sizes.
Hey, Don, do you have a good sense as to when it's the right thing to ask for a custom size vs just using the image properties in the browser to resize one of the standard sizes?
You're exactly right. If you want both landscape and portrait photos to have 800px on the longest, tell me 800x800 and I'll take care of it.
As for using the browser to resize, I wouldn't ever do it. Their resize algorithms are so pitiful, it's sad.
I've been waiting years for them to put a decent algorithm in (they all use simple bilinear, I believe), but since it hasn't happened, I have to throw backend hardware at the problem.
It uses the standard smugmug sizes where possible and allows users access to custom sizes. I expect that at least some people will use it, so it's one of the examples Don asked for.
As a pro user who rarely allows for large view (I'm not fond of people ripping off my photos-- this still happens in medium view, of course), I'm fine with the settings right now. If I want XL, I simply enable original with a watermark-- on an 8 MP camera that is plenty big enough to fill several screens!
I agree. Why can't those who want XL just use "originals"?
I agree. Why can't those who want XL just use "originals"?
Because Original can be 3000px by 2000px and greater. So viewing that on my screen (1600x1200) that would be too big, and missing a part. And an 800px wide photo looks pretty small on my screen
Because Original can be 3000px by 2000px and greater. So viewing that on my screen (1600x1200) that would be too big, and missing a part. And an 800px wide photo looks pretty small on my screen
Hmm..., good point. It seems what might be more useful is if there were a screen-detection JS and that small, medium and large were somehow calculated on that scale (of course, this could get wieldy). I do a lot of my styling on my personal computer, which is a 14" ibook at a 1024x768 resolution (b/c the darned thing doesn't go any higher). Obviously, large is just fine for that, often pushing most of the page out of view. But when I check those same pages on my computer at work, which has a lot more screen space (19") and higher resolution (12..something or other), large is a better fit. It would be nice if pics were always a certain percentage of the visible screen. that would keep the rest of the design more constant.
Of course, musing about all of these things is relatively easy, but implementing them in a way that won't slow down load times is not (and I'm not a programmer, so it's easy to be naïve).
Maybe I've had a long day, but I'm having trouble understanding the need for this change and I don't find much merit in any of the proposed solutions.
XL is definately needed on 17" monitors running 1600x1200 etc., which is pretty much common. The L images look tiny on them. Its high time we got XL, or even XXL which is 1280x1024 in 3:2 format.
I agree. Why can't those who want XL just use "originals"?
That would be quite a big jump from L to Original if you're uploading from the new Nikon D2Xs, which pumps out 4288 x 2848 pixels (12 effective megapixels).
Mainly because of the fact that you have 6 columns and 7 rows of thumbnails plus the large image.
The all thumbs version is a pain as you have to go to the big image and the return to the all thumbs view for an overview.
The standard smugmug view only has 3 x whatever thumbnails, which means customers keep having to turn the page over and over again,
So in my world, the above would be great... I know that's not the technical issue you're all discussing, but it's the thing that's most important to THIS user from a viewing point of view.
I'm not seeing any wiiiide? Can you explain further please
For me it looks in both IE6 and FF like this. I even can't make the window any smaller (than 1024px wide) without having horizontal scrollbars appear. This wasn't the case a couple of days ago - back then every smugmug box was defaulted to 750px wide or something like that unless you messed with your customizations. I didn't change a thing in my customizations.
For me it looks in both IE6 and FF like this. I even can't make the window any smaller (than 1024px wide) without having horizontal scrollbars appear. This wasn't the case a couple of days ago - back then every smugmug box was defaulted to 750px wide or something like that unless you messed with your customizations. I didn't change a thing in my customizations.
For me it looks in both IE6 and FF like this. I even can't make the window any smaller (than 1024px wide) without having horizontal scrollbars appear. This wasn't the case a couple of days ago - back then every smugmug box was defaulted to 750px wide or something like that unless you messed with your customizations. I didn't change a thing in my customizations.
On my laptop with 800x600 as resolution it looks like it used to look on my 1280er monitor in terms of wide of the gallery description. See here - just focus on the gallery description - ignore the header.
Aparently the thing senses my resolution and adjustes accordingly, but it doesn't seem to care about the browser window size.
On my laptop with 800x600 as resolution it looks like it used to look on my 1280er monitor in terms of wide of the gallery description. See here - just focus on the gallery description - ignore the header.
Aparently the thing senses my resolution and adjustes accordingly, but it doesn't seem to care about the browser window size.
Nope, no change. I tried narrowing down the problem with the FF webdev bar. Removing all the CSS from smugmugblack.css let's me resize my browser window again with wrapping the text correctly. This is my smugmug black - maybe anyone can try including the content of it into a html-only page of your own.
Also it's not the only page where it happens to me - it's the same in my guestbook.
Sebastian
EDIT: Feel kind of stupid now - it's just that through flashing my cookies my standard traditional view selection got replaced with smugmug style (which is 960px wide in spite of the 750px wide traditional). That's why my html only pages looked wider to me than before. Haven't looked at a single gallery since the flushing and therefore haven't noticed the template change. :lol
EDIT: Feel kind of stupid now - it's just that through flashing my cookies my standard traditional view selection got replaced with smugmug style (which is 960px wide in spite of the 750px wide traditional). That's why my html only pages looked wider to me than before. Haven't looked at a single gallery since the flushing and therefore haven't noticed the template change. :lol
What's all the hubbub? I requested the XL feature some months ago through Smugmug feedback, thinking I was original, before I discovered Dgrin. :
To all of those that might be puzzled (who incidentally likely have 13 inch monitors and my larges look BRILLIANT to. Ha.) I'd like to explain a little of what I'm personally looking for and why. My primary interests are sports and portrait photography and I do my best to combine the two. I take great pains to convert from RAW, color correct, sharpen or not and do touchups on nearly every image I produce. But when I spend an hour on a 3/4 portrait, sometimes even a headshot, add some eye catchlight, burn/dodge some under/overexposed areas and view it as a Large on Smugmug, you can hardly tell the subject even HAS eyes, let alone how spectacular the image will look as a 20x30 poster. As it stands, my options are to a) allow originals, in which detail could be seen (across about 4 screens), in which NOBODY with any computer savvy will actually PAY for a print or b) make a separate gallery after resizing every image to say 1600x1200 and allowing originals or c) similarly crop a section of the original (enlarged to show detail, as they say). Still, none of these solutions protect my work, as the watermark feature cannot be added to the original, nobody is real concerned with protecting a thumb, small or possibly medium, and anything above large (subjectively including large) could yield a good stolen print.
All the hubbub; styles-schmyles. I danno if I'm just an utter noob (yes I do), but even at 1600x1200 with a 23" monitor, when I click on one of my larges, with any style set, I get the single-image-view. Yes, I know, I am a noob and this could probably be fixed, however, that's fine. If the image is too large for the current style, I get a single image view. If the single image is too large (original or extra-crispy), I get scrollbars, and on clicking that, I get more of a full screen scroller. This is JUST FINE by me (although I wouldn't mind seeing the scrollbars dispatched with and replaced by a hand-grabber-draggy-thingie (technical term)).
I respect the fact that Smugmug wants to stay modular and anticipate forward compatibility, but I think you should walk before running. I don't think anyone expects Smugmug to anticipate someone having a 4000x1000 50" LCD and having a style and theme all set to appease them. If it's too big to fit the current style, go to single image view. All I'd personally like is a 871987239-XL.JPG of at least 1280 and the ability to watermark it or not. Nobody HAS to click XL if they don't like it; nobody HAS to allow XL on their page if they're not comfortable. Intentionally nerfing games because some people still use IBM XTs or making web pages predominantly text based because some are still 56K are not the way to make money or progress and many suffer for the sake of the few.
With all that said (longwinded), I'd just like to point out this is just IMHO. I love all you guys at Smugmug and Dgrin and everyone has valid concerns (no flames ). It's all about personal choice.
Comments
Your wish, or something like it, is my command.
Thanks! Really, that's great, exactly the functionality I hoped for. Now, here is a suggestion. Why not cache these once you render them? I think that one request is very likely to mean you'll get more.
wow..... I think that is really cool
not a feature I would of thought possible... performance is way better than expected. I fixed my Journal Large hack (because we have old and new Large Portrait sizes now) by setting the size I want, instead of what you have stored. It works fast, even at 10 pics per page. I don't know where the overhead is going, but it works.
Yeah, if you early adopters could post links to places where you're using this functionality, that'll help me understand how it's used and how we can tune it to work both better and faster.
Thanks,
Don
Well my custom Journal Large is now resizing my old Large Portraits to the new Large portrait size (600 tall). This page has several portrait pics, all resized to "600 tall" on the fly.
function upsize_image(img, prefix, suffix, img_num, target) { var caption = document.getElementById('caption'+img_num); if (caption && upsize_re.test(caption.innerHTML)) { target = RegExp.$1; } target = target.substr(0,1).toUpperCase(); img.src = prefix + "800x600" + suffix; // if Image has at least one dimension large enough if(img.width == small_max_width) { // landscape image img.height = Math.round(2 * img.height); img.width = Math.round(2 * img.width); } if(img.height == small_max_height) { // New portrait image img.height = Math.round(2 * img.height); img.width = Math.round(2 * img.width); }One thing from a non-programmers standpoint: wouldn't it be better to serve the size I want without regard to the image orientation. Let's say I enter 800x600, but my image is in portrait orientation which currently would deliver a 450x600 image.
I would like SM to ignore the order in which I entered the pixel dimensions, because it should be obvious what I wanted, and deliver a 600x800 sized portrait. This would eraze the need for fancy javascript code checking the image orientation.
Or is there any reason from a programmers standpoint why that would be bad?
Concerning the caching: My IE already caches the custom requested sizes - they're showing up in my cache as '123456789-600x800.jpg'. Haven't checked it on FF though.
Sebastian
SmugMug Support Hero
The caching I was thinking about is on the server side. Suppose I make a very popular web page with a custom sized image. Suppose thousands of different people visit it. (I should be so lucky.) From what I understand, the image will have to be rendered thousands of times. But the server could hold onto the rendered custom sized image for a while after each request, avoiding having to rerrender each time.
I'm going to see if I can incorporate this particular feature into the JournalMedium script to allow a lot more flexibility as to image sizes.
Hey, Don, do you have a good sense as to when it's the right thing to ask for a custom size vs just using the image properties in the browser to resize one of the standard sizes?
The same portrait image with 600x800 and 800x600 requested. See?
Yeah, server side caching could save some processing power when the word about this feature spreads.
Sebastian
SmugMug Support Hero
You're exactly right. If you want both landscape and portrait photos to have 800px on the longest, tell me 800x800 and I'll take care of it.
As for using the browser to resize, I wouldn't ever do it. Their resize algorithms are so pitiful, it's sad.
I've been waiting years for them to put a decent algorithm in (they all use simple bilinear, I believe), but since it hasn't happened, I have to throw backend hardware at the problem.
Don
Sebastian
SmugMug Support Hero
Making the large view smaller was a mistake IMO, and it's time to rectify it.
http://mikekatz.smugmug.com/
It uses the standard smugmug sizes where possible and allows users access to custom sizes. I expect that at least some people will use it, so it's one of the examples Don asked for.
Here are a few galleries of mine which use it:
http://rutt.smugmug.com/gallery/1444752
http://rutt.smugmug.com/gallery/1421224
I agree. Why can't those who want XL just use "originals"?
www.ivarborst.nl & smugmug
Hmm..., good point. It seems what might be more useful is if there were a screen-detection JS and that small, medium and large were somehow calculated on that scale (of course, this could get wieldy). I do a lot of my styling on my personal computer, which is a 14" ibook at a 1024x768 resolution (b/c the darned thing doesn't go any higher). Obviously, large is just fine for that, often pushing most of the page out of view. But when I check those same pages on my computer at work, which has a lot more screen space (19") and higher resolution (12..something or other), large is a better fit. It would be nice if pics were always a certain percentage of the visible screen. that would keep the rest of the design more constant.
Of course, musing about all of these things is relatively easy, but implementing them in a way that won't slow down load times is not (and I'm not a programmer, so it's easy to be naïve).
FB:https://www.facebook.com/TanveersPhotography
Site :http://www.tanveer.in
Blog :http://tsk1979.livejournal.com
That would be quite a big jump from L to Original if you're uploading from the new Nikon D2Xs, which pumps out 4288 x 2848 pixels (12 effective megapixels).
Ok, folks, I haven't read the whole thread, because frankly, it all goes over my IT challenged head..
BUT I would strongly support an option like the one shown here:
http://onethumb.smugmug.com/gallery/1377106/1/64999146/Medium
Mainly because of the fact that you have 6 columns and 7 rows of thumbnails plus the large image.
The all thumbs version is a pain as you have to go to the big image and the return to the all thumbs view for an overview.
The standard smugmug view only has 3 x whatever thumbnails, which means customers keep having to turn the page over and over again,
So in my world, the above would be great... I know that's not the technical issue you're all discussing, but it's the thing that's most important to THIS user from a viewing point of view.
Anybody else seeing this on your sites?
Sebastian
SmugMug Support Hero
I'm not seeing any wiiiide? Can you explain further please
Portfolio • Workshops • Facebook • Twitter
Am I going nuts?
Sebastian
SmugMug Support Hero
Looks OK to me - FF on WinXP.
Swim for Them | WellmanHouse.net | AlbumFetcher | SmugShowBuilder
Aparently the thing senses my resolution and adjustes accordingly, but it doesn't seem to care about the browser window size.
Puzzled greetings,
Sebastian
SmugMug Support Hero
Flush your cache and temp files?
Portfolio • Workshops • Facebook • Twitter
This is my smugmug black - maybe anyone can try including the content of it into a html-only page of your own.
Also it's not the only page where it happens to me - it's the same in my guestbook.
Sebastian
EDIT: Feel kind of stupid now - it's just that through flashing my cookies my standard traditional view selection got replaced with smugmug style (which is 960px wide in spite of the 750px wide traditional). That's why my html only pages looked wider to me than before. Haven't looked at a single gallery since the flushing and therefore haven't noticed the template change. :lol
SmugMug Support Hero
Problem solved, yes?
Portfolio • Workshops • Facebook • Twitter
Sebastian
SmugMug Support Hero
I requested the XL feature some months ago through Smugmug feedback, thinking I was original, before I discovered Dgrin.
To all of those that might be puzzled (who incidentally likely have 13 inch monitors and my larges look BRILLIANT to. Ha.) I'd like to explain a little of what I'm personally looking for and why. My primary interests are sports and portrait photography and I do my best to combine the two. I take great pains to convert from RAW, color correct, sharpen or not and do touchups on nearly every image I produce. But when I spend an hour on a 3/4 portrait, sometimes even a headshot, add some eye catchlight, burn/dodge some under/overexposed areas and view it as a Large on Smugmug, you can hardly tell the subject even HAS eyes, let alone how spectacular the image will look as a 20x30 poster. As it stands, my options are to a) allow originals, in which detail could be seen (across about 4 screens), in which NOBODY with any computer savvy will actually PAY for a print or b) make a separate gallery after resizing every image to say 1600x1200 and allowing originals or c) similarly crop a section of the original (enlarged to show detail, as they say). Still, none of these solutions protect my work, as the watermark feature cannot be added to the original, nobody is real concerned with protecting a thumb, small or possibly medium, and anything above large (subjectively including large) could yield a good stolen print.
All the hubbub; styles-schmyles. I danno if I'm just an utter noob (yes I do), but even at 1600x1200 with a 23" monitor, when I click on one of my larges, with any style set, I get the single-image-view. Yes, I know, I am a noob and this could probably be fixed, however, that's fine. If the image is too large for the current style, I get a single image view. If the single image is too large (original or extra-crispy), I get scrollbars, and on clicking that, I get more of a full screen scroller. This is JUST FINE by me (although I wouldn't mind seeing the scrollbars dispatched with and replaced by a hand-grabber-draggy-thingie (technical term)).
I respect the fact that Smugmug wants to stay modular and anticipate forward compatibility, but I think you should walk before running. I don't think anyone expects Smugmug to anticipate someone having a 4000x1000 50" LCD and having a style and theme all set to appease them. If it's too big to fit the current style, go to single image view. All I'd personally like is a 871987239-XL.JPG of at least 1280 and the ability to watermark it or not. Nobody HAS to click XL if they don't like it; nobody HAS to allow XL on their page if they're not comfortable. Intentionally nerfing games because some people still use IBM XTs or making web pages predominantly text based because some are still 56K are not the way to make money or progress and many suffer for the sake of the few.
With all that said (longwinded), I'd just like to point out this is just IMHO. I love all you guys at Smugmug and Dgrin and everyone has valid concerns (no flames
SteveM - Pro subscriber
www.downriverphotography.com
BizDev Account Manager
Image Specialist & Pro Concierge
http://www.downriverphotography.com