It is possible to physically rotate a JPEG image in 90-degree increments without losing quality. Other things can be done too like cropping, flipping, and converting to greyscale. I do not know if Lightroom does this (I would be surprised if they don't), but the way to test it would be to rotate it, save it as a new file, rotate it back, save it as a new file. Then compare bits to the original.
....You may be pleased to know that here at SmugMug we employ this lossless technique when doing image rotations....
- Greg
I don't worry much about the lossy issues here at Smug, because Smug isn't doing anything to the originals I have on my computer or backed up; they just have copies. Of course though, it's always good to know, & I suppose if someone got a humongous print made from a jpg, they might see compression artifacts. Also, if something went wrong with all of our backups elsewhere, it's good to know we have the security of our collection here. I'm going to look up this stuff in my DAM book again, whenever I can find the _ _ _ _ book! He goes through all these programs & how they work internally. One thing though-- It's the simple fact of opening & re-saving the jpg that's a big part of the problem, & a soft rotation doesn't require that.
I don't worry much about the lossy issues here at Smug, because Smug isn't doing anything to the originals I have on my computer or backed up; they just have copies. Of course though, it's always good to know, & I suppose if someone got a humongous print made from a jpg, they might see compression artifacts. Also, if something went wrong with all of our backups elsewhere, it's good to know we have the security of our collection here. I'm going to look up this stuff in my DAM book again, whenever I can find the _ _ _ _ book! He goes through all these programs & how they work internally. One thing though-- It's the simple fact of opening & re-saving the jpg that's a big part of the problem, & a soft rotation doesn't require that.
There are two lossless ways to rotate a JPEG. One involves only changing a metadata tag. The other involves rotating the actual image without decompressing/recompressing and is only possible if the image's size (height and width) exactly aligns as a multiple of the JPEG compression block size. This is often the case these days (but not always).
In any case, I don't know which method Adobe Bridge uses, but everything I've read says that even as of several years ago, Bridge used a lossless JPEG rotation. Either method should work before uploading to Smugmug.
The other involves rotating the actual image without decompressing/recompressing and is only possible if the image's size (height and width) exactly aligns as a multiple of the JPEG compression block size. This is often the case these days (but not always)..
Correct me if I am wrong here, but that is dependent on MCU size of the jpeg is, right? Most of the time it is 8x8, but I've heard of others (16x8, 8x16, 16x16). As long as you can fill the entire jpeg with those blocks (and not have anything left over), it can be rotated lossless. The safest thing to do, IMHO, is make sure the image is some multiple of 16 in width and height and that will almost always work out.
Do I have that about right? You probably know more about the intimate details of this then I do...
Correct me if I am wrong here, but that is dependent on MCU size of the jpeg is, right? Most of the time it is 8x8, but I've heard of others (16x8, 8x16, 16x16). As long as you can fill the entire jpeg with those blocks (and not have anything left over), it can be rotated lossless. The safest thing to do, IMHO, is make sure the image is some multiple of 16 in width and height and that will almost always work out.
Do I have that about right? You probably know more about the intimate details of this then I do...
- Greg
The interesting use case here is with JPEGs right out of the camera so there's no "make sure the image is a particular size". It is what it is for the cameras you own. Yes, I believe if it is the MCU size that is the relevant block size.
The best thing would be if Bridge was just setting the same metadata that a modern camera sets for orientation. That would work with all image sizes and works with Smugmug. But, I don't know which method Bridge actually uses and I can't find it on the internet. I think we're probably at the point where Anna Lisa should just try it.
Correct me if I am wrong here, but that is dependent on MCU size of the jpeg is, right? Most of the time it is 8x8, but I've heard of others (16x8, 8x16, 16x16). As long as you can fill the entire jpeg with those blocks (and not have anything left over), it can be rotated lossless. The safest thing to do, IMHO, is make sure the image is some multiple of 16 in width and height and that will almost always work out.
Do I have that about right? You probably know more about the intimate details of this then I do...
- Greg
I'd never heard this before, until Andy mentioned it awhile back. But anyway, I can't imagine many photogs using that criteria for cropping or uploading; like John says, it's whatever comes out of your camera, & usually you only crop if you feel you have to for various reasons, & you're gonna do that on a visual basis or because a certain format is needed. To be size-constrained just because of lossless rotating isn't something I'd be interested in. Ok, as soon as I get through my tax appt. & some work tomorrow, I'll try some of these other things.
I'd never heard this before, until Andy mentioned it awhile back. But anyway, I can't imagine many photogs using that criteria for cropping or uploading; like John says, it's whatever comes out of your camera, & usually you only crop if you feel you have to for various reasons, & you're gonna do that on a visual basis or because a certain format is needed. To be size-constrained just because of lossless rotating isn't something I'd be interested in. Ok, as soon as I get through my tax appt. & some work tomorrow, I'll try some of these other things.
Once you're cropping, all bets are off. The JPEG is getting recompressed in that operation anyway. The point of the lossless rotation is an image that is unmodified in other ways. I'd be extremely surprised if Bridge didn't do exactly what you want. Before Lightroom came out, I used Bridge extensively (even with cameras that didn't have rotation sensors) and it worked great for me in this regard.
Cool. Love to hear about the inner workings that caused this bug. This is exactly how a hard-to-reproduce bug like this gets solved. A smart developer collects as much info as they can and then analyzes how this could possibly happen in the system and then builds defenses around it. Kudos to you Greg!
It's way, way, way, way faster than rotating on Smugmug and no matter how much Smugmug improves their tool, it will always be faster on the local computer.
Ummm...not for this poor chap. :cry.
I used to run massive batch operations via irfanview to rotate images prior to using SM when I was hosting images myself. The actual rotation time may be faster, but there's still the setup. SM's interface is pretty nice. Most programs aren't setup for batch rotation and a nice interface.
Feel free to post here if you continue to have any issues with it.
- Greg
YES!!! We'll see what happens. I've so behind on uploading/processing that I will be working on thousands of images in the next few weeks, and many of them needing rotation. If I see anything funny, I'll report back.
Just out of curiosity, where was the problem in the locking? Was it simple falling off an array or something more?
Wow! Seriously?? That was fast!! Can't wait to try it out! Samir seems to do enormous batches at a time, so he ought to be able to give it a run for its money! Thanks for letting us know.
I will be shortly. I'm about to get into my busy season, which means 1000+ images a week for the next 9 months...
I used to run massive batch operations via irfanview to rotate images prior to using SM when I was hosting images myself. The actual rotation time may be faster, but there's still the setup. SM's interface is pretty nice. Most programs aren't setup for batch rotation and a nice interface.
If you choose to not obtain the right software, then Smugmug can be your choice. But, with the right software, it's way, way, way faster to do it on your local hard drive before uploading. I'll happily race you anytime. But, if you're constrained to not use appropriate software on your PC, then that isn't something I can comment on.
I'm not sure what batch processes you're talking about. Fixing rotation in Adobe Bridge or Lightroom for me involves manually mutli-selecting all the images that need to go one direction and then clicking the right rotation button. Then, multi-select any remaining images that need a different rotation and punch the right button. Then, I'm done with that directory of images. On to another directory or the next operation. I can fix 1000 images in under a minute.
Obviously. That's not what the discussion was about. Greg was talking about sizing photos so they'd have a ratio that would evidently produce a lossless rotation. My response was to observe that I can't see anyone bothering to crop to a certain ratio so that they'd then have a lossless rotation. It would be silly. As I said a buncha times-- if I'm ever editing anything, correct rotation of course gets saved along w/ whatever other edits-- first to a PSD. Then I make a jpg copy. I never save back to the original jpg.
I'd never heard this before, until Andy mentioned it awhile back. But anyway, I can't imagine many photogs using that criteria for cropping or uploading; like John says, it's whatever comes out of your camera, & usually you only crop if you feel you have to for various reasons, & you're gonna do that on a visual basis or because a certain format is needed. To be size-constrained just because of lossless rotating isn't something I'd be interested in. Ok, as soon as I get through my tax appt. & some work tomorrow, I'll try some of these other things.
If you take the photo size, for example, a 10 megapixel camera might have 3648 x 2736 pixels. Both of those numbers are evenly divisible by 16 (and by consequence 8). So they can almost for sure be rotated lossless.
You could probably point at virtually every reasonably standard size that comes out of a camera and it would be evenly divisible by 16 and those that are not would probably be divisible by 8. But, as jfriend says, if you crop the image first then all bets are off. Unless, of course, you are using a tool that can do lossless cropping - which would mean you'd only be able to crop out certain sizes.
.. There's a funny thing about computers and the number "8"
Once you're cropping, all bets are off. The JPEG is getting recompressed in that operation anyway. The point of the lossless rotation is an image that is unmodified in other ways. I'd be extremely surprised if Bridge didn't do exactly what you want. Before Lightroom came out, I used Bridge extensively (even with cameras that didn't have rotation sensors) and it worked great for me in this regard.
Right, That's why it doesn't make sense to do so (crop just to get lossless rotation) To get the image to be this certain ratio that evidently isn't lossy like he's saying, you'd have to crop, right? I don't know any other way to get it to be a certain ratio. But yes, either way, I would never be doing that, because there'd be no point. Here's what would be handy for me, for images that I'm not bothering to edit in any other way right away: To have a soft rotation done in batches like you've described. Then I wouldn't need to waste HD space converting them to PSDs just to rotate. They'd remain on my HD in the correct orientation then, and also some would get uploaded & not need rotation here. So, yes, I think we understand eachother.
If you choose to not obtain the right software, then Smugmug can be your choice. But, with the right software, it's way, way, way faster to do it on your local hard drive before uploading. I'll happily race you anytime. But, if you're constrained to not use appropriate software on your PC, then that isn't something I can comment on.
I'm not sure what batch processes you're talking about. Fixing rotation in Adobe Bridge or Lightroom for me involves manually mutli-selecting all the images that need to go one direction and then clicking the right rotation button. Then, multi-select any remaining images that need a different rotation and punch the right button. Then, I'm done with that directory of images. On to another directory or the next operation. I can fix 1000 images in under a minute.
It's actually not much different in SmugMug, nor should it be; that's why I've been trying to imagine how it can be all that much faster in another program, because no matter what, you still have to select the photos-- except that here we have to return to the tool after fixing the lefts to then fix the rights. That part, they could improve for sure. Still, I think I too can rotate the messed-up ones in a batch of 2000 here on Smug in under a minute as long as they don't over-rotate! That's really been the only issue here. No one would have come here complaining about the tool itself had it not been for the problem it had. Otherwise, it's fast.
If you take the photo size, for example, a 10 megapixel camera might have 3648 x 2736 pixels. Both of those numbers are evenly divisible by 16 (and by consequence 8). So they can almost for sure be rotated lossless.
You could probably point at virtually every reasonably standard size that comes out of a camera and it would be evenly divisible by 16 and those that are not would probably be divisible by 8. But, as jfriend says, if you crop the image first then all bets are off. Unless, of course, you are using a tool that can do lossless cropping - which would mean you'd only be able to crop out certain sizes.
.. There's a funny thing about computers and the number "8"
- Greg
My Nikon produces images that are 3008 x 1960. The first # is divisible by 16, but the second is only divisible by 8. So I don't know if they "qualify" or not. Here's what I don't get though: Anytime you (or a program, or a website's tool) is opening & then saving an image, aren't you getting a certain amount of loss, even if miniscule & invisible to the human eye? So doesn't Smug's system, no matter what ratio the jpg is, have to save that info back to the jpg, introducing lossiness? If not, then you can see that I haven't yet comprehended the site's method of saving changes. I'm not saying I ever notice artifacts though. So I'm thinking I just don't know how our Smug edits are saved, & I trust you when you're saying it's a non-lossy method. Maybe the answer is that Smug isn't truly "opening" a jpg to change it? I only know that on my own computer, the only way to rotate w/o loss is to save the change to PSD or TIFF & then back to jpg, or to do soft rotations (essentially a meta-tag)
My Nikon produces images that are 3008 x 1960. The first # is divisible by 16, but the second is only divisible by 8. So I don't know if they "qualify" or not.
It probably is. It probably uses 8x8, or it may use 16x8. Doubt very highly that it uses a 16x16 or 8x16.
Here's what I don't get though: Anytime you (or a program, or a website's tool) is opening & then saving an image, aren't you getting a certain amount of loss, even if miniscule & invisible to the human eye?
Now you are getting into some of the fun "magic".
If I was designing and writing a photo editing software, I would not write it in a way that if no changes were made to the data that required decompressing, why do it? I am sure there are many that would degrade the quality due to a de-compression/re-compression. But, that does not mean it is necessary.
So, imagine if we can rotate an image by reading chunks of compressed data (in your case, lets say 8x8) - there is no need to de-compress and re-compress it. We can just take that chunk of 8x8 data and literally rotate it without decompressing any of it. Then we just go chunk-by-chunk through the data, reading one chunk at a time until all have been rotated.
If for some reason this cannot be done, because the 8x8 thing doesn't fit then we have no choice but to de-compress > rotate > re-compress.
.. I am over-simplifying a bit here, just trying to explain how it works in broad terms.. If you want more information, I found a web-page with a bit more technical information about this: http://www.impulseadventure.com/photo/jpeg-lossless-extend.html
Just out of curiosity, where was the problem in the locking? Was it simple falling off an array or something more?
I am pretty sure that either:
A) the lock is not getting properly created but thinks it did
or something is releasing the lock through some obscure code path. Images can get locked for a lot of reasons and maybe when some other process is trying to lock it, it fails and releases the lock.
or C) There is just a bug somewhere that someone is clearing a lock when its not necessary (or a lock attempt was never made, just the release)
What I did was to make the system as a whole immune to failures in the locking system. Either the operation worked (lock + operation + unlock) and the serial number gets incremented, or one of those elements fails and it does not get incremented.
With distributed systems like this, eventual failure at some stage is inevitable. Now it can be as cranky as it feels like being
Feel free to post here if you continue to have any issues with it.
- Greg
Ok, Greg-- first tests of the fix are Yeee-HAAww I realized I have a bunch of galleries in my archives that I never bothered to rotate (was scared, probably) So I started with 3 of them. In all of these, virtually every vertical shot had to be rotated. In the first gallery, I just tried the Right rotations. In the 2nd & 3rd galleries, I did only Left rotations. I think I did over 300 rotations all-together. I've not done that many rotations ever, where I had no problems. But I went back later on, and didn't see any mis-rotated photos (of those I fixed)!!! I have not yet tried to do left rotations & then go right back in & do the rights. I'll try that w/ the next gallery. Do you have any idea how long a person should wait between the different types of rotation before going back into the tool? I don't know how long new thumbs take to generate. So yes, now you get the bow: I know we have more testing to do, but it sure looks hopeful so far! Thank you thank you!
I shoot thousands and thousands of images a week and this never is an issue for me. I have all my bodies set for auto rotate. Sorry.
Andy, I just wanted to follow up on this one thing about having bodies set for auto-rotate. I had done some checking into this before when you mentioned it, but today I did some much heftier searching. I went through every possible menu on the D1x, and also checked the index of my manual, then went through every page of the manual looking for anything about rotation. I came up completely empty-handed. I'm personally not surprised, as this is very early generation Nikon Pro DSLR. And I'll still keep my eyes open, but I doubt it has it. Like I said, I'm sure my brother would've had it set that way if it was available. He's a Nikon guru. He also uploaded a bunch of stuff for me last summer when we were both traveling, & when he did that, he rotated the obvious mis-rotated ones. I know he'd have said something to me if he thought there was a way the camera could do it. Like I said though, the one thing that does surprise me is that the verticals don't rotate automatically when I shoot w/ the 2nd shutter, which I nearly always do now. The moral of this story is that I guess I just need that phantom D4 . Oh, and I did download the LR 3 Trial version. Now I just need time to use it.
Ok, Greg-- first tests of the fix are Yeee-HAAww I realized I have a bunch of galleries in my archives that I never bothered to rotate (was scared, probably) So I started with 3 of them. In all of these, virtually every vertical shot had to be rotated. In the first gallery, I just tried the Right rotations. In the 2nd & 3rd galleries, I did only Left rotations. I think I did over 300 rotations all-together. I've not done that many rotations ever, where I had no problems. But I went back later on, and didn't see any mis-rotated photos (of those I fixed)!!! I have not yet tried to do left rotations & then go right back in & do the rights. I'll try that w/ the next gallery. Do you have any idea how long a person should wait between the different types of rotation before going back into the tool? I don't know how long new thumbs take to generate. So yes, now you get the bow: I know we have more testing to do, but it sure looks hopeful so far! Thank you thank you!
Great, glad to hear it is going well for you. I would not anticipate any problems though
As for timing, usually somewhere between 15-35 seconds. Though, if it fails, then it has to timeout first, which takes 10 minutes. I don't think you would get caught by any caching issues since we are incrementing the serial number of the image (so to any caching systems it would look like a new image).
You can go back into the tool right away and submit operations for other images. The only thing that might happen is that if you submit an operation for an image that is already being rotated, then it will not go through. But, as long as you are rotating separate images there is no problem at all with it.
If you choose to not obtain the right software, then Smugmug can be your choice. But, with the right software, it's way, way, way faster to do it on your local hard drive before uploading. I'll happily race you anytime. But, if you're constrained to not use appropriate software on your PC, then that isn't something I can comment on.
I'm not sure what batch processes you're talking about. Fixing rotation in Adobe Bridge or Lightroom for me involves manually mutli-selecting all the images that need to go one direction and then clicking the right rotation button. Then, multi-select any remaining images that need a different rotation and punch the right button. Then, I'm done with that directory of images. On to another directory or the next operation. I can fix 1000 images in under a minute.
It's not a question just software. I can't even install Bridge or Lightroom on the fastest hardware I have. And I don't have money to throw at the problem, so I just have to work with whatever tools I have until I have money.
I bet if I ran the old batch processes on the hardware that you're using to run Bridge and Lightroom, everything would rotate instantly as well. You're asking me to race your Ferrari in my Honda Accord. Let me put $150k into the Honda Accord, and then we'll definitely have a race.
Great to see the success with the tool so far. bow
I'm knee deep in website development right now, so even photo uploading is behind moreless processing. But with a batch of a couple of thousand now waiting for me, and more on the way, I'll know really quickly if there's any more issues.
Not yet as I haven't been able to work on any photo processing at the moment. But by the end of April, I will have rotated enough thousands of photos to say for certain.
Man, I hope you get some lobster with that or something! Well, I can't say I've been real helpful w/ the testing. Dropped off the face of the planet for a few days there, getting stuff matted & framed for a show. I've uploaded some already-edited stuff, so that was rotated correctly in PS & had no problems being correct here. I'll try a few more today, if that helps. Samir-- end of April??? I think Greg's gonna get awful thirsty by then!!
I do have one concern/suggestion/observation that might get this even more fully resolved going forward, however... or should I say: it will help with people's confidence & assurance that it's resolved. It's another issue with how the rotate tool works, and it's one that I should have mentioned much earlier, since some people (maybe even Samir, but if so, he probably compensated for it a long time ago) may have been having this trouble in combo with the other problem.
So here you go: When selecting photos for rotation using the bulk tool, you can choose photos for rotation just by clicking on them one at a time & not holding down any other buttons. You know you've selected them because they get a red edge, of course. So you're trucking along, thinking you've selected a bunch. You scroll down, selecting some more, and then go up to the top & hit "left" or whatever & figure you're done. Well, if you haven't been counting or forget to notice how many are slated for rotation, you may not realize that a whole bunch of previously selected photos are now missing from the count. Why? Because you really do need to hold down the "control" key, but only if you have more than one screen-ful of thumbnails! As soon as you scroll, that's it, your selections that aren't showing on the screen have un-selected themselves. I've never seen other selection tools (on my computer or elsewhere) behave this way. This one fools you because it allows multi-selecting w/o the control key... unless scrolling needs to occur (I've not tried this on a MAC, so I can't tell you what MACs do w/ it). I've been compensating for this for so long now that I forgot about the issue until the other day when it happened again & I thankfully noticed & had to re-select.
The problem this can cause is people thinking they told a bunch of photos to rotate when they really didn't. If you haven't scrolled down very far, only some of the photos you previously selected may un-select, so you just don't realize it. I would say that the solution here is to make it so that the only way to select more than one photo is to hold down control or shift, because that's the way people expect the tool to work. (as much as I hate having to use control, it's more fail-safe). As long as control is held down, there's no problem. The only problem is not realizing that control needs to be held down but only if some previously-selected thumbs no longer show on your screen because you've scrolled. So making control a must-do will prevent people from thinking they rotated photos that they really haven't. I'm afraid otherwise you'll have this tool all nicely fixed & then still get people saying it's not. There may be other bulk tools here that have this issue, but I can't remember off-hand. I used to get thrown off by it all the time, but it's the kind of thing you just do w/o thinking about it after a few months here... unless you don't rotate for awhile. Then you come back & say, "oooops...oh yeah..."
I have to apologize as well for not testing, although the real apology needs to be to my site visitors who have been still visiting even without new photos for 5 months!
As of last weekend I've been getting back into rhythm of processing photos using my normal workflow. So far, I haven't seen any over-rotation. Although, I have run into some strangeness today that I'm hoping will just clear up on its own.
Now, I'd like to touch a bit on what Anna Lisa mentioned about the select tool. While I haven't had the same experience of unselected images, I have noticed that on slower computers and when rapid selecting images, it will sometimes 'cancel' all the existing selections in favor of what I just selected in a similar fashion to what she describes. I think it's simply a failure of the computer to process the javascript in time, thereby cancelling all selections via some failsafe in the code. While this isn't a problem on most 'modern' computers, it can be an issue on ones heavily loaded with open applications.
I don't know of a real fix other than more efficient code. My workaround is to simply not click so fast and not try to select everything in one batch, but several smaller batches. This way, I won't lose a lot of work if it resets.
I don't think it's actually related to the original issue, but I can't say.
So here's the issue. A rotated image only rotates in dimensions, not actually rotating the photo. So a 4x6 image becomes squished into a 6x4 instead of being rotated (look at the watermark). I think this issue is related to this one I've been observing on and off for about a week or so: http://www.dgrin.com/showpost.php?p=1608563&postcount=3
I'll post some examples in galleries I'm currently working on in a second (they're on a different computer).
Comments
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
In any case, I don't know which method Adobe Bridge uses, but everything I've read says that even as of several years ago, Bridge used a lossless JPEG rotation. Either method should work before uploading to Smugmug.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Correct me if I am wrong here, but that is dependent on MCU size of the jpeg is, right? Most of the time it is 8x8, but I've heard of others (16x8, 8x16, 16x16). As long as you can fill the entire jpeg with those blocks (and not have anything left over), it can be rotated lossless. The safest thing to do, IMHO, is make sure the image is some multiple of 16 in width and height and that will almost always work out.
Do I have that about right? You probably know more about the intimate details of this then I do...
- Greg
The best thing would be if Bridge was just setting the same metadata that a modern camera sets for orientation. That would work with all image sizes and works with Smugmug. But, I don't know which method Bridge actually uses and I can't find it on the internet. I think we're probably at the point where Anna Lisa should just try it.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
My Website index | My Blog
Want faster uploading? Vote for FTP!
I used to run massive batch operations via irfanview to rotate images prior to using SM when I was hosting images myself. The actual rotation time may be faster, but there's still the setup. SM's interface is pretty nice. Most programs aren't setup for batch rotation and a nice interface.
Want faster uploading? Vote for FTP!
Just out of curiosity, where was the problem in the locking? Was it simple falling off an array or something more?
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
I'm not sure what batch processes you're talking about. Fixing rotation in Adobe Bridge or Lightroom for me involves manually mutli-selecting all the images that need to go one direction and then clicking the right rotation button. Then, multi-select any remaining images that need a different rotation and punch the right button. Then, I'm done with that directory of images. On to another directory or the next operation. I can fix 1000 images in under a minute.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
If you take the photo size, for example, a 10 megapixel camera might have 3648 x 2736 pixels. Both of those numbers are evenly divisible by 16 (and by consequence 8). So they can almost for sure be rotated lossless.
You could probably point at virtually every reasonably standard size that comes out of a camera and it would be evenly divisible by 16 and those that are not would probably be divisible by 8. But, as jfriend says, if you crop the image first then all bets are off. Unless, of course, you are using a tool that can do lossless cropping - which would mean you'd only be able to crop out certain sizes.
.. There's a funny thing about computers and the number "8"
- Greg
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
If I was designing and writing a photo editing software, I would not write it in a way that if no changes were made to the data that required decompressing, why do it? I am sure there are many that would degrade the quality due to a de-compression/re-compression. But, that does not mean it is necessary.
So, imagine if we can rotate an image by reading chunks of compressed data (in your case, lets say 8x8) - there is no need to de-compress and re-compress it. We can just take that chunk of 8x8 data and literally rotate it without decompressing any of it. Then we just go chunk-by-chunk through the data, reading one chunk at a time until all have been rotated.
If for some reason this cannot be done, because the 8x8 thing doesn't fit then we have no choice but to de-compress > rotate > re-compress.
.. I am over-simplifying a bit here, just trying to explain how it works in broad terms.. If you want more information, I found a web-page with a bit more technical information about this: http://www.impulseadventure.com/photo/jpeg-lossless-extend.html
- Greg
I am pretty sure that either:
A) the lock is not getting properly created but thinks it did
or
or C) There is just a bug somewhere that someone is clearing a lock when its not necessary (or a lock attempt was never made, just the release)
What I did was to make the system as a whole immune to failures in the locking system. Either the operation worked (lock + operation + unlock) and the serial number gets incremented, or one of those elements fails and it does not get incremented.
With distributed systems like this, eventual failure at some stage is inevitable. Now it can be as cranky as it feels like being
- Greg
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
Great, glad to hear it is going well for you. I would not anticipate any problems though
As for timing, usually somewhere between 15-35 seconds. Though, if it fails, then it has to timeout first, which takes 10 minutes. I don't think you would get caught by any caching issues since we are incrementing the serial number of the image (so to any caching systems it would look like a new image).
You can go back into the tool right away and submit operations for other images. The only thing that might happen is that if you submit an operation for an image that is already being rotated, then it will not go through. But, as long as you are rotating separate images there is no problem at all with it.
- Greg
I bet if I ran the old batch processes on the hardware that you're using to run Bridge and Lightroom, everything would rotate instantly as well. You're asking me to race your Ferrari in my Honda Accord. Let me put $150k into the Honda Accord, and then we'll definitely have a race.
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
I'm knee deep in website development right now, so even photo uploading is behind moreless processing. But with a batch of a couple of thousand now waiting for me, and more on the way, I'll know really quickly if there's any more issues.
Want faster uploading? Vote for FTP!
...I have a beer riding on the outcome....
- Greg
Want faster uploading? Vote for FTP!
I do have one concern/suggestion/observation that might get this even more fully resolved going forward, however... or should I say: it will help with people's confidence & assurance that it's resolved. It's another issue with how the rotate tool works, and it's one that I should have mentioned much earlier, since some people (maybe even Samir, but if so, he probably compensated for it a long time ago) may have been having this trouble in combo with the other problem.
So here you go: When selecting photos for rotation using the bulk tool, you can choose photos for rotation just by clicking on them one at a time & not holding down any other buttons. You know you've selected them because they get a red edge, of course. So you're trucking along, thinking you've selected a bunch. You scroll down, selecting some more, and then go up to the top & hit "left" or whatever & figure you're done. Well, if you haven't been counting or forget to notice how many are slated for rotation, you may not realize that a whole bunch of previously selected photos are now missing from the count. Why? Because you really do need to hold down the "control" key, but only if you have more than one screen-ful of thumbnails! As soon as you scroll, that's it, your selections that aren't showing on the screen have un-selected themselves. I've never seen other selection tools (on my computer or elsewhere) behave this way. This one fools you because it allows multi-selecting w/o the control key... unless scrolling needs to occur (I've not tried this on a MAC, so I can't tell you what MACs do w/ it). I've been compensating for this for so long now that I forgot about the issue until the other day when it happened again & I thankfully noticed & had to re-select.
The problem this can cause is people thinking they told a bunch of photos to rotate when they really didn't. If you haven't scrolled down very far, only some of the photos you previously selected may un-select, so you just don't realize it. I would say that the solution here is to make it so that the only way to select more than one photo is to hold down control or shift, because that's the way people expect the tool to work. (as much as I hate having to use control, it's more fail-safe). As long as control is held down, there's no problem. The only problem is not realizing that control needs to be held down but only if some previously-selected thumbs no longer show on your screen because you've scrolled. So making control a must-do will prevent people from thinking they rotated photos that they really haven't. I'm afraid otherwise you'll have this tool all nicely fixed & then still get people saying it's not. There may be other bulk tools here that have this issue, but I can't remember off-hand. I used to get thrown off by it all the time, but it's the kind of thing you just do w/o thinking about it after a few months here... unless you don't rotate for awhile. Then you come back & say, "oooops...oh yeah..."
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
As of last weekend I've been getting back into rhythm of processing photos using my normal workflow. So far, I haven't seen any over-rotation.
Now, I'd like to touch a bit on what Anna Lisa mentioned about the select tool. While I haven't had the same experience of unselected images, I have noticed that on slower computers and when rapid selecting images, it will sometimes 'cancel' all the existing selections in favor of what I just selected in a similar fashion to what she describes. I think it's simply a failure of the computer to process the javascript in time, thereby cancelling all selections via some failsafe in the code. While this isn't a problem on most 'modern' computers, it can be an issue on ones heavily loaded with open applications.
I don't know of a real fix other than more efficient code. My workaround is to simply not click so fast and not try to select everything in one batch, but several smaller batches. This way, I won't lose a lot of work if it resets.
Want faster uploading? Vote for FTP!
I don't think it's actually related to the original issue, but I can't say.
So here's the issue. A rotated image only rotates in dimensions, not actually rotating the photo.
http://www.dgrin.com/showpost.php?p=1608563&postcount=3
I'll post some examples in galleries I'm currently working on in a second (they're on a different computer).
Want faster uploading? Vote for FTP!