メインコンテンツへスキップ

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

Problem with exported images when I try to open in Lightroom

コメント

22件のコメント

  • H. Cremers
    I won't ask why you are using LR 😉 😉

    But, when you have a problem with LR loading images in its library, it strikes me as odd that you've come to the Capture One forum to ask what the problem is.

    Obviously, i cannot help you. Can you open the C1-8 exported images in another browser? It may have something to do with file support of your LR version, or perhaps simply file privileges.

    Who knows someone else can help, there seem to be quite some LR and Aperture "refugees" here 😎
    0
  • NNN635393881947243607
    Same issue was here, not even Lr4 import those. I updated to Lr5 and it works fine. Maybe it's something to do with the older Lr, but how come, it's weird.
    0
  • Drew Altdo
    Has anyone asked Adobe why their software does not open the files? 😉
    0
  • NN635142464227298396UL
    Drew, I don't think it's appropriate to ask Adobe what CaptureOne's dev team changed with their processing engine so that now all the exported files are corrupt.
    0
  • Drew Altdo
    [quote="NN635142464227298396UL" wrote:
    Drew, I don't think it's appropriate to ask Adobe what CaptureOne's dev team changed with their processing engine so that now all the exported files are corrupt.

    But that's not what's happening.
    The files are viable (as you can see in Lightroom 5) and meet all file standards for format. So, the question remains, what makes Lightroom 4 different from Lightroom 5 where the same files are seen by one but not another.
    Do you have any conflict with the files in Photoshop? Bridge? Preview? Image Capture? iPhoto? etc?

    I just find it odd that files not opening in specific version of another software is not addressed to the manufacture of that software. If it was an issue for every software, regardless of version, it would clearly be something we need to look into. However it's just an older, specific, version of Lightroom.
    0
  • Drew Altdo
    Looking into this further, it doesn't seem to be an issue with Lightroom seeing the files but instead the Import Feature crashing.
    So, it seems clear that Lightroom can see the files but importing is problematic.
    Not knowing the specifics of their software and the import process I cannot say why but anyone with this conflict is certainly welcome to contact Lightroom so we can shed some light on it.
    0
  • Michael Ruddick
    FWIW I am seeing similar issues on a Windows7 machine...in my case LR4.4 cannot import Pro8-exported DNG, TIFF, or JPG.

    I am trying to discern what is differnet in Pro8's vs ver7's exports, but haven't found a smoking gun yet.
    I also posted on Adobe's support site to understand how LR4.4 vs LR5.6 differ in their ability to ingest/import files.

    Either way, my process flow got broken with Pro8, too, and I'm hoping to not get forced into an LR5 upgrade.

    One way I found around the issue, although not efficient or good, was to export a TIFF from Pro8, bring it into IrfanView (free viewer), then save as JPG. That JPG is importable to LR4.4, for whatever reason. This is fairly goofy and destructive to the image, of course, but was more of a way I found in trying to understand what changed in Pro8 that affected LR4's ability to import.

    Mike
    0
  • Michael Ruddick
    I have created a question on Adobe's community support site:
    https://forums.adobe.com/thread/1584230 ... 0&tstart=0
    in case anyone in this forum would like to contribute on the effort to understand, from Adobe's perspective, what has changed from their LR3/LR4 importing methods, to LR5's...which may in turn clue those of us interested into manipulating Pro8's output to be importable to LR3/4. <fingers crossed>

    -Mike
    0
  • Drew Altdo
    We're certainly looking into this, and as Mike pointed out it does seem to be due to a change in the embedded thumbnail.
    However, it is still beyond us as to why Lightroom 4.4 would not honor the files as they are indeed valid and viable. There may simply be something within the Import process alone that requires thumbnails be written in a very specific way to accommodate the process.
    As Lightroom 5 shows no issue, it's clear that this specific requirement in Lightroom 4.4 was changed. However, not working for Adobe I do not know the specifics or reasoning behind it, it simply seems that Lightroom 5 import was written to avoid these potential conflicts in otherwise valid files.

    Hopefully we'll be able to find a workaround on our end that will accommodate Lightroom 4.4 users but for the moment it seems Lightroom 5 is your best bet.
    0
  • Permanently deleted user
    Today I tried to import a 16-bit tiff that had been created in C1Pro v8, into Lightroom v4.4, and as others seem to have discovered, the import process just hangs and I have to close LR completely, although the thumbnail is visible in the import browser. I can open the suspect file without problem in Windows Photo Viewer, Breeze Browser Pro v1.9.7, and Picture window Pro v6. I'm on a Win7 Pro 64-bit machine.Two things to note:

    1) If I save the file in PWPro as another tiff, it will import into Lightroom
    2) The thumbnail view in Breeze looks different, in that the C1v8 tiff fully utilizes the size of the placeholder, like all my other files do, whereas C1Pro v7 tiffs were significantly, and unusually, smaller in size within the placeholders.

    Ian
    0
  • Michael Ruddick
    I don't believe that the embedded thumbnail is the sole issue that makes LR4 barf on itself during import.
    I did noticed the thumbnail difference before, and putting a new thumbnail into a JPG that LR4 could not ingest did not help matters.
    Granted, the thumbnail may be one of the issues, but pretty sure it's not the only issue at hand.

    On another thread, someone pointed out to me that JFIF standards may have evolved, and LR4 may have problems with the newer standard. I don't know much about JFIF, but as I poked around with it, I was able to use a plugin in IrfranView that rebuilds the thumbnail *and* either strips or rebuilds the JFIF information. I think I told it to strip alot of the JFIF information away, and guess what? That JPG could be ingested by LR4. So I kinda feel like I may be closing in on more detail, with everyone's help, and surely appreciative that Drew's keeping pace to see if there might be a not-so-painful way around this to satiate the LR4 or LR3 users.

    Something that still makes me wrinkle my brow, though, is that TIFFs and DNGs are equally affected. I have no idea how JFIF standards do or do not apply or get used in TIFFs or DNGs, but something tells me I might be learning along the way, LOL.

    I may have to resurrect some exiftool memories and tools to continue the surgery. I remember that package being incredibly flexible when I wanted to play with specific EXIF information as an image moved through my workflow; different apps would muck with exif data differently, sometimes clobbering things I wish would've stayed intact. Exiftool gave me a path to batch process files and just replace specific fields from the original image file. If exiftool understands JFIF, it might be a useful tool here.

    -Mike
    0
  • Permanently deleted user
    Well Mike, I'm afraid that is all above my head. However, for what it is worth, my copy of Breeze was installed in 2011, and PWPro in 2012. Now I don't know when the new standard came in, but I would guess after my copy of Breeze, so it is interesting that that application can open the file, unless it is just purely fortuitous. Similarly for PWPro, though it too is interesting in that the tiffs that it produces are importable into LR4.4. I don't know what standard they comply with, but it could be found out.

    I'll have to leave the issue in other, far more capable, hands!

    Ian

    Edit. Ah, just looked up JFIF and see that it refers to jpegs. Not sure what standards there are for tiffs though.
    0
  • Michael Ruddick
    Yeah, the inner workings of the files themselves, we tend to not have to care, right?
    JPEG is the method that makes the files smaller (the compression); JFIF is the standard file format that puts pieces of information in the right places, with the right identifiers (headers, etc), and stuff like that.
    I always thought of JPEGs as JPEGs, a rose is a rose...but not so simple.

    Anyhow, I found another decent temporary solution to importing Pro8-exported JPGs into LR4. I suspect this solution recreates what Ian has discovered with Breeze or PWPro.

    I used IfranView, and one of the available plugins "Jpg_transform.dll" When that plugin is loaded, Irfan has an option under Options called "JPG Lossless Rotation". Within that dialogue, when opened, if I select
    None for the Transformation option,
    Optimize JPG file,
    Apply original EXIF date/time to new file,
    Write JFIF maker,
    and (most importantly) Clean all APP markers
    then the JPG file is rewritten and able to be imported into LR4.
    The nice-ish part of this method is that I believe it is ONLY touching the JFIF information, not anything with the image information.
    IrfanView also supports an easy batch method to do this by using their thumbnail view, selecting multiple pictures, and then right-clicking to get into the same JPG Lossless Rotation options. It's very fast.

    I don't know how TIFF or DNG files may be manipulate-able in a similar fashion to get LR4 to behave with them, but may poke at it some more, I dunno. It would be nice to have something available when I want to keep higher bit depth integrity through the edit process, but realistically, that doesn't happen all that often I suppose.

    It should be noted there were options to rebuild thumbnails, as well...and that option did not seem to have any bearing on LR4's ability to import. The primary attribute seemed to be the "Clean all APP markers". I don't know exactly what that option does (e.g. remove them, reformat them, etc).
    I also did not try playing with all the options to prove out that the APP marker cleansing was the sole determinant of being able to import to LR4.

    Hopefully this provides some clues in case the PhaseOne dev team wants to entertain creating an export recipe that enables a kind of 'compatibility' mode for LR4 (and probably LR3) users' sake. Or an option in the export process to maybe dumb down the JFIF contents.

    -Mike
    0
  • Permanently deleted user
    You know, Capture One's "difficult" relationship with tiffs is not new. About a year ago I raised a ticket about an issue with tiff import to C1Prov7. When I tried to import tiffs (created in PWPro) into C1, the import browser would only show empty place-holders for those tiffs (i.e. no thumbnail), but did include the file name. I could select them and import them, whereupon they would be visible in the browser and could be selected and viewed in the viewer. None of these tiffs gave a problem in other programs, including LRv4.4. After a protracted dialogue, Phase 1 responded with "Thanks for the clarification - we have seen the same and will report this to R&D - they will then decide when and if we will fix this in a future release." and "We will close the case for now from Support - just to say it's not left in cyberspace but reported to R&D in Phase One as listed in previous post. It wil be looked at 😊"

    I've just checked out C1Prov8, and it behaves the same way! I created a 16-bit Adobe space tiff and an 8-bit jpeg in LRv4.4, and I created a further tiff copy by re-saving the LR-produced tiff in PWPro. Both of the two tiffs gave empty place-holders in the import browser in C1Prov8, but could be imported and opened in the viewer. Interestingly, the jpeg appeared to work normally. So it seems to be a two-way problem - both importing and exporting.

    Somewhere along the line C1Pro is not talking the same language as the other applications. Where the fault really lies is anyone's guess, but however well C1 "complies" with some standard, it does seem to be the odd one out.

    Ian
    0
  • SFA
    [quote="NNN635108010324039495" wrote:


    Somewhere along the line C1Pro is not talking the same language as the other applications. Where the fault really lies is anyone's guess, but however well C1 "complies" with some standard, it does seem to be the odd one out.

    Ian


    One of the problems of Computing is that absolute compliance with published "standards" is not a guarantee that things will always work smoothly.

    There have been many many examples of applications with publically published standards that third party developers "must" use (according to the developer) that do not always follow the rules for the standards they claim to use.

    Bear in mind that the Standards are usually set by the bigger names in the industry or a specialist field within the industry.

    This makes things awkward for developers who clearly need to be seen to be following standards AND allowing for common anomalies outside the documented standards in order to make a practical application that works with whatever it may be fed. However unless people creating the code know about the anomalies to do so may be extremely difficult ... and time consuming and code bloating, performance sapping and so on.

    Given the reports in the thread that LR5 does not seem to have a problem that may suggest that all the parties are working with (or close to working with) a common set of standards and available knowledge of anomalies in the most recently developed applications.

    Or it may just be pure chance ....



    Grant
    0
  • Drew Altdo
    Hey All,
    Just chiming in here to give you the low down.

    It seems that Lightroom 4 has a bit of a bug in regard to Keyword handling.

    In Capture One 8 we've introduced the standard for including Keywords in processed files. This includes Hierarchical Keywords which was not available in Capture One 7.
    When Capture One 8 process' an image without any keywords, the field where they would reside is still present in the file but is of course blank. When importing into Lightroom 4 this blank field is what stalls the import process. Lightroom 5 does not have this conflict as it correctly skips the field if no Keywords are available. As should occur. No issue with the files, no issue with the thumbnails, just a conflict with proper handling of Keywords or a lack thereof.

    So, as an immediate solution to those with this issue, please simply add a Keyword to the processed files in Capture One 8 and Lightroom 4 can then complete the import process as there is data present in the field.
    In the future, we may introduce a non-standard change to the processing of files so that if there are NO keywords in the file, when processed it will simply omit the xmp field for Keywords (this does not fit current standard). However this would be a special workaround specific to accommodate Lightroom 4 and we do not know yet what effect this will have on other standard software so I'm not sure how much priority this will be given.

    Alternatively one can upgrade to Lightroom 5 which does not have this conflict.
    0
  • Permanently deleted user
    Thanks Drew, that seemed to work OK. I can only assume that the act of importing the tiff into PWPro and re-saving, before importing into LR, effectively omits the empty field from the re-saved file.

    Ian
    0
  • Drew Altdo
    [quote="NNN635108010324039495" wrote:
    Thanks Drew, that seemed to work OK. I can only assume that the act of importing the tiff into PWPro and re-saving, before importing into LR, effectively omits the empty field from the re-saved file.

    Ian



    Very likely if not a definitive yes... however it may also be effecting other data fields, can't say for sure.
    0
  • Michael Ruddick
    BEAUTIFUL Drew, this in fact fixes the issue.
    I also verified that adding a keyword in Pro8 produces exported JPG, as well as DNG and TIFF, that LR4 can import.
    Thanks so much for digging in and finding a way to make LR4 behave from within Pro8.

    One last question, which I may be able to find an answer elsewhere, but... if I want to add a keyword, say "Goliath", to several pictures in Pro8, what is my fastest route?

    I don't see how to select multiple pictures and then apply the keyword addition to them all.

    Instead, it looks like I can add the keyword to one picture, then copy this to the Pro8 clipboard, then apply to multiple other pictures.

    Just checking to make sure I am not missing a quicker route of multi-selecting and applying the keyword change...but suspect it might be some combo of ctrl/shift/alt and clicking the clipboard copy or something.

    Thanks again Drew!

    Mike
    0
  • Drew Altdo
    You're not missing something.
    The design is supposed to allow the "+" button to apply to all selected images but at present it looks like this function was broken just prior to release, we're looking into it.
    0
  • SFA
    [quote="Drew" wrote:
    You're not missing something.
    The design is supposed to allow the "+" button to apply to all selected images but at present it looks like this function was broken just prior to release, we're looking into it.


    FWIW I was going to raise a support case about this "+" question as the User Guide description mentions it but I could not get it to work (on Windows). Presumable I can forget about the Case now and save everyone some extra admin?



    Grant
    0
  • Michael Ruddick
    For anyone interested in trying to drive a Lightroom 4.x solution, see
    http://feedback.photoshop.com/photoshop ... -lightroom
    as you can +1 the topic to vote that you also have the problem.

    On that discussion thread, Adobe has confirmed the bug in LR4.x that hangs on empty fields. That topic thread at least has an Adobe employee participating, which is good to see.

    (Thanks to Drew's investigation, I could also post a workaround to add a keyword from within Pro8 to get LR4 to behave.)

    -Mike
    0

投稿コメントは受け付けていません。