Quick question. With Photoshop in 16-bit mode, is a JPEG image actually being processed above 8-bit depth or simply within 16-bit depth?
Quick question. With Photoshop in 16-bit mode, is a JPEG image actually being processed above 8-bit depth or simply within 16-bit depth?
Quick answer: probably
If you do anything to the image that multiplies the (original 8 bit) pixel values by something that results in a 'fractional' answer, using 16 bit will allow that accuracy to be held and further multiplied, before the output translation/rounding to 8 bit again for us to view.
If you start 8 bit and process 8 bit, each successive process step MAY result in successive rounding errors and the final result may look obviously posterized - or you could call it "painterly" and insist it was deliberate
Cheers, Dave
Well, your jpeg image actually isn't processed (ok, ok, there are some modifications you can do on an image in jpeg format, like rotation by 90°)...
What I mean is, jpeg is a storage format, so a (compressed) jpeg image will first be converted into a bitmapped image, with the bit depth used internally.
Also the colours converted into the colour space used internally by photoshop.
So if you use Photoshop in 16-bit mode, you will indeed process your image with 16 bits per channel, and that's independent of the format the image was stored in.
I've done edits on quite a few 8-bit jpegs, so I don't understand where you are coming from here Remco.
Most of the tools I use in any of my edits are available, so I can clone, dodge, burn, lighten, darken, etc. The only issue is that there is less "headroom" as I can only change up to 256 different discrete values per channel, so there is a higher risk of artifacts creeping into an edit.
Ed - there is no advantage to converting an 8-bit image to 16-bits. All you get is an 8-bit to 16-bit conversion, but the underlying colour data has not changed at all. There is a theoretical advantage of having some of the work done in 16-bits, but that all gets lost again if you convert back to an 8-bit jpeg for posting.
If I edit a jpeg, I stick with 8-bit.
I think Remco was making the point that you do not actually edit a jpeg file but rather the image derived from the jpeg file. If you are working in a 16 bit work-space the 8 bits per channel image derived from the jpeg file become the most significant bits of the 16 bit work-space. On saving the image back to a 8 bit jpeg file the lower 8 bits of the work-space will basically be discarded. I am unsure if any rounding derived from the lower(least significant) 8 bits is done when saving, may depend on software being used.
I think the same can be said about any image file. A jpeg is just a way of encoding (with lossy compression) of an image. A TIFF is another way of encoding image data. Raw data has to be turned into image and rasterized before it can be edited.
Whenever we edit, we are looking at a rasterized and resized image file that we see on our computer display. This applies to both a parametric editor or a pixel based editor.
The only other approach for image editing I am aware of is vector based graphics (Adobe Illustrator or Corel Draw), but again this vector data has to be rasterized and displayed on the computer screen to be edited.
Not sure, but I don't think so. I think they're recalculated to 16 bits. So a value of 128 in 8 bits, 50%, will become 32768 in 16 bits, also 50%.
So x% in the a-range will stay x% in the b-range. You may use any number for a or b.
I might add a diagram again.
And I did.
The RGB-raster image is the most important image. Always wonder where it's derived from.
George
Last edited by george013; 14th January 2017 at 08:45 AM.
128*256(value of least significant 8 bits) = 32,768 no recalculation needed.
In binary maths each shift to the left results in multiplying by 2. Placing the 8 bit value as the most significant byte of a 2 byte 16 bit integer automatically multiplies by 256.
Last edited by pnodrog; 14th January 2017 at 10:26 AM.
An ordinary JPEG is always being into the 8-bit Space, not 16-bit, and always being lossy encoded.
That's because saving as JPEG file should be always the last step, for Web Viewing like here, etc...ordinary Workflow from Picture Processing is RAW -> TIF -> JPEG, usually. TIF or .PSD Format, because they are 16bits, and RAW Files from DSLR, DSLMs are typical 12 to 14bits, whileas professional digital MF Cameras are usually 16bits in terms of RAW Files. (Hasselblad for instance)
Quite so. Not unlike where some people think of "editing a raw file" when that can not be done.
Thanks, I didn't know that - I've always though that 8, 12 or 14bit went into the LSBs. Certainly do with my Sigma cameras with their 12-bit ADCs, but then Sigma is always different, eh?If you are working in a 16 bit work-space the 8 bits per channel image derived from the jpeg file become the most significant bits of the 16 bit work-space.
When converting to 16 bit you place them in the most significant bits. Also with 12 and 14 bit. When you don't want to convert them, you use the less significant bits. You're multiplying with 2^8, 2^6 or 2^4.
It's a binary solution for the decimal approach I had. Much more direct.
George
The key point is that if (unsigned integers) the most significant bit is on the value is equal or greater than 50% of total range and if off is less than 50% of range. So if we have an 8 bit value it's most significant bit needs to placed as the most significant bit of a 16 bit work-space so it is scaled correctly to the extended range.
Exactly how different software (Photoshop, GIMP etc) handles the scaling and stores the information in memory will depend on a range of factors including operating system, programme language(s) used, flexibility of data structure for different implementations, ease of program enhancements and updates, performance or memory usage priority etc etc.
It matters little to me as a photographer so long as it all works....
Aha, "scaled", another keyword for me to complete my understanding.
Sometimes I like to understand what's going on. For example, I use RawDigger to examine raw file image data and the raw histograms show it un-scaled, which is why I got a little discombobulated . . .Exactly how different software (Photoshop, GIMP etc) handles the scaling and stores the information in memory will depend on a range of factors including operating system, programme language(s) used, flexibility of data structure for different implementations, ease of program enhancements and updates, performance or memory usage priority etc etc.
It matters little to me as a photographer so long as it all works....
Yes I also like to understand the underlying concepts and behavior of what is going on but I am wary of getting too caught up in it's actual implementation.
e.g. As above a 8 bit range must be scaled at some point to work in a 16 bit workspace and it would seem simplest it be done at the start by bit alignment but there are other ways of doing it.
Last edited by pnodrog; 17th January 2017 at 09:41 PM.