Is HDR really 32-bit?

I'm really impressed with the new HDR feature in Camera Raw 9.0. It's easy to use and seems to do an excellent job. It is advertised as producing a 32-bit HDR image. This size would indicate that that is probable because my 12 MP NEF files are only 8 or 9 MB, and the resulting DNG HDR file is 56 MB. But both Bridge and Lightroom indicate that the HDR image is 16 bit. Any thoughts? I haven't yet tried it using Lightroom, but plan to do so shortly.

Jim, the result of the HDR merge is a floating-point DNG file. The image data itself is stored as 16-bit floating point data. When you render that data using the Camera Raw controls, we internally use a 32-bit floating point image processing pipeline to handle the rendering.

Similar Messages

Is iTunes64Setup.exe really 64-bit?

For a new install of Windows 7 Pro 64-bit, I downloaded iTunes64Setup.exe without being asked if I wanted 64- or 32-bit. But upon installing, it put itself into "Program Files (x86)." Isn't this where the 32-bit programs go to live?

Vista seems to be getting better slowly but there are still people having issues with it alongside MAX, XSI, various graphics driver issues, certain old hardware not getting driver update support etc. plus it uses more RAM as a general OS overhead, leaving you less for your work. There are many, many reasons why a lot of us are sticking with XP for now.
I should mention probably the biggest reason - if you already have a load of machines with XP Pro 64 on, all set up for your render farm with a perfect network going, you don't really want to be buying a bunch of licenses of Vista and risk it all going down the pan in the process. For instance I'm just a 1-man freelance shop, but I have 6 machines all in a tight-as-hell XP64 network - that would cost me around £500 plus to upgrade to Vista, hours of pain setting it all up again (and we know how crappy Vista's network management is now, over XP - it's almost like it's in dummy mode!) and who knows what other issues.
The sorry fact is that XP64 is and always has been a "black hole" for developers (hardware and software). They didn't like the sudden move to 64-bit, chose to wait a dev cycle (ultimately until vista 64 came out) and now suddenly it's all the rage and being supported properly, leaving us XP64 users in the annoying position of having virtually 0 support from anybody for our software or hardware for the next year or so (i say the next year or so as I expect most of us will have moved to Vista by then). I've lost count of the number of times I've had to google for workarounds to installing/using applications or hardware.
It's a hassle, but ultimately less hassle in the short term than switching to Vista. I'll leave that for maybe another 6 months I think.

PS/Camera raw (hdr pro 32 bit). Saving as Tiff, photo has errors!

While using PS/Camera raw. I am doing an HDR image. I select my three raw images and edit in "merge to hdr pro".
I then set to 32 bit, save as tiff (ctrl+s). The files always have errors and can not be opened.
If i save in 16 bit the file works fine.
Here is what the file looks like in my folder. Look at the upper right image.
Camera raw 7.3 with PS CS6. Windows 7 64.
EDIT:
I found that when Camera raw is done merging the photos and places tehm into Photoshop. Even though i can not save them as a Tiff, i can open them in NIK HDR, choopse any options there, then it will save as a Tiff.

Hi!
I have the same problem. I exported 5 photos out of Lightroom 4.3 and used "merge to hdr pro".
When I saved the 32Bit Tiff it looked the same like your example.
Have you found a solution to this problem?

10-bit RGB really 8-bit?

When I capture 10-bit RGB files in Final Cut Pro they show up as 8-bit files when I bring them into Shake. Any ideas as to why this happens?

Interesting. I wasn't sure if Final Cut Pro was capturing 10-bit files properly or not. I've been reading that FCP can only render RGB in 8-bit so I wasn't sure if it was really capturing 10 bit files as 8-bit. I am able to create 10-bit RGB files in After Effects and Shake will default to working in 16-bits when I import them.
Do you have experience with Glue Tools? Does it allow one to export all the 10-bit data as DPX files?

7.7 Not really 64 bit?

I've downloaded what is in theory the version of iTunes for 64-bit Vista. However, when I go to install it, the target directory is "C:\Program Files(x86)\iTunes". This is the default location for 32-bit applications. The "(x86)" should not be there for a 64-bit application.
Has anyone using Vista 64-bit installed this version? Does it work correctly for you? Do you have a iPhone and does it still sync?

Thanks, Roy, that's interesting information.
I wonder why the behavior changed - previous 64-bit versions installed as 64-bit applications, while this one installed as a 32-bit (based on the installation directory).
Anyway, because I already had 64-bit iTunes 7.6 installed under "C:\Program Files\", I overrode the iTunes installer and told it to put 7.7 in the same location. I am curious to see if future editions continue to target the 32-bit program folders or revert to the 64-bit program folders.

Try to install iTunes on Vista 64 bit on a clean install but it refuses to install

I download the 64 bit version for install on my PC, but during install i noticed it was being installed to Program files (x86) which confused me. so I changed it to Program files in the setup preferences and proceeded to install. It gets half way through installing and gives up. Am I to guess that iTunes 64 is not really 64 bit at all but a psuedo to give it that impression. If it is going to install into a 32 bit directory then I have no recourse but to assume the latter.
Any ideas how I can get this to install on my Windows Vista 64 bit. Either way it comes up with scripting errors every time I try now. What is needed is an apple cleaner to get rid of elements of the old installs hidden in places like Appdata and the registry as well as hidden MSI scripts which stop subsequent installs.

An error occured during the installation of assembly 'Microsoft.VC80.CRT.type="win32="8.0.50727.6195".publicKey Token="1fc8b3b9a 1e 18e 3b".processorArchitechture="x86'''.Please refer to help and support for more information. HRESULT: 0x8007054f.
These ones are typically caused by underlying problems on the PC that also often cause Windows Updates to fail to install. If we can fix the Windows Update trouble, we can usually get the iTunes trouble cleaned up en passant.
Go into your Windows update and try to check for new updates. If updates install, stock up on the ones you're behind on, restarting the PC if requested to do so. After the restart, try installing iTunes again. Does it go through this time for you?
If windows updates fail to install, go into your Update History and doubleclick the failures. What alphanumeric codes appear for you? Are they also 8007054F, or some other number? (If they're another number, what number are you getting?)

16 Bit PSD Files Not Compressed

Something that's not new, but that I've not really noticed before...
Image compression in Photsohop CS6 doesn't seem to be effective on a 16 bit PSD when Maximize Compatibility is turned on.
For example, with Maximize Compatibility set to Always, if I create a new file 6144 x 4096 pixels x 16 bits/channel with a pure white background, and add a single text layer that says "This is a test", then save the file, it's 144 megabytes. Zipping that same file into a .zip archive results in a massive reduction, to 245 kbytes.
Sure enough the saved file size goes down if I set Maximize Compatibility to Never. But even that can be hugely more compressed by zip (down to 88 kbytes).
This implies the failure to compress is happening on the flattened preview.
If I change to 8 bits/channel and save that same document either way it's about two and a half megabytes, differing only a couple hundred kbytes between Maximize Compatibility Always vs. Never. In this case, apparently the flattened preview is being compressed nicely.
These are my file handling preferences. Note that I do NOT have [ ] Disable Compression checked.
Doing a bit of spot testing, I believe this is nothing new - it has been the same in recent past versions (e.g., Ps CS5, CS4). I've just never noticed that saving 16 bits/channel data yielded such huge files (because I always diaabled compression anyway), but apparently it has been the same all along.
No problem here - this is just a curiosity to me, as I have a fast disk array and these saves are all quick enough. I choose the "Always" maximize compatibility setting because I have a viewer (IrfanView) that I use for quick previews that won't read files saved with Maximize Compatility disabled.
I suppose it does beg the question: What prevents Photoshop from doing the Flate compression on the flattened preview in a 16 bits/channel PSD file? Was there an old version that couldn't decompress such files?
-Noel

Thanks. That makes sense, especially considering 16 bit data is really 15 bits plus a hair, so an all white background would look, to an RLE compression scheme, like (in hex) 80 00 80 00 80 00 etc. - i.e., be incompressible.
Is there any kind of compression you could invoke that would work in recent versions of Photoshop? I'm imagining a "More Compatible" setting, which could give decent compression for a 16 bit file but not necessarily be "Completely Compatible" with everything ever made out there.
I need to ask the author of IrfanView if he's working on a multi-layer PSD decoding scheme. I know there are people who have done it (the FastPictureViewer Codec Pack provides previews and thumbnails for Maximize Compatibility: Never files, for example).
-Noel

Problem Processing HDR Pro in CS5

When selecting my photos for HDR processing from Bridge, by going to tools, Photoshop, Merge to HDR Pro and making my adjustments there, everything seems normal. When I click on "OK" and waiting, the photo comes up in PhotoShop as a completely black image. The "background" layer is of course also black, but when the layer first appears there is a quick glimpse of the photo before going black. There is a slider at the very bottom left hand corner of PhotoShop that is set about 1/3rd or a little more from the left . Just to the right of the slider is an arrow and when clicked, it says "32 bit exposure", which is checked, along with other selections. Upon moving the slider to the right, the photo gradually appears in photoshop, but the layer still stays completely black. Upon adjusting the slider to get the correct exposure and then trying to "save as" the image, I only have a few choices instead of the normal large selection. TIFF is one selection, but JPEG is not. Upon Saving as a 16 bit TIFF, I do not have the option to open the file in Camera Raw.
In Scott Kelby's Photoshop CS5 book, in the HDR chapter it shows a screen-shot of PS and the photo after clicking the OK button. In the screen shot, there is no slider in the very bottom left of PS, but it states "exposure works in 32 bit only" in the same area of where my slider is located.
This process was working correctly originally, but started acting this way about 2 or 3 weeks ago. My thinking is that I have changed a setting somewhere that is causing this problem, but I can't seem to locate where. Would anyone out there have a solution to this very frustrating problem? Thanks Much In Advance, Gary

There is a Radius, Strength, Gamma, Exposure, Detail, Shadow, Highlights, Vibrance, Saturation and Curves Controls.
In that case you've told MergeToHDR to go to 8 or 16 bit and are not creating an HDR image.
Then you won't have the exposure slider or any choice of whitepoint.
You only get the whitepoint choice when creating an HDR image (32 bit/channel).
You might want to spend some time reading the manual about how MergeToHDR works.
Merge to HDR. Mine says Merge to HDR Pro....would that make a difference somehow?
Same thing.
And ACR can't open 32 bit/channel floating point images.

How do i know if phtoshop elements 11 is installed as 64 bit or 32 bit on windows 32

I installed elements 11 upgrade as download purchased from adobe site
windows 7 with quad 4 processor and 8 gb memory and 3 mhz speed plenty of power for 64 bits
i was not given option on install as to 32 bit vs 64 bit install and i want 64 bit for two reasons
1) for speed
2) for optimal connectivity with lightroom 64 bit plugins and an HDR program 64 bit pluigins
the ABOUT screen does not tell me what I am running in elements

Thanks
Sent from my iPad

16-bit vs 8-bit Mysteries

I think I've read almost every 8bit vs. 16bit debate over the past 6 years, including those by Fraser and Margulis. I still remained bit confused, so I tried to develop some tests of my own. I didn't get very far because I stumbled over some mysteries. I'm hoping some gurus with more experience can shed some light.
Details follow, but in summary, why does the Photoshop Info Pallet show "odd" 16bit values on 8bit images? Why does Photoshop generate different 16bit values from the same 8bit values?
Here are my initial testing steps:
Set Up:
Fire up Photoshop. I'm using CS5 64bit in Windows 7 64bit, but I expect these tests would be the same under any version. Select the Eyedropper Tool and change the sample size to "point sample". Go to the Info Pallet, set one of the readout values to RGB (if not already there by default.) Then set the value to 16 bit by clicking on the eyedropper next to the RGB values.
MYSTERY 1:
1A. Generate a new blank document, 500x500 pixels, 8bit mode. sRGB colorspace.
2A. Bring up the Color Picker window and set all RGB values to 149. There is nothing special about 149. You can use any value. I picked it because it matches the "50% gray" value in the Swatches pallet that I use in other tests.
3A. Fill the image with this value. Several ways to fill, I use the Paint Bucket.
4A. Use the "point sample" Eyedropper tool to read the 16bit RGB values in the Info Pallet. See 16bit values of 19147 for the 8bit value 149.
That's the mystery. Why is the 16bit value an odd amount? In 16 bits there are 128 steps between each 8 bit value. You would think that 8 bit values would be in integrals of 128. So an 8 bit value of 149 should be 148 X 128 = 19072, not 19147.
MYSTERY 2:
2A. Generate a new document, 500x500 pixels, 16 bit mode.
2B. Go to Swatches pallet, click on the "50%" gray swatch, top right row.
2C. Bring up Color Picker window, see that RGB values are all 149.
2D. Use Paint Bucket tool and fill the image.
2E. Wave the mouse around the image and see that the 16bit RGB values are all 19131.
2F. Bring up the Color Picker window and simply retype any one of the RGB values with the same value. Apparently this causes Photoshop to reset the values.
2G. Re-fill the image with the "reset" values.
2H. Sample around the image and see that the 16bit RGB values are now all 19147.
2I. Repeat often, filling the image with RGB 149 values first set by the Swatches pallet, then set with the Color Picker. Notice that the 16bit readout in the Info pallet switches back and forth between 19131 and 19147.
So, why does Photoshop generate different 16bit values from the same 8bit values, depending on where you get the 8bit values (Color Picker vs. Swatches)? Note: different colorspaces generate different values from the Swatches pallet, as expected, but the mystery of getting different 16bit results from identical looking 8bit values still happens, regardless of colorspace.
MYSTERY 3:
3A. Generate a new doc in 16bit mode.
3B. Go to Swatches pallet, click on the 50% gray swatch.
3C. Use the Paint Bucket tool and fill the image.
4D. Sample the image with the Eyedropper, verify all values are 19131.
5E. Use Image/Mode and convert to 8bit.
6F. Wave the mouse around the image and see that the 16bit values have changed. Most are 19147, but a few are 19018. Magnify the image to the max to see and sample individual pixels. There is no apparent pattern to the 19018 value pixels. They appear to be random.
So, why does Photoshop NOT apply the same math to every pixel during a 16bit to 8bit conversion?
The only explanation I can think of for these mysteries is that maybe the Info Pallet is giving bogus numbers for 16bit values. Perhaps the math performed on the actual pixels is different from the math used to calculate and display the values in the Info Pallet. In which case, what we see is not what we get?

Photoshop 16 bit integer data is really 15 bits plus a tiny bit more.
black = 0
white = 32768 = 0x8000
Yes, that seems strange, but it's the way it is.
Plus I recall seeing (in the Plug-in SDK) some conversion math that led me to believe it was optimized for speed rather than numeric accuracy. I'll try to find that again.
Hopefully this might help explain some of what you're seeing.
-Noel
P.S., there was a thread a while back in the Camera Raw forum in which it was shown that color management operations were introducing dithering in 8 bit data. It's possible the operations you're using are invoking the same quirk from the Adobe color management engine.

How to get higher resolution previews in HDR Pro

I often make HDR images by exporting a bracket from lightroom into photoshop via right click>merge to HDR in photoshop. When the dialog comes up it is always a very low resolution preview. When I go to zoom in (cmd +) the resolution remains the same and I am zooming in on a pixelated image and the zoom is very limited. I am working from D3s files so there is plenty of resolution but it just doesn't show up in the preview. Is this simply the way it works or is there a way I can get a higher resolution preview. I'm not worried about rendering times either as I'm on a 8 core with 16gb or ram.
Thanks!

Liter Cola-
not sure if this is entirely what you want, but there are options in adjusting the preview for a 32bit HDR image. with a 32 bit image you can store the entire dynamic range of the HDR image:
"32‑bit Exposure
Option for adjusting the preview image for viewing 32‑bits-per-channel high dynamic range (HDR) images on your computer monitor. The slider is available only when the document window displays an HDR image."
link:
http://help.adobe.com/en_US/photoshop/cs/using/WSfd1234e1c4b69f30ea53e41001031ab64-78eea.h tml#WSfd1234e1c4b69f30ea53e41001031ab64-78eba
hopefully this helps somewhat-
janelle

32 bits on Snow Leopard : old dylib, dylib paths and xcode

Hello !
I've got a problem with 32 bits on Snow Leopard. I'm unable to change paths inside and old leopard dylib, and i have architecture compilation problems when i compile the dylib and the project that uses it. (i've replaced personal information in the rest of the post)
I want to use libsigc++ (a signal library) in a project but :
- if i use my old leopard compiled dylib of libsigc++, an absolute path is wrong inside the dylib, when i run the application that uses the dylib, i get
Dyld Error Message: Library not loaded:
and the indicated path is wrong (as i see when i do otool -L dylib_file)
but if i do installnametool with the change flag
the path remain the same when i do otool -L dylib_file
in addition, if i do installnametool with the delete_rpath flag
i get installnametool: no LC_RPATH load command with path: ...
- if i try to compile libsigc++ on Snow Leopard, everything seems to work, and when i compile the project that uses the compile libsigc++, i get :
ld: warning: in DYLIB_FILE, file is not of required architecture
I've tried, as i seen on a forum, to compile my dylib with
env CFLAGS=-arch i386 ./configure (with quotes, but it doesn't work here)
env CFLAGS=-arch i386 make (with quotes too)
but the result is the same...
My configuration in XCode is Mac OS 10.5 , i386 , gcc 4.0
So, does anybody have a solution to change my dylib paths or to be sure that my project and my dylib (compiled with configure and make) are really 32 bits ?
Thank u !
Emilien

MeeLoo wrote:
- if i use my old leopard compiled dylib of libsigc++, an absolute path is wrong inside the dylib,
What path is that?
when i run the application that uses the dylib, i get
Dyld Error Message: Library not loaded:
and the indicated path is wrong (as i see when i do otool -L dylib_file)
but if i do installnametool with the change flag
Can you print the exact command you are using?
- if i try to compile libsigc++ on Snow Leopard, everything seems to work, and when i compile the project that uses the compile libsigc++, i get :
ld: warning: in DYLIB_FILE, file is not of required architecture
Have you done a "make clean" on everything in this project? You are only going to get the "file is not of required architecture" if you are mixing architectures. If you do the default options, you shouldn't ever have mixed architectures or that error message.
I've tried, as i seen on a forum, to compile my dylib with
Which forum is that? The internet is a great mixing bowl of misinformation.
env CFLAGS=-arch i386 ./configure (with quotes, but it doesn't work here)
env CFLAGS=-arch i386 make (with quotes too)
First of all, you shouldn't even be using that flag at all. Do "make clean" on everything and get rid of all the options and it should build fine. If you insist on cross-compiling, the correct flags to use are
“-arch i386 -mmacosx-version-min=10.5″ to build a 32-bit version for MacOS X 10.5. You may need to set both CFLAGS and CXXFLAGS, depending on how well the makefile is constructed. If your Makefiles aren't well constructed, setting those flags on the "configure" command line may not work.

Does Photoshop elements process HDR images...or ...?

I am using Light room (LR), and have watched the instructional videos for processing HDR images in LR, using Photoshop (PS). I have only PS Elements on my system presently. LR lets me select multiple images for HDR in LR, and input the LR commands to process images for HDR using PS. The PS Elements window appears. The little cursor wheel spins, and spins, then .... nothing happens. Do I need the full PS CC suite to process HDR? Do I need to buy a subscription (that I don't want) to the CC system and get the full blown PS software? Has Adobe now got me by the balls... ?

PSE does not do true HDR. It will do a "kind-of HDR" by merging photos with different exposures (Photomerge-Exposure), but only in 8 bits. The result (also in 8 bits) cannot possibly be HDR because 8 bits can't contain even the DR your camera can capture in a single exposure, much less extend it to HDR. The advantage in using LR in the HDR process is that it can edit (map) the 32 bit HDR tiff produced by PSCS (and other HDR programs) when working from 16 bit images. However, if you do want to do Photomerge, send the images to PSE in the usual way, select them all in the Photo Bin and then initiate Photomerge-Exposure.

10-Bit color calibration problem

I have the following setup:
Dual HP ZR30w Wide LCD Monitors, each connected via Display Port to each below card.
Dual ATI FirePro v7800 (FIreGL) display adapters
Latest FirePro drivers from the AMD website (file name: FirePro_8.85.7.2_Win7x64_125182.exe)
Win 7 Pro 64-bit
Spyder3Elite 4.0.2
When I enable 10-bit color in the ATI drivers, and use the Spyder 3 package to perform
a calibration the profile is absurd --- light yellows render as light green, off whites become
purple... If, in 10-bit I switch to an old profile generated when running 8-bit I get reasonable
but slightly off color. Running 8-bit with an 8-bit calibration works perfectly to my eye.
Colorvision claims there is no problem, that the above ATI/HP pipeline is really 8-bit. Here
is the quote from their tech support:
"the option you deactivated is not a 10bit communication between your graphic card and your monitor.
That's just a 10bit LUT/mode in your video card which will be reduced to 8bit output to your monitor.
Please understand we can't give you a fix for a 10bit pseudo wide color depth mode of your video card.
The output is 8bit and that's all. The only advantage is that you could tweak color with less reduction.
But this has nothing to do with the industrial standardized ICC profiling system."
Does what they say make any sense? My understanding of the HP monitors and ATI cards is that
it is a true 10-bit pipeline.
If I do have a true 10-bit pipeline, what can I do to run in that mode and have well calibrated monitors?
I contacted integrated color, as they have software that will work with my Spyder 3 sensor and they
said I would not see any benefit from 10-bit monitor color and their software does not support 10-bit
mode. Does that ring true?
Thanks in advance,
Andrew

It should also be noted here that banding is potentially a bigger problem with wide gamut, since the values are farther apart. So while 10 bit is perhaps not strictly needed, it has become more desirable.
I see clear banding on that test image, on my wide gamut/8 bit Eizo S2243.
If in-monitor calibration makes it a good match to Adobe RGB 1998, and in the context of an 8 bits/channel color pipeline, then no calibration or profile-based transform would be required when you edit in the Adobe RGB 1998 color space.
This is where I still don't agree (but we probably shouldn't go there again ) I concede that my previous position was a bit...ah, inflexible. Mainly that's because I've since realized that there are many variables that need to be brought under strict control before you can make any claims to accuracy.
So let's just say it's about peace of mind. There are many unknowns in the equation above, and it seems to me the best approach is to pin down as many as you can.
As I write this, I'm on my way to look at proofs for a book I've supplied 80% of the photographs for. I've done what I can, I have peace of mind, and still...

How to read bits from the file?

Hello everybody,
I'm beginner in LabVIEW. I need to get bits from the file, but I don't know how I can do it. I use the example "Read Binary File VI" from LabVIEW Help, but it returns DBL array. And for a long time I can't find a solution to convert this array to array of bits. Can somebody help me? Thanks in advance.
Solved!
Go to Solution.

tranonim wrote:
Hello everybody,
I'm beginner in LabVIEW. I need to get bits from the file, but I don't know how I can do it. I use the example "Read Binary File VI" from LabVIEW Help, but it returns DBL array. And for a long time I can't find a solution to convert this array to array of bits. Can somebody help me? Thanks in advance.
You can pass in the type into the Read Binary File VI to get the data in whatever form you want. Just remember that a boolean is really 8 bits.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Is HDR really 32-bit?

Similar Messages

Maybe you are looking for