32bit files are rendered almost black and cannot be recovered. Had to rollback to 4.3 to work. Anyone has the same issue? I'm on Mac, 10.8.2, MacBookRetina 15".
I think 32 bpc tif file rendering in LR 4.4 RC is partly broken. See my posting http://feedback.photoshop.com/photoshop_family/topics/lr_4_4rc_32_bpc_ tif_file_rendering_broken_far_too_dark_far_too_ugly_colors?utm_content =topic_link&utm_medium=email&utm_source=reply_notification
I had to go back to LR43 and have had some trouble to go back to ACR 73 in PS CS6 :-(
Isn’t PhotoMatix or the PhotoMatix plug-in using the wrong profile (with a darker gamma) and LR 4.4 is now using the specified profile and the file looks bad?
Isn’t this something to notify the PhotoMatix plug-in developers about, not Adobe? I mean if Adobe was doing something wrong that masked the issue with the PM profile and is now doing something more correctly that has unmasked the problem with the PM profile, then it is the PM profile that is the problem.
some days ago I have written to Photomatix / HDRSoft. It seems to me that they will fix this (hopefully).
Nevertheless, one of the largest promises of LR (and of parametric editing) is: when the development of an image is finished it has to be rendered the same way FOREVER (as long as LR exists).
If Adobe breaks this promise then parametric editing does no longer make sense. Then pixel editing is the only way of making sure that the rendering of an image is not lost.
Therefore I strongly expect (and even if HDRSoft embedded a wrong gamma) that my image in LR43 looks the same in LR 4.x 5.x/6.x and so on!
Or, more specifically, PM is embedding the original raw photo’s color profile (appropriate for 16-bit gamma 1.8 images) in the resulting 32-bit image (which is a gamma 1.0 image) and this is not appropriate.
Up until now, LR was either ignoring the color profile entirely or at least ignoring the gamma, but now LR 4.4 is respecting this profile that has an incorrect gamma, so things look bad.
Are you asking Adobe to switch off their color management for 32-bit images to get around PhotoMatix assigning the wrong profile to the 32-bit image?
Unless you consider the situation being that previous LR’s had a “bug” in the 32-bit HDR rendering that was ignoring the profile and now that bug has been fixed.
Is 32-bit toning officially been announced in LR? One of the PS employees that monitors the forum a while back didn’t seem to know it was even in there, so if 32-bit toning is not official, then Adobe can change it however they want.
Having a particular toning method stick forever requires a new process version.
sorry, I fully disagree.
There have been many announcements about 32bpc editing in LR 4.1+.
Imagine, just as an example, PS Merge to HDR Pro would have an internal issue, not visible to customers. Let us say it is a bug. Can a customer accept that Adobe is just fixing this bug and therefore "destroying" tens of thousands (or even more) of already finsihed images of customers?
Again, I think, Adobe promised to render images the same way along all LR versions!
I would generally agree that there should be some way to preserve the current rendering until PM fixes their side of things.
PM has been naively just passing on the original component image profile which is totally inappropriate to their resulting HDR result—a bug in PM, perhaps; however, LR apparently used to ignore this profile or at least its gamma--a bug in LR, perhaps, and now it is strictly enforcing it w/o the user being able to control the resulting change.
I could see Adobe sticking to their more technically-correct interpretation and users, like yourself, who had unknowingly relied on the two bugs cancelling each other out, suffering as a result. Adobe probably has a good reason to do this, because they are trying to make things work with their own Photoshop HDR output files, which do have correct profiles in them.
Adobe could put a preference in ACR/LR to ignore color profiles included in HDR files or at least something about assuming a particular gamma, which would be messy, esoteric and generally confusing to anyone who doesn’t understand the issue.
PM could create their own HDR profile that is correct for their output, and be different than just copying the input profile.
PM could not embed any profile into the HDR output file, in which case LR would assume sRGB as the default, I think, which would still have the wrong gamma.
It would be good to find a workaround until, presumably, PM does something to correct the inclusion of an inappropriate profile.
For someone who has both LR and PS::
1) Does it work to create a new PPRGB profile with a 1.0 gamma and ASSIGN that profile to the 32-bit HDR TIF and resave it, before working on it in LR?
2) Does it work to open and resave the TIF w/o a profile? If LR was ignoring the profile, before, maybe this would be equivalent.
from my point of view there are 2 different approaches necessary:
(1) how to get correct 32bpc files from PM tools for NEWLY merged images
(2) how to deal with 32bpc files with wrong profile/gamma for EXISTING merged images
For (1) the best solution would be: PM/HDRsoft fixes its tools.
For (1), for the time being, I just tried this approach:
- generated a 32 bit tif file with PM plugin "Merge to 32 Bit HDR" 1.02
- opened this is PS CS6, discarded the embedded profile, then assigned a linear PPRGB profile, saved it
- copied the file to LR44RC in a virtual machine, imported the file, looked at it at 1:1 in loupe, was OK, went to develop, looked also OK, played around for 1 minute, seemed to be OK
- (BTW: one time I saw in develop mode a little black popup saying "an unknown error occurred"
Interestingly, when I use the PM Batch Application and output a merged OpenEXR file, this file has no embedded profile. So it is easy to assign a linear PPRGB profile to it and get a correct rendering in LR44RC.
For (2) I tried these approaches and all failed:
- opened existing 32bpc tif file (merged with PM plugin "Merge to 32 Bit HDR" 1.02) in PS CS6,
- in Embedded Profile Mismatch popup, I selected Convert Documents Colors to the Working Space
- copied the file to LR44RC in a virtual machine, imported the file, tried to render 1:1 and see an exclamation point in grid view and a little black popup saying "an unknown error occurred" in loupe mode
- opened existing 32bpc tif file (merged with PM plugin "Merge to 32 Bit HDR" 1.02) in PS CS6,
- in Embedded Profile Mismatch popup, I selected Discard the Embedded Profile, then assigned a liner PPRGB profile
- copied the file to LR44RC in a virtual machine, imported the file, tried to render 1:1 and see an exclamation point in grid view and a little black popup saying "there was an error working with the photo" in loupe mode. In grid and loupe mode the brightness and colors seemed to be OK but the image could not be rendered sharp, it stayed very soft forever. In develop mode I saw a little black popup saying "an unknown error occurred" and again brightness and colors seemed to be OK but the image was not sharp. And when I tried to change the exposure, LR44RC crashed.
Do these procedures match your suggestions? Is there any other approach I can try?
Still, I think, Adobe promised to render image across all LR versions the same way (using the same PV). And still I think customers can strongly expect that their already finished images are not "destroyed" by a newer LR version.
I would have expected the Discard-Assign process to work for already worked on images.
I’m curious if your LR 4.4RC is crashing due to something local or because there is something wrong with the image or modified profile.
Can you zip up your image, and the PPRGB-Gamma1 profile and put them on Dropbox? I’d like to try them on my LR 4.4 RC install that is not on a VM.
I am now very confused. This morning, after I tested the approach of discard-assign for an existing image, I deleted all test images. Now I tried to reproduce the behaviour again. But I can no longer get the same behaviour.
Each time after discarding and assigning the profile, saving the file and importing it into LR44RC, I can no longer see any LR43 adjustements in LR44RC. Sometimes I see now a gray preview instead of a dark image, in loupe mode and even in develop mode, And mostly it seems that all adjustments are forgotten.
Regarding putting one image in my dropbox. Unfortunately, due to copyright/IP reasons, this is not possible. If you instruct me how to upload it directly to an Adobe server and if only Adobe can access the image for testing, then I can upload an image.
BTW: For all my posting regarding issues with 32bpc editing, I have worked at least 8 to 12 hours to test stuff and to investigate behaviours. From my point of view, all I have done could have also be done by Adobe employees...
Chris Cox from Adobe described the HDR-profile problem, as of about a month ago, and they may or may not change anything in LR.
The issue we’re dealing with, here, is what to do about existing images that seem not to be working once the profile is fixed.
maybe these postings are referred to:
The second link is what I am referring to, which is a couple clicks into the thread referenced in Manfred/MJS7643's reply #3, above.
It seems what is different in LR 4.4 compared to a month ago when it was merely a warning in PS that was seen, is that LR 4.4 now actually respects the bad 1.8 gamma of the PM-embedded profile instead of ignoring it as it had in previous versions.
The issue that is still not understood is why a LR 4.4 RC on a VM is choking on the files that have had the ProPhotoRGB corrected to have a gamma of 1.0. This is, perhaps, unlrelated to LR 4.4 making things dark as the embedded profile tells it to.
I wonder if it would work to use Photoshop to change your ProPhotoRGB profile installed on your computer to have a Gamma of 1.0, or if that would only work with newly-imported files, too. Of course that would mean you can’t use PPRGB for any other types of files, anymore.
Unless LR 4.4 final gets a preference to ignore the gamma for 32-bit files, there’s not much that will save what’s already been edited that started out with the wrong profile if LR 4.4+ starts to honor the gamma in the profile.
I suppose Adobe can add an attribute to PV2012 that ignores the profile gamma for 32-bit files and then make a PV2013 that honors it, so all your PV2012 HDR files with the bad PPRGB-Gamma1.8 profile would still work but if PhotoMatix actually fixes something and embeds a correct profile, then you could set those to PV2013 and have things be ok.
It's not Adobe's problem to fix...yet I would not be surprised that Adobe might do something to fix it out of a sense of concern for it's users. The best solution is for PhotoMatix to fix the appearent error of their profile and provide a method for their users to "fix" the files where the wrong profile has been embedded...
BTW, adding a "preference" is a much more major bit of work than you are supposing...particularly when it's a 3rd party whose apps are incorrectly embedding broken profiles...just sayin'
good to hear that Adobe might work on a solution so that the 32bpc files with wrong gamma are still editable and rendered in LR44+ like in LR4.3.
What this incident shows to me: Adobe gave the promise to render files with the same PV in all LR versions the same. This is of course a very challenging promise and is necessary to make sense out of parametric editing.
For a LR / Photomatix plug-in user it was not apparent that there was a wrong gamma in the profile. LR 4.3 (and problably 4.1/4.2) was implemented in a fault-tolerant way and did "fix" somehow the (wrong) profile. Nothing about this "fix" was shown in the LR UI. So a LR / Photomatix plug-in user could be confident that all is working fine and all the many, many 32bpc files will be rendered the same for LR 4.x/5/6/7 etc (as long as the PV is not changed).
BTW: from my point of view the 32bpc editing facility in LR 4.1+ is really great. I think this is a unique feature for LR 4.1+ . I am not aware that there is another powerful image editor which supports 32bpc editing for all features and functions. I would be happy if in some years Photoshop would support fully or mostly 32bpc editing too...
Big problem is that now I'm stuck. Don't know what to do and I fear that creating new HDRs with Photomatix LR plugin can only worsen my situation. I need some clarification about what's going on. I've written today to HdrSoft but got no answer yet.
While waiting for PM to fix things and for Adobe to re-accommodate what PM has already done wrong, any new HDRs you create with PM should probably have their profile stripped with Photoshop prior to import into LR 4.x to avoid LR seeing the bad gamma.
I assume this would work, but perhaps LR would assume sRGB Gamma 1.8/2.2 which would still be wrong, so a further refinement to this would be to actually create a gamma 1.0 version of whatever profile(s) the input images have that PM is currently erroneously embedding in the HDR result image (the one specifically mentioned in this and other threads was ProPhotoRGB), and use PS to ASSIGN that profile to the HDR result and embed that profile upon saving from PS, so no matter whether LR is ignoring the gamma or interpreting the gamma, the correct result will occur.
This is still not an answer to what to do with the accumulated two-wrongs-make-a-right HDR images that LR 4.4 RC is now showing with the embedded gamma, but it should work for new HDR images coming from PhotoMatix.
Breaking news!! There's a beta from HDR that could help. I'ma away and can't try right now, anyone can see if it works in the meantime? http://www.hdrsoft.com/support/faq_merge_lrplugin.html#lr44
I just tried the PM plug-in 1.1 beta on WIn7 64bit on one set of bracketed images. After merging I opened original in PS CS6 and PS does not complain about the profile and shows a linear PPRGB profile. Then I imported the file into LR 4.4 RC running in a virtual machine. For me this 32bpc image looks good in LR44RC.
Of course this was not a thorough test and validation. Just a quick try.
I've tested the new 1.1 beta plugin on MacOS 10.8.2 and LR4.4RC and works perfectly. BTW the new strong deghosting is wonderful. HDRSoft says it's working on a tool that will fix all the previous merged 32bit files. So, I'd say, we're on the right path!
Here is how you create a Gamma 1.0 ProPhotoRGB profile for embedding in your images. These are the Windows menu paths so maybe the first thing is different on some:
PS -> Edit / Color Settings…
In the Color Settings panel in the RGB Work Spaces dropdown choose list the following items one after the other:
Choose: Load RGB … and select the ProPhoto profile file
Choose: Custom RGB… and adjust the gamma to 1.0 and change the name from Custom RGB to something that makes sense
Choose: Save RGB… and save out the new ProPhotoRGB-gamma 1.0 profile with a file name that makes sense
To Assign this profile to one of your HDR images in Photoshop:
PS -> File / Open one of the HDR images.
PS -> Edit / Assign Profile…
Click the radio button next to Profile: and choose the new profile you’ve named and saved above from the dropdown list.
PS -> File / Save As… to save your HDR file as a new name to test with LR.
thanks for explaining how to create a custom Gamma 1.0 ProPhotoRGB profile and assigning it to own 32bpc files with wrong profile/gamma.
I just followed your procedure. After assigning my custom profile to a 32bpc file (generated with the PM plug-in and therefore the wrong gamma) I copied this file to a virtual machine and imported it into LR44RC.
In the import dialog I saw proper colors and brightness. After rendering the image 1:1 in the grid it looked still OK. But ... there is a black exclamation point top right saying "LR has encountered problems reading this image". I can enlarge the image to Fit mode and still the colors and tones are fine (but the image is blurred/not sharp). And there is a small black popup saying "There was an error working with the photo". And when I go to develop module colors and tones are OK (but not the sharpness) and there is again a small black popup saying "An unknown error occurred".
Just an idea: the virtual machine is running Win8 32bit with 3GB usable memory. Could this small amount of memory cause the issues within LR44RC?
So my questions is: do you think that creating a custom linear PPRGB profile and assigning this to the "bad" 32bpc files should resolve the LR44RC issue?
If I remember, you’ve been getting errors on your LR 4.4 RC on the VM for several things you’ve tried. I am not sure if the image is the problem or the VM.
Did you also copy that custom gamma-1 profile over to the VM so LR can find it over there? You might want to install PS over on the VM, too, so you can do all your work over there, instead of only part of it.
I just installed a new VMware Workstation virtual machine, running Win7 64 bit with 8 GB memory and copied my host display profile to the virtual machine and added it to the Win7 color management.
I did not copy the custom linear PPRGB profile from the host to the guest. From my point of view this is not necessary because PS embedds the custom profile into the 32bpc file.
Now when I copy a 32bpc file with a previously wrong gamma and with an assigned custom linear PPRGB profile and import this into LR44RC in the virtual machine, all works fine :-) Colors and brightness are OK and no more strange popups about some LR errors.
So it seems to me that your procedure to assign a custom linear PPRGB profile is fixing the bad rendering.
Many thanks for your help !
BTW: From my point of view it would be more than helpful if LR44RC explains in detail why it sends small black popups like "LR has encountered problems reading this image" or "There was an error working with the photo" or "An unknown error occurred". Probably the root cause of these message have been out of memory issues. LR probably knows this, but LR does not tell this to the user...
Either it was a coincidence or the errors were because the PPRGB-Gamma1 profile actually needs to be installed on the computer LR is reading the image data from, not just embedded in the image. You could remove the profile from the VM temporarily and see if the error comes back and then put it back and see if the error disappears.
>Either it was a coincidence or the errors were because the PPRGB-Gamma1 profile actually needs to be installed on the computer LR is reading the image data from, not just embedded in the image.
Hmm, this might be a misunderstanding. As I have written in my last posting, when using LR44RC in a Win7 64bit 8GB VM, I did NOT copy my custom profile to the guest OS. It was just embedded in the image and worked well.
So for me there is still a need for LR44RC to handle the assumed out of memory issues with proper messages to the user. Only sending small black popups like "LR has encountered problems reading this image" etc is not helpful to resolve the issues.
HDRSoft has posted a beta fix for the old files. I've tested it personally and works perfactly.
This is the link for the beta download: http://hdr-photography.com/download/beta/Upgrade32bitTIFF1.0Beta2.zip
Test and report if you find problems. I've found none.