Reading Sony RAW (.arw) Images

Hello,

I have a problem reading Sony RAW (.arw) files with openAsPicture.
See screenshot what is in the Picture-object:

Then I tried with QTGraphicsImporterMBS, but that gave LastError = -1
Then with CIImageMBS, and that returned ‘nil’.

So, does someone know how to read those kind of images?

Ehm… target is to get a picture handle to display the image in an imageWell.

Thanks for your help,
Marc Vos

Did you try CIFilterMBS filterWithImageFile?

Does it open in preview.app? Because we need macOS to support it.

Otherwise, you could try dcraw command line tool.

Ah, d… Preview gives an error: Preview currently does not support this raw file format.

I’m looking for a binary dcraw for Mac OS X just now.

[quote=372216:@Marc Vos]Ah, d… Preview gives an error: Preview currently does not support this raw file format.

I’m looking for a binary dcraw for Mac OS X just now.[/quote]
So basically there’s a bunch of issues.

  1. You need to stay up to date with the macOS in order to get the rawCamera formats that Apple supports, no longer do they ship updates to previous versions of the macOS. Which has not gone down well with the Photography community at all.

  2. Apple’s support for RAW formats was never as quick as Adobe’s, but in the recent years, they’ve really started to fall even further behind. I personally chalk this up to Apple not really caring about any other camera but the iPhone.

  3. DCRaw is probably the best way if you want to embed the library within your application. If it’s for your own personal use, consider Adobe’s DNG converter.

I run 10.12.6 - so not as up-to-date as ‘now()’ but still, on the internet these .arw issues go way back.

I now have a dcraw tool, but it takes 20 seconds to convert this 42MB compressed .arw to .ppm
I don’t know if that’s an acceptable time to wait for a RAW image to be displayed, under photographers, I mean.

Since it is not for personal use, embedding dcraw is the only way.

Christian, thanks for pointing me to dcraw! Never would have found it otherwise.

Personally I would;

  1. First try to open it normally, that way if/when Apple add support your app will automatically get the improvement.
  2. If that fails, extract the UTI of the file and use UTTypeConformsTo “public.camera-raw-image” to see if it’s a RAW image. If not, abandon here.
  3. Most RAW formats are based upon the TIFF specification and contain a thumbnail of sorts, some contain JPEG some contain TIFF, all should be readable with CGImageSource, just loop through until you find a smaller preview. Display a dialog to the user with the preview and a message saying something like “RAW format not supported by Apple, using 3rd Party RAW converter. This may take a few moments…”. This way you make it clear to the user why it’s taking longer to open the image in your application than it does with say Adobe software.
  4. Let DCRaw do it’s job.
  5. File a feature request at Apple for the RAW format, make sure to include in the feature request that you want this for the version of the macOS that you’re using and tell them why you haven’t upgraded.

You’ll probably never get the RAW image support in the version of the macOS you’re using, and they may never add RAW support (Afterall Apple consider the iPhone to be a professional camera, bleugh). At the least you’re doing the best you can and providing them with information as to why photogs are leaving the platform, it’s up to them what they do with it.

I used to get requests to add RAW image support to my photography based applications in the past, I’d always respond and say I used Apple’s RAW converter and I’d let Apple know about the users Camera. However in recent years I don’t seem to get so many requests, I get more requests for Windows versions of my apps instead.

p.s. Send Dave Coffin an e-mail, he’s a good guy and maybe there’s something he can do to speed it up for you.

[quote=372312:@Sam Rowlands]Personally I would;

  1. Most RAW formats are based upon the TIFF specification and contain a thumbnail of sorts, some contain JPEG some contain TIFF, all should be readable with CGImageSource, just loop through until you find a smaller preview. Display a dialog to the user with the preview and a message saying something like “RAW format not supported by Apple, using 3rd Party RAW converter. This may take a few moments…”. This way you make it clear to the user why it’s taking longer to open the image in your application than it does with say Adobe software.
    [/quote]

Hi Sam, it’s all about only displaying the image in a 200x200px ImageWell.
I’ll have a look at CGImageSource[MBS], and implement dcraw with a button if everything else fails, so the user can decide if (s)he wants to wait 20 secs.

Regards,
Marc

Then look into reading the preview, you might even be able to extract using Quicklook, I seem to recall that the previews are 160 x 120.

So … CGImageSource did return what it was, but no handles to any image data. I found that dcraw has an option to extract the thumbnail image (-e), if any. That takes less then a second! So I use that option now, when no other image-reading routines return valid results.

Thanks for all your input!

[quote=372431:@Marc Vos]So … CGImageSource did return what it was, but no handles to any image data. I found that dcraw has an option to extract the thumbnail image (-e), if any. That takes less then a second! So I use that option now, when no other image-reading routines return valid results.

Thanks for all your input![/quote]
Good I’m glad you something that’s much quicker than 20 seconds.

I would recommend to use this function:

CIFilterMBS.filterWithImageFile(File as FolderItem, options as Dictionary) as CIFilterMBS

this would do the raw images and allow to specify options.

[quote=372605:@Christian Schmitz]I would recommend to use this function:

CIFilterMBS.filterWithImageFile(File as FolderItem, options as Dictionary) as CIFilterMBS

this would do the raw images and allow to specify options.[/quote]
Hi Christian,
While the OP could use this function (if Apple ever add support for his camera) I would recommend against it for displaying a preview.

Let me explain why. This function’s primary use is to load the RAW image and operate on the RAW data using Core Image. Apple have only ever demonstrated it using basic functions or RAW conversion functions, and the reason for that is because loading a RAW image into GPU memory takes a lot of space, thus applying a large filter chain to the RAW image can crash the GPU resulting in the machine crashing. The best usage I’ve found with this function is to use it to render a RAW image to a CGImage (thus transferring the rendered image to a 32-BIt image stored in the application memory, then flush the RAW image from the GPU and upload the RAM based image to the GPU. This way the OS can flush and restore the image data as needed.

For simply providing a preview of a RAW image, it’s much safer (unless you need to intervene in the RAW conversion process) to get Core Graphics to do it. You can get Core Graphics to generate a 32-BIt preview and tweak some detail after wards (some dynamic range can be recovered and colors corrected), it’s just not as precise as doing it during the RAW conversion.

Just my humble opinion.