Jump to content

fritzunruh

Members
  • Posts

    36
  • Joined

  • Last visited

Posts posted by fritzunruh

  1. Hi,

     

    Big thank you Gus for uploading the photo and the very specific directions for fixing this problem (the same issue that I'm having!).

     

    Since the original photos have disappeared though, I just wanted to confirm that my camera is experiencing timing issues in the same direction as the original poster; please excuse the boring picture...

     

    [ATTACH=full]1283775[/ATTACH]

     

    In another forum I was reading, the individual was experiencing this issue from the other direction, (meaning that his second curtain was catching up to the first?) - The Classic Camera Repair Forum: Problem with shutter curtains speeds?. In my case, if I understand it correctly, the first curtain is is opening too soon, and the second is then too late (?).

     

    I just want to know, before I open my camera up, that following your same instructions: turn the first curtain 4 increments counter-clockwise OR turn the second curtain 4 increments clockwise will resolve my timing issue in the correct direction.

     

    Thank you in advance!!!

     

    -Alex

     

    Did you sort this out? I'm having the same issue with an A1 and would really like to turn it into the correct direction as well.

    • Like 1
  2. This is a problem with the camera, not the lens. The shutter curtains seem to be moving unevenly at the the slower speeds which would be needed at smaller apertures.

     

    I looked into it a bit - I'm afraid you're right and its shutter capping...

     

    Does someone have a source on how to address the tension of the shutter springs and maybe even get to the parts that might need lubrication on a Canon A1?

  3. This is a problem with the camera, not the lens. The shutter curtains seem to be moving unevenly at the the slower speeds which would be needed at smaller apertures.

     

    I really hope you’re wrong :((

     

    Most of the pictures of that roll were shot a the fastest shutter the camera offers (1000th), the ones that show the problem were definitely shot at that way though!

  4. Hey guys,

     

    I encountered a problem and was hoping somebody might have seen it before and can tell me if my suspicions are correct and my lens is somehow broken. I got hold of a Canon 35-70mm f4 FD Lens for my A1, which looks good and does work without issues on multiple shots but when stepped down quite a bit (probably above f8) theres a huge area that is heavily underexposed.

     

    analogscan_200421-00023-6.thumb.jpg.22a885b69f554440a0de426d6980dd35.jpg analogscan_200421-00024-6.thumb.jpg.e4e578bd074e0efe8df5bcbc67af0afb.jpg analogscan_200421-00025-6.thumb.jpg.1b7f36c1c27f1afd888a5cfeb56a121c.jpg

     

    It is definitely nothing in front of the lens or inside the body that is blocking the light either, most of the shots of the roll are fine.

     

    This is what the aputure blades look like... I feel they should be more evenly round then they are, or am I wrong?

     

    IMG_5825.thumb.JPG.6d9f49ce4e8773bc6a5a74b2ed444a38.JPG

     

    Testing on a digital camera with adapter works without issues on all aputures, although they do not close when I take a picture.

     

    Did someone see this problem before? Is the lens one for the trashcan?

     

    Thanks a lot!

  5. I would add that if you don't need ACR (not processing a RAW image), why use it at all? If you don't need to use the PNG format (e.g., for web display or email), which is only one notch better than a BMP or GIF, why use it? If your scanner (LS8000) is capable of 14 bit color depth (rounded up to 16 bit), why scan in 8 bit mode.

     

    The LS8000 has three parallel rows of sensors for faster scanning. If you get horizontal banding, as in wide areas of neutral density with little detal, it is painfully obvious. Should it occur, use the "Fine" scanning mode. It is not present in any of the images shown so far.

     

    Cleaning of an LS8000 should be left to a professional, if you can still find one. The optics, particularly the sensor, can only be reached with major disassembly of a complex mechanism. Only dust near or on the sensor will produce any visible effect. Vertical banding of the sort somewhat visible in the examples is too broad to be due to dust bunnies. More likely, it is caused by irregular development. Since ithe image is lighter in the center, I would suspect vignetting or diffuse ghosting.

     

    8 bit images have very little tolerance for digital processing, and easily leads to banding and posterization. I have no problem sending 8 bit JPEG images out for printing, but only after they are exported from 16 bit masters.

     

    I see, unfortunately I don’t have access to the scanner easily to try again in 16bit.

     

    I do eventually want to use ACR or LR for edits, I just left out the editing part for testing what might cause the artifacts.

     

    My problem and question is why it looks the compressed way it does after leaving LR or ACR as a lossless tif or png export. The problem doesn’t exist before, shouldn’t a lossless export no matter what bitsize look just like that - lossless? Or at least not create heavy compression artifacts I’d expect from a low quality jpeg? Because thats what’s happening and I have no idea what could cause the issue or if it just happens on my system for some reason.

  6. The info I'm getting from your scan is that a Nikon LS 8000 was the scanner.

     

    It says ...

    Device make: Nikon

    Device model: LS8000 Filmstrip

     

    These scanners are known for banding, perhaps horizontal banding, I'm not sure which, but I think most users check "Fine" mode to eliminate the banding. Also the mirror and lens needs cleaning regularly if used every day and if not in a pollution free environment.

     

    I picked up two bands in your original scan, they are very faint but are in the same position as the two same bands in the other pics that show the bands more prominently. The pic needed de-sharpening to see the bands better and by following them down into the sea, there's vertical lines. There should be no vertical lines in the waves.

     

    [ATTACH=full]1338024[/ATTACH]

     

    Thanks, I know that there’s a little issue with this banding in the original file, my main problem is the way it looks after leaving LR or ACR as a lossless tif or png, because it looks way different from the source data.

  7. Start with and edit high bit data.

    http://digitaldog.net/files/TheHighBitdepthDebate.pdf

     

    IF you opened then saved through ACR/LR, the data was reprocessed. With no edits makes even less sense.

     

    Think about this a bit; you've got an original 8-bit per color TIFF and you're running it through the ACR engine again, exporting it somehow and now you see data loss. Don't do that on 8-bit per color data; you're losing image quality for a reason I'm as yet still not sure why.

     

    It makes a lot of sense to test where the issue is and eliminate the edit as the root of the problem.

     

    So your theory is that there is no problem at all and it’s just because it’s 8-bit?

     

    That would mean that if you were to open the tif in ps through ACR (like I asked before and you asked why on earth you would do that) then exporting a lossless png you could replicate my compression artifacts exactly, right? That’s a way of tackling a problem and finding out if it’s just you, the software, the hardware or no real issue.

  8. It's a problem because you're further globally editing the data (and for what reason?)

     

    I‘d like to be able to edit the picture without introducing artifacts. The reason I‘d like to do so is to apply creative edits such as crop, contrast and color. Is that impossible in your professional opinion?

     

     

    So what edits did you apply to the data in either and why? How did you export them?

     

    None, the artifacts appear without any further edits whatsoever. I exported them in any way I could imagine, see above. Exporting is not necessary to get the artifacts either, they appear as soon as the image is processed by ACR and opened within photoshop.

     

     

    Again, I can take the data and save it as a JPEG at quality level 3 and introduce data loss; why would I and should I be surprised to see data loss? No.

    Was the original high bit data? What I downloaded isn't. It's 8-bits per color.

     

    I’m still not sure in what way exporting a quality level 3 jpeg is practically comparable to opening the image through ACR. Theoretically I understand that I might be inducing a step of processing the image, that has an effect on it, but I can’t believe it has such a massive destructive impact and that’s just the way it’s supposed to be.

  9. Why on earth would I do that? It's a TIFF. It is rendered.

    I also didn't save it as a JPEG with loads of compression and then looked at it, why would I?

     

    Because that is where the problem is! Lightroom and ACR seem to run a similar engine that both cause this problem, I‘m aware that the file itself isn’t the issue but the processing through LR/ACR, that’s why it would be interesting to see how it goes on other systems.

     

    How is exporting a compressed jpeg and opening a TIF with LR or ACR the same?

  10. Looks as if you now have it narrowed down which is good. Apparently ACR engine or Graphics card related. Note that it is not uncommon to have bugs in the software for graphics cards that can create issues. Sometimes they are specific to the OS, ACR version, and or Graphics Card (and its driver version).

     

    So this is now a bit beyond what I can help as I do not have your combination of hardware/software.

     

    I do suggest a couple more things in your debug process

    - When viewing previews in LR, make sure you use just the Develop Module and only at 100% (1:1) viewing.

    - Make sure you are viewing the original image and not a Smart Preview

     

    To further the narrowing down of the problem, the Camera Raw Preferences (in Photoshop and Lightroom) allow custom settings for use of GPU separating out vewiing and image processing.

     

    After that, seeking help on the Adobe/Apple/AMD Radeon help sites or product support to narrow down the issue. If narrowed down enough to an unresolved issue, if you can find someone that can duplicate it on their system (I cannot) then you could submit a bug report to Adobe.

     

    Thanks for sharing your information as when I do upgrade to Catalina and a more recent MacBook Pro eventually, I will know to watch out for the potential of the issue you came across.

     

    Tried the custom settings already, unfortunately no change.

     

    Thanks for trying to help, it really is an odd problem, just glad that I‘m not just too stupid.

     

    I just got in touch with Adobe, something I should have done earlier, they offered they check the file and try to replicate the problem on several systems - I‘ll let you know how my odyssey ends.

  11. To help narrow down the issue a question and a suggestion

     

    You said the version of LR was 3.2.1 I am confused as that would be Lightroom 3. Are you using the most recent version of Lightroom Classic or something else?

     

    Though I am skeptical that it is related, you incoming image is in Adobe RGB color space and exporting you change to sRGB color space. This should not cause a problem yet who knows.

     

    Also, there is PS and LR vs exporting vs using Save and Save As

     

    To narrow down the issue I suggest a couple steps.

     

    - In Photohosp, go to Preferences and turn off all GPU acceleration

    - Also make sure that the Preferences are set to go directly into Photoshop and not through ACR

    - Bring your original image into Photoshop and verify at 100% magnification (or 200 or 400%) that there is not fuzzy areas

    - Note - make sure you keep the file in Adobe RGB and don't change to sRGB

    - Use the File > Save As command and save as a PNG file (so no lossy compression)

    - Bring that PNG file back into Photoshop and verify that the is no fuzzy areas

     

    I will assume that it will come back just as the original with no fuzzy areas yet if wrong, just report back the problem and don't follow steps below

     

    If you are at this point you have a baseline where you save the file and did not have a change. Each step below should be taken individually and not in combination by making the change in the steps above to test it out

     

    1) Do the above yet first make sure that GPU acceleration is turned on in Photoshop

    2) Do the above steps with the only change use the Save for Web legacy function (do not change to sRGB and leave that unchecked) (do not change image size)

    3) Do the above steps with the only change being using the Export function in PS (with and without changing to sRGB)

     

    4,5) Add GPU acceleration with #2 and #3

     

    6-9) Change Preferences to go through ACR before entering into Photoshop and do the prior combinations.

     

    I think one of the above combinations finally ends up with the problem occurring the way you said in Photoshop and this should help isolate which area is the root cause.

     

    It is just the divide and conquer approach.

     

    You could use using LR or not as a variable and which format you save in as a variable yet not sure that would be necessary.

     

    Hope this helps track it down.

     

    Thanks for staying with me in these hard times, John.

     

    You're right, disabling ACR helped photoshop being able to save as a png without issues.

     

    1) Turning on GPU works, too.

    2) Web-legacy export to png works (although with reduced contrast)

    3) PS export works with and without sRGB (the latter with reduced contrast)

    4,5) Works with GPU as well

    6-9) When just the GPU for ACR is deactivated, the issue appears within ACR preview as well as in PS as well as in all exports.

    When GPU for ACR preview is activated but processing GPU is deactivated the issue doesnt appear in ACR preview but in PS as well as in all exports.

    When GPU for ACR is completely activated the issue doesnt appear in ACR preview but in PS as well as in all exports.

     

    In conclusion, it seems that a GPU acceleration is needed for the whole process but fails when the data is handed over from ACR to PS - exporting directly from ACR produces the error as well.

  12. Adobe Camera Raw is a rather blunt tool for rendering images. I was curious why Adobe Bridge would treat TIFF images from a scanner as though they were RAW. Bridge has not been my image catalog since Lightroom was invented, and I never installed in on my Mac. Until you establish another default image editing program, Bridge will use Camera Raw for everything. RAW images from a digial camera will still resort to Camera RAW, even if you open them in Photoshop.

     

    Camera RAW defaults are found in an unobtrusive line near the bottom of the window. I noticed immediately that my 16 bit TIFF files were listed as 8 bit. Clicking on that line opens the size and format defaults for ACR, which could be the reason the pixel size is doubled. One of the options is resizing. There seem to be discrepencies in color space too. (Bridge goes back into the dust bin for me.) Of course you can keep the same number of pixels and change the size or resolution (in PPI) without resampling. Photoshop and Lightroom don't care - the display is unchanged. However not all display programs are as forgiving, and size rather than pixels matters when setting up a print or print preview.

    .

     

    Noted, but ACR was just one of the applications resulting in the issue? PS and LR do the exact same thing.

     

    The vertical banding shown above appears to be due to aliasing or Moire patterns from the resampling process. A less obvious source of banding occurs when images of a low gradient in medium tones (e.g., blue or grey sky) are displayed on a monitor with 8 bit color depth. There are only 256 possible tone densities in 8-bit resolution, so the dividing lines become visible. You see them on the monitor, but they're not necessarily in the image.

     

    But they are in the image, you see them no matter the level of magnification?

  13. After using your original image I could not recreate you issue. Comparing your two provided images, I did fine a 75 pixel x 75 pixel grid of pattern that coincided with the appearance of blur. Note that is a preceived blur yet I believe is a subtle change in luminosity between the sharp and duller areas.

     

    You can see the pattern that I could extract in the image below.

     

    This is definitely in the processing pipeline somewhere and apparently not in the magnification or slight resizing.

     

    I suggest several things

    1) Turn off GPU acceleration and see if it goes away.

    2) Make sure you have the most recent versions of you OS, PS, LR, ACR, and GPU firmware (could be bugs discovered before)

    3) Let forum members know which OS, PS, LR, ACR, and GPU you are using for further help.

     

    i-dGvpf42.png

     

    Thanks John.

     

    The graphic acceleration hint brought another tiny piece to the puzzle. As soon as I turn it off, the issue can be seen inside of the preview LR as well. When I turn the acceleration back on, the issue is gone in the preview (as seen in my first posts screenshots). Unfortunately turning it off or on doesn’t help the exported result.

     

    Apparently the hardware acceleration is needed to prevent what is perceived as blurry, but is not used while rendering the image to export - is that just my system?

     

    Current versions:

    OS: MacOS Catalina 10.15.3 (I'll update to 10.15.4 after this reply)

    GPU: Radeon Pro 560 (A0.927, drivers linked to OS)

    PS: 21.1.2 (up to date)

    LR: 3.2.1 (up to date)

    ACR: can' tell the version number, but up to date

  14. The Eizo should be a high bit panel but the video card?

    If you don't see any banding, and it's high bit data, you're good to go. And sure, it's possible there is banding in that data, certainly if you see it on a high bit system or the data is indeed high bit (where it came from is the $64K question).

    It's possible it came about prior to being 'converted' to high bit.

    Photoshop and newer Mac OS are indeed high bit capable but you'll need to check the video card. Likely it is. You can get this info from System Report (About this Mac), Grahics>Display as well as looking in Photoshop's General Preferences > Performances, Advanced Graphics Processor Settings (30-bit display).

     

    Yes, its a 30bit display with an 4GB Radeon Pro 560 GPU.

     

    I see banding on every screen, setup and level of zoom, just after I exported the image - not prior.

  15. Thanks a lot for taking the time, it makes total sense that the bending comes from the scanners sensor, what I cant get my head around is the fact that its not there in the original scanned file but only appears after I export it from lightroom / photoshop / camera raw whatever. And its not the editing either, since it looks absolutely fine in the preview of those programs, no matter the zoom setting.

     

    I wouldnt mind a slight shift of brightness that you made visible very well, I do mind the muddy and blurred grain pattern, which just is not in the original file!

  16. Visible banding can be caused in two vastly different areas: The data itself OR the display path (perhaps both).

    If the image is high bit (16-bit per color even though it's rarely that encoding), the banding seen is likely instead in the display path. IOW, it's not in your data. That may explain why you don't see it in Develop at 1:1, the proper way to view the data in the first place. You can't evaluate banding at less than 1:1 or 100% due to a zoomed out preview uses differing subsampling to show you the image.

    The banding in the display path can be due to it not being totally high bit either. In a high bit display path, ALL areas must be high bit: The video card, the display panel, the software and the OS.

     

    Thanks! I realize a banding issue can occur when an image is zoomed out and its physics with the display, but in my case the "compression look" is seen on every zoom-level as you can see above? If the issue just lays in my hardware chain another display would not have the issue, right? I double checked with an eizo color edge, same problem persists. And my own setup being a recent and maxed out Macbook Pro in combination with up-to-date Adobe software should be able to process an image without such a noticeable drop in quality, shouldn't it?

  17. To add something I just discovered:

     

    I tried to open the original source image from my scan in photoshop and reset all development settings upon import (Camera RAW pops up and wants settings, I just reversed everything and opened the image)

     

    The issue comes up even before exporting the image, as soon as the source material is "touched" by got "out of" the Camera RAW development module the image muds up, even inside of photoshop!

  18. scanned using silverfast into a tif with 2903 × 1943 pixels, not sure about the model of the scanner but a rather advanced type, no sub 1k $ consumer model afaik

     

    I get that these specs help generally, but in this case it seems that the issue lies somewhere in the processing of the data rather than the capturing? The source file looks good, just when put into the Adobe Camera RAW processing system it messes with the compression somehow and leads to a noticeable drop in quality.

  19. You're right, the pixels of the export appear to be bigger. But how can that be the case when I'm exporting without any resizing of the image? The dimensions are the same too, still it seems it looses half the resolution!

     

    I tried to make a fixed pixel sized comparison, but realized that when I import the source image into photoshop I can't get around the "development" done by the camera RAW module, which leads to the compression - even though I didnt even export the image!

     

    I tried to work around that by screengrabbing a fixed rectangle of a evenly magnified osx preview as seen below.

     

    Original

     

    547440367_Bildschirmfoto2020-04-16um15_58_27.thumb.png.adb0487c9ba41325ee346124918a2c6b.png

     

    After

     

    629340734_Bildschirmfoto2020-04-16um15_59_01.thumb.png.438411bd0c8deb0c8fd3299a888e8258.png

  20. This is a screenshot of an enlarged portion of the picture inside the LR module - There are no artifacts at all

     

    556158791_Bildschirmfoto2020-04-16um12_30_56.thumb.png.fdf10b873ed32badce1a38c70372e4b7.png

     

    This is the original file without any edits, just converted from tif to png to be able to upload here - no artifacts at all of course

     

    0828.thumb.png.8179b018781d800d07da81b9ece8d197.png

     

    This is the exported final result as a jpeg, just because I cant upload a tif here - but the issue with a tif is identical. Of course the jpeg shows some additional signs of compression, but the blurred areas of smudged grain look just like that on a uncompressed file. To see it, you have to zoom in a little, but not to a pixel level.

     

    0828.thumb.jpg.79a0bb389da07dbdb0f7a452297b471e.jpg

     

    It drives me nuts.

×
×
  • Create New...